October 15 Date for First Round of Azure MFA Requirement Enforcement

Microsoft’s decision to enforce multifactor authentication (MFA) for access to Azure properties certainly caused a great deal of kerfuffle. The original May 14, 2024 announcement didn’t help itself by proclaiming that “Microsoft will require MFA for all Azure users,” an assertion that led people to believe that any sign-in to Azure AD (Entra ID) would require MFA. At the time, I thought the idea is sound but the communication was woeful.

Roll forward to June 27, 2024, and a follow-up post to the Core Infrastructure and Security blog in the Microsoft Technical Community attempted to clear the confusion. Given the number of questions since, the signs are that people are still unsure what’s happening. Let me try to unravel the situation.

First, not everyone is affected by the change. MFA is only enforced for access to some Azure cloud properties. According to message center notification MC862873, Microsoft will require MFA for access to the Entra admin center, Azure portal, and Intune admin center (including services like Windows 365 Cloud PC) on or after October 15, 2024. Although I am not certain, Windows 365 Cloud PC seems like the only place where non-administrators might be affected by the MFA requirement.

Phase 2 of the implementation in early 2025 will see the requirement spread to the Azure CLI, Azure PowerShell, and infrastructure as code (IaC) tools. The good news is that only administrator accounts typically use these sites. Normal users are unaffected by the change. And anyway, administrator accounts should be protected by MFA. If they are not, the tenant has other problems.

Second, Microsoft 365 tenants that use Security Defaults already mandate MFA for connections to administrator portals.

Third, tenants that don’t use Security Defaults and have conditional access policies in place to control connections instead probably have a policy to require MFA for connections to administrative sites. Microsoft even publishes a policy template to make it easy for tenants to enable this control.

Workload identities, such as the managed identities used with Azure Automation, are unaffected. However, if Azure Automation runbooks include user identities (username and password credentials) for authentication, they might not work after Microsoft deploys the requirement for MFA access to Azure. For instance, if a runbook uses the Azure PowerShell module, it must use a managed identity or service principal (app) to connect.

Break glass accounts are affected too. If ever needed, these accounts are likely going to access Azure administrative sites and use Azure administrative tools, so the new guidance is to modify the previous practice of using a long and complicated password and add the protection for the accounts with a strong MFA authentication method like FIDO2 or certificates.

Postponing the Azure MFA Requirement

Microsoft says that they will allow a grace period to tenants who need some extra time. Organizations that use non-Microsoft MFA solutions might be in this category (support for external MFA providers is in preview). If in doubt, use the link in the message center notification post to request a postponement (Figure 1).

More information is available in the Microsoft planning document covering the new requirement.

Microsoft’s Script to Reveal Access to Azure Administrative Tools

In their post, Microsoft says that the Export-MsIdAzureMfaReport cmdlet from the MSIdentityTools PowerShell module as a way to uncover accounts likely to be affected by the change. The cmdlet “exports the list of users that have signed into the Azure portal, Azure CLI, or Azure PowerShell over the last 30 days by querying the sign-in logs,” so it’s a useful way to get an insight into who might be affected by the MFA requirement. I ran the cmdlet for my tenant and found that I need to act for an account used for utility background jobs (Figure 2).

The data used by the cmdlet is available to administrators to create their own version. For instance, the script covered in this article explains how to combine data from several sources to create a picture of MFA usage within a tenant.

No Need to Panic – the Azure MFA Requirement is a Good Thing

The bottom line is that there’s no need to panic unless you have a bunch of background jobs that use user credentials for authentication or forget to update your break glass accounts. Normal users will make unperturbed progress through the change. This is predominantly a good update to force administrators who haven’t yet understood the absolute need to protect their accounts with MFA to change their behavior. After all, why leave an open door ready for the bad guys to kick in?

Support the work of the Office 365 for IT Pros team by subscribing to the Office 365 for IT Pros eBook. Your support pays for the time we need to track, analyze, and document the changing world of Microsoft 365 and Office 365.