Entra Mandatory MFA Enforcement: What Actually Breaks

Your admins are fine. They’ve had MFA for years, and they’ll never notice this landed.

What breaks is the deployment pipeline that’s been running since 2021 with a username and a password sitting in an environment variable, built by someone who left in 2023, documented nowhere. It’ll fail on a release day, the error will look like a permissions problem, and two people will spend a morning checking RBAC assignments before anyone thinks about identity.

So it’s worth knowing what’s in scope, what isn’t, and the order things tend to fall over.

A timeline, because the dates keep getting misreported

• October 2024. Phase 1 begins. MFA required for accounts signing in to the Azure portal, the Microsoft Entra admin center, and the Microsoft Intune admin center, for any create, read, update, or delete operation. Read is included here, which won’t be true of Phase 2.
• February 2025. Phase 1 extends to Microsoft 365 admin center sign-in, at admin.microsoft.com, admin.cloud.microsoft, and portal.office.com/adminportal/home.
• September 30, 2025. Last selectable start date under the Phase 1 postponement page.
• October 1, 2025. Phase 2 begins, gradually. Azure CLI, Azure PowerShell, the Azure mobile app, IaC tooling, the REST API, and the Azure SDKs. Create, update, and delete only; Microsoft is explicit that reads won’t require MFA.
• July 1, 2026. The latest enforcement start date a tenant could select on the Phase 2 postponement page.

That word gradually is doing real work. Microsoft’s own documentation illustrates the postponement page with a tenant whose enforcement lands “on or after February 20, 2026,” which tells you Phase 2 didn’t flip globally on October 1 the way a lot of write-ups imply. Don’t assume your tenant was enforced that day. Don’t assume it wasn’t, either. Go look.

One wrinkle that catches people who did their homework early: if you postponed the start of Phase 1, the start of Phase 2 was postponed to the same date automatically.

You’ll also find articles dating Phase 2 to October 2024 or to October 15, 2024. Those are stale. Microsoft’s documentation carries an explicit change note that the enforcement date for Phase 2 moved to October 1, 2025.

Managed identity or user account: that’s the whole question

This is where most coverage goes wrong, and the error costs real remediation hours in both directions.

Microsoft’s position is specific. Workload identities, meaning managed identities and service principals, aren’t impacted by either phase. A pipeline authenticating with a service principal and a certificate keeps working. A function app using a system-assigned managed identity keeps working. An Entra Connect or Entra Cloud Sync deployment keeps working, because the synchronization service account isn’t affected.

What’s affected is the pattern where somebody created a normal user account, gave it a password, granted it Contributor, and pointed a script at it. Microsoft’s wording: if user identities are used to sign in as a service account to run automation, including scripts or other automated tasks, those user identities need to sign in with MFA once enforcement begins. The FAQ says it again. Automation accounts are out of scope only while they use a managed identity or service principal, and any set up as user identities will be enforced upon.

So the useful question isn’t “do service accounts need MFA.” It’s “which of my automations authenticate as a human-shaped account.”

In our experience the answer is always at least one more than the platform team expects, and it’s usually something with a name like svc-deploy that predates the current org chart.

Resource Owner Password Credentials

The OAuth 2.0 ROPC grant trades a username and password directly for a token. It can’t carry a second factor, so it’s structurally incompatible with MFA, and Microsoft’s guidance is blunt: after MFA is enabled in your tenant, ROPC-based APIs used in your applications throw exceptions.

The entry points, per library, along with the version each was deprecated in:

• .NET: AcquireTokenByUsernamePassword, deprecated as of MSAL.NET 4.74.0
• Go: the public client username-password API, as of 1.6.0
• Java: PublicClientApplication.acquireToken(UserNamePasswordParameters parameters), as of msal4j 1.24.0
• Node: acquireTokenByUsernamePassword, as of 3.2.3
• Python: acquire_token_by_username_password, as of 1.35.0

Worth noting the Java one specifically, since msal4j doesn’t follow the naming pattern the other libraries use and half the blog posts on this topic paste a method name that doesn’t exist there.

The environment variable trap

This one bites teams who believe they’re already modern, and it’s my favorite finding to hand over because the fix takes ten minutes once you’ve seen it.

DefaultAzureCredential is the recommended credential chain in the Azure Identity libraries, and it’s genuinely good practice. But it walks a chain of credential sources, and one of those links reads AZURE_USERNAME and AZURE_PASSWORD from the environment. If those variables are set on your build agent, DefaultAzureCredential or EnvironmentCredential will happily use them, and that path is ROPC underneath. The code looks modern. The auth isn’t.

UsernamePasswordCredential itself is deprecated across the Azure Identity libraries on a parallel timeline: .NET at 1.14.0-beta.2, Go at 1.9.0, Java at 1.16.0-beta.1, Node at 4.8.0, Python at 1.21.0.

Grep every pipeline definition and secret store you have for AZURE_PASSWORD. That single search finds more broken automation than an hour of reading code.

Break-glass accounts stopped being exempt

Every well-run tenant has one or two emergency access accounts excluded from every Conditional Access policy, with a long password in a physical safe. That design is now insufficient, and it’s insufficient in a way that’s easy to miss because nothing about it looks broken.

Microsoft covers it directly: break glass or emergency access accounts are also required to sign in with MFA once enforcement begins. The FAQ widens it. Enforcement applies to all user accounts regardless of whether they’re a student account, a break-glass account, an administrator account with activated or eligible roles, or any user exclusions enabled for them.

There’s a bigger version of this. If you configured exceptions or exclusions in a Conditional Access policy, they no longer apply to this enforcement. Exclusions were the standard tool for carving out accounts that couldn’t do MFA: the break-glass pair, the legacy service account, the vendor’s support login. That tool doesn’t work here anymore, and if your identity design leans on it, the revisit is bigger than a policy edit.

Microsoft’s recommended fix is a passkey (FIDO2) or certificate-based authentication. Both satisfy the requirement, and neither depends on a phone number, a SIM, or a person being awake. For a break-glass account that’s the right shape anyway: two hardware keys, two safes, two people, written down.

Old clients fail quietly

Even where a user can complete MFA, an old client might not tell them that’s what’s needed.

Microsoft’s note is worth reading twice. A user signed in without MFA can still use a Phase 2 application, but on a create, update, or delete the app returns an error saying they need to sign in with MFA, plus a claims challenge. Some clients use that claims challenge to prompt for step-up. Others return only the error, with no prompt at all.

That second category is where your help desk tickets come from. Someone runs a deployment, gets an opaque authorization failure, and files a ticket that reads like an RBAC problem.

Microsoft names Azure CLI 2.76 and Azure PowerShell 14.3 or later as the versions to be on for the best compatibility experience. I’d treat that as a floor and push past it on every build agent and admin workstation. I’d also stop short of the claim I’ve seen elsewhere, that older versions can’t handle claims challenges at all. Microsoft doesn’t say that, and the failure mode is more varied than a single missing capability.

Where things fail, at a glance

What stays out of scope

Knowing the boundary is worth as much as knowing the requirement, because it stops you remediating things that were never at risk.

Microsoft Graph sits outside it, generally. Only requests sent to https://management.azure.com/ are under scope, which is the Azure Resource Manager control plane. Your Graph-based provisioning tooling is a separate conversation. Microsoft’s own hedge is “generally,” and I’d keep the hedge rather than flatten it.

Reads are exempt under Phase 2. A monitoring job that only queries resource state through a user identity keeps working. Add a tagging or cleanup step and it doesn’t.

Sovereign clouds are out for now. Enforcement is public-cloud only; Microsoft says it isn’t currently enforced in Azure for US Government or other sovereign clouds. “Currently” is Microsoft’s word, not mine.

Directory synchronization stays clear too, because the Entra Connect and Entra Cloud Sync service account isn’t affected.

Applications hosted on Azure are a different question entirely. Users aren’t required to use MFA to reach other applications, websites, or services hosted on Azure, and those owners set their own authentication requirements. This enforcement is scoped to managing Azure. The applications running on it keep whatever rules their owners already wrote.

Two catch people the other way. Test tenants are in scope, with no exception for test environments. B2B guests are in scope too, satisfiable either from the resource tenant or from the guest’s home tenant through cross-tenant access settings.

Which enforcement tool you can actually use

Getting ahead of Microsoft by requiring MFA yourself is the whole game here, because when you already satisfy the requirement, enforcement arrives as a non-event. Three options, and your licensing decides which.

Conditional Access, if you have it, which means Microsoft Entra ID P1 or P2. Build a policy requiring MFA for the users and applications in scope. Stricter policies you already have keep applying, a phishing-resistant MFA requirement for instance. Microsoft’s enforcement doesn’t weaken what you’ve built. It removes the exclusions.

Security defaults, for tenants on free Entra ID. Blunt, all-or-nothing, and dramatically better than nothing.

Azure Policy works regardless of Entra licensing, and it’s the only one with a dry run. Microsoft publishes two built-in definitions, both at version 1.0.0-preview: one for delete operations (db4a9d17-db75-4f46-9fcb-9f9526604417) and one for create and update (4e6c27d5-a6ee-49cf-b2b4-d8fe90fa2b8b). The effect parameter takes AuditAction or Audit, and the override takes DenyAction or Deny, depending which definition you picked. The vocabularies aren’t uniform, which is normal for a preview and an easy way to write an assignment that silently does nothing.

The Azure Policy compliance list is always empty for these definitions, by design, and not knowing that will cost you an afternoon. Microsoft’s own tutorial says these assignments don’t provide compliance, that audit events appear only in Activity Logs, and that the compliance list always shows zero resources, because the policy identifies non-compliant requests rather than resources. So “the compliance blade is clean” means nothing at all. Read the Activity Log instead: filter on operationName.value=='Microsoft.Authorization/policies/audit/action' from the CLI, or run AzureActivity | where CategoryValue == "Policy" if you’ve got the logs in a workspace.

Microsoft’s mandatory-MFA page describes the Audit effect as reporting noncompliance in policy compliance results, which contradicts the tutorial. When two Microsoft pages disagree, take the more specific one. The tutorial is about this exact policy, and its explanation of why the list is empty is internally consistent in a way the summary sentence isn’t.

While you’re in preview, resource selectors are worth using to stage the rollout by location rather than flipping the whole estate, and expect the error text your users see to vary by client and command.

If your MFA comes from somewhere else

Plenty of organizations already have strong multifactor authentication and none of it is Microsoft’s. That’s fine, but the integration has to be the current one.

A third-party MFA product integrated through the external authentication methods framework satisfies the requirement. What doesn’t satisfy it is the legacy Conditional Access custom controls preview. Microsoft is explicit that custom controls don’t meet the MFA requirement and that you need to migrate to external MFA to keep using an external solution. That’s a genuine trap: a tenant on custom controls has MFA, believes it’s compliant, and isn’t. The remediation is a migration, not a setting.

If you federate to an external identity provider such as AD FS and your MFA lives there, the IdP has to send Entra a claim saying so. Microsoft names multipleauthn, and for WS-Fed or SAML 1.1 the value wiaormultiauthn is accepted as well; on SAML 2.0 the claim needs to arrive in the AuthnContext element. Whether Entra honours any of it also depends on how federatedIdpMfaBehavior is set on the domain. Get the claim wrong and Entra treats the sign-in as single-factor no matter what the user actually did at the IdP.

Test both of these before enforcement rather than after. The failure looks exactly like a misconfiguration, and your first instinct will send you to the wrong place.

What to do this month

The postponement dates are behind us. What’s left is a support request, raised by a Global Administrator, to temporarily lift enforcement after it’s begun. That’s a lever for an emergency, not a plan.

So the work is the same whether enforcement has already reached your tenant or is still queued:

Pull thirty days of sign-in logs and filter to the enforcing application IDs. Azure CLI is 04b07795-8ddb-461a-bbee-02f9e1bf7b46, Azure PowerShell is 1950a258-227b-4e31-a9cf-717495945fc2, and the Azure mobile app is 0c1307d4-29d6-4389-a11c-5cbe7f65d7fa. IaC tooling authenticates as CLI or PowerShell, so it lands under those two. Add c44b4083-3bb0-49c1-b47d-974e53cbdf3c if you want the Phase 1 surfaces, since the Azure portal, Entra admin center, and Intune admin center share it. That one’s been enforced since 2024 and shouldn’t be producing surprises.

For every account in that result, ask one question: is this a person? If no, it moves to a workload identity: managed identity where the workload runs in Azure, service principal with federated credentials or a certificate where it doesn’t.

Then search every pipeline definition, key vault, and secret store for AZURE_PASSWORD and for the ROPC calls listed above. Re-key break-glass accounts onto FIDO2 or certificate-based auth, and rehearse the recovery path with the new method before you need it, because a break-glass account you’ve never tested is a story, not a control. Push Azure CLI and Az PowerShell past the floor everywhere. Assign the Azure Policy in audit and go read the Activity Log rather than the compliance blade.

None of it is difficult. All of it is tedious, and the tedium is why it gets deferred until a deployment fails on a Friday. If you’d rather have the sign-in log analysis and the workload identity conversion handled as a scoped piece of work than squeezed between sprints, our security team does that shape of engagement. You end up with an inventory, a converted pipeline set, and a break-glass procedure your auditors will accept.

The enforcement was never the risk. The undocumented account with a password in a build variable was always the risk. Microsoft just stopped letting you ignore it.