Microsoft Makes MFA Mandatory for Azure — What AZ-104 and AZ-500 Candidates Must Know

What Microsoft changed — and when

For years, MFA in Azure was a best-practice recommendation enforced through Conditional Access policies at the discretion of each organization. That changed in 2024. Microsoft announced that MFA would become a platform-level requirement with no opt-out path, rolling out in two distinct phases to minimize disruption.

Phase 1 (October 15, 2024) targeted interactive browser-based sign-ins to the Azure portal, the Microsoft Entra admin center, and the Microsoft Intune admin center. Any user — global administrator, contributor, or read-only guest — signing into these surfaces was required to satisfy an MFA challenge before gaining access. Organizations that had not yet deployed a compliant MFA method received automatic enforcement regardless of their Conditional Access configuration.

Phase 2 (February 3, 2025) extended the requirement to non-browser tooling: the Azure CLI, Azure PowerShell, the Azure mobile app, and IaC toolchains including Terraform and Bicep pipelines that authenticate interactively. Service principals and managed identities authenticating with certificates or client secrets were explicitly excluded — the mandate targets human sign-ins, not machine identities.

How MFA enforcement works under the hood

Microsoft implemented the enforcement at the tenant-level through a system-managed Conditional Access policy called Require MFA for Azure management. Unlike customer-created policies, this one cannot be disabled. Tenant administrators can inspect it in the Entra admin center under Protection → Conditional Access → Policies, but the toggle is read-only.

Accepted second factors include: the Microsoft Authenticator app (push notification or number-matching), FIDO2-compliant hardware security keys, certificate-based authentication via smart card, Windows Hello for Business, and passkeys stored in Authenticator or a third-party FIDO2 platform. SMS one-time codes are accepted but Microsoft explicitly classifies them as the weakest option and steers organizations toward phishing-resistant methods for privileged roles.

Break-glass emergency-access accounts — the accounts every Azure administrator should maintain for lockout recovery — are not exempt. Microsoft recommends pairing these accounts with FIDO2 hardware keys rather than phone-based authenticators, since a lost or locked phone should not become a recovery blocker during an incident.

What this means in practice for Azure administrators

The enforcement surfaces friction in a few common administrative workflows. Automated scripts that previously used a service account with username and password to call az login interactively will fail if the script runs in a context that presents a human sign-in prompt. The fix is straightforward: switch those scripts to service principal authentication with a client secret or certificate, or use a managed identity when running inside Azure. The broader lesson — that human and machine identities should use different auth flows — is exactly the kind of architecture question that appears on AZ-104 and AZ-500 exams.

Microsoft's enforcement mirrors a decade-long industry consensus: password-only access to privileged management planes is an unacceptable risk. The mandate removes the organizational inertia that delayed MFA adoption at tens of thousands of tenants.