Question About Azure MFA Phase 2 Enforcement Behavior

Question

I have a question regarding Azure MFA.

It has been about six months since the “Enforcement starts” date for Phase 2 described in the following documentation: https://learn.microsoft.com/en-us/entra/identity/authentication/concept-mandatory-multifactor-authentication?tabs=dotnet#phase-2-applications

However, MFA is still not required when launching the CLI or PowerShell. Do users need to configure something themselves for MFA to be enforced? Or is it supposed to be enforced automatically?

Additionally, MFA is applied when logging in to the Azure Portal. Was this configured by the user, or is MFA being enforced automatically?

Answer 1

Phase 2 MFA enforcement and Azure CLI/PowerShell behavior work as follows:

1. How Phase 2 enforcement works (CLI, PowerShell, IaC, REST)
   Phase 2 is enforced on the Azure Resource Manager (ARM) service side, not in the client tools themselves. Any user account that sends a Create/Update/Delete request to https://management.azure.com via Azure CLI, Azure PowerShell, SDKs, IaC tools, or REST APIs is in scope. When enforcement is active for the tenant:
   • If the user signs in without MFA and then performs a Create/Update/Delete operation, ARM returns an error plus a claims challenge indicating MFA is required.
   • Some clients interpret the claims challenge and prompt the user to perform MFA (“step-up” authentication). Other clients only show the error and do not automatically prompt.
   • Read-only operations do not require MFA in Phase 2.
   This enforcement is automatic on the service side; it does not require the tenant to configure Conditional Access or other policies for it to exist. However, the rollout is gradual across tenants, and Microsoft allows tenants to postpone Phase 2 enforcement.
2. Why CLI/PowerShell may not be asking for MFA yet
   Several reasons can explain why MFA is not yet observed when using CLI/PowerShell:
   • Phase 2 may not yet be enforced for the tenant due to the gradual rollout, or the tenant’s enforcement date may have been postponed. A Global Administrator can postpone Phase 2 to a later date using https://aka.ms/postponePhase2MFA. If Phase 2 is postponed, ARM will not yet require MFA for Create/Update/Delete operations from CLI/PowerShell.
   • Even after enforcement starts, sign-in itself to CLI/PowerShell does not always show an MFA prompt immediately. The MFA requirement is evaluated when a resource management operation is executed. If only read operations are being performed, or if the client does not surface the claims challenge as an MFA prompt, it may appear as if MFA is not enforced.
   • For best compatibility, users should be on Azure CLI 2.76+ and Azure PowerShell 14.3+; older versions may show errors rather than a clean MFA prompt.
   No additional configuration is required for the system enforcement itself, but Microsoft strongly recommends configuring Conditional Access or security defaults so that users complete MFA before they encounter enforcement errors.
3. Do users/tenants need to configure something for MFA to be enforced?
   • System (mandatory) MFA enforcement for Phase 2 is handled by Microsoft and is automatic once it is active for the tenant (unless postponed). Tenants do not need to create policies for this enforcement to exist.
   • However, to provide a smoother user experience and to ensure MFA is already in place across all relevant sign-ins, tenants are expected to:
     • Configure a Conditional Access policy that requires MFA for users accessing Azure (requires Entra ID P1/P2), or
     • Enable security defaults if Conditional Access is not available.
   • Tenants can also use Azure Policy in Audit or Enforcement mode to self-enforce MFA and understand impact ahead of Microsoft’s enforcement.
4. Why MFA is already applied in the Azure portal
   Phase 1 enforcement covers the Azure portal, Microsoft Entra admin center, Microsoft Intune admin center, and later the Microsoft 365 admin center. For Phase 1:
   • Starting October 2024, MFA is required for accounts that sign in to these portals to perform any CRUD operation, with a gradual rollout across tenants.
   • This is system enforcement by Microsoft. If the tenant has not postponed Phase 1, MFA in the Azure portal may be coming from this mandatory enforcement, even if the tenant did not explicitly configure Conditional Access.
   • If the tenant already had Conditional Access or security defaults requiring MFA for portal access, there is effectively no change in user experience; MFA was already being enforced by tenant policy.
   Therefore, the MFA prompt in the Azure portal could be:
   • From tenant-configured policies (Conditional Access or security defaults), or
   • From Microsoft’s Phase 1 mandatory MFA enforcement, if active for the tenant.
5. Postponement and timing
   • Tenants with complex environments can postpone Phase 1 enforcement until September 30, 2025 via https://aka.ms/managemfaforazure.
   • Tenants can postpone Phase 2 enforcement until July 1, 2026 via https://aka.ms/postponePhase2MFA. If Phase 1 was postponed, Phase 2 is automatically postponed to at least the same date, and can be set even later.
   • If postponement is configured, MFA will not yet be enforced by the system for the corresponding phase, even if the general “Enforcement starts” date has passed.
6. Summary for the described behavior
   • Azure portal MFA: Likely enforced either by existing Conditional Access/security defaults or by Phase 1 mandatory MFA if the tenant is in scope and not postponed.
   • CLI/PowerShell MFA: Phase 2 enforcement is service-side and operation-based. If it is not observed:
     • Phase 2 may not yet be active for the tenant or has been postponed.
     • Only read operations may be in use, which do not require MFA.
     • The client may not be surfacing the claims challenge as an MFA prompt, or the tools may be on older versions.
   • No extra configuration is required for Microsoft’s mandatory enforcement, but Conditional Access or security defaults are recommended to ensure users complete MFA smoothly and consistently.

---

References:

• Planning for mandatory multifactor authentication for Azure and other admin portals
• Azure Identity Management and access control security best practices