Emergency Access (Break-Glass) Accounts Prompted for MFA Registration Despite All Exclusions Configured

Configure each emergency-access account with a passkey (FIDO2 security key) or certificate-based authentication because Microsoft’s mandatory MFA enforcement explicitly includes break-glass accounts and Conditional Access exclusions do not exempt them.^1^

What is triggering the prompt?

For sign-ins to an affected admin application, the most likely mechanism is Microsoft’s application-level mandatory MFA enforcement, not one of your tenant’s Conditional Access policies.

Mandatory MFA applies to:

• Azure portal, Microsoft Entra admin center, and Microsoft Intune admin center.
• Microsoft 365 admin center.
• Azure CLI, Azure PowerShell, Azure mobile app, IaC tools, and control-plane operations, according to the applicable enforcement phase.
• All user accounts performing the affected operations, including emergency-access accounts.

Microsoft states that Conditional Access exceptions or exclusions no longer apply to this enforcement. This is consistent with the sign-in logs showing the MFA Conditional Access policies as Not Applied.^1^

To confirm it for these particular events:

1. Open Microsoft Entra admin center → Entra ID → Monitoring & health → Sign-in logs.
2. Open the affected sign-in.
3. Check Application, Authentication Details, and Conditional Access.
4. The mandatory-MFA documentation states that the sign-in log identifies the application that imposed the MFA requirement.
5. In Azure portal, browse to the Phase 1 mandatory-MFA management page described in the documentation and verify whether its banner says enforcement has begun for the tenant.^1^

MFA enforcement versus security-information registration

They are related but separate operations:

• MFA enforcement requires the account to complete multifactor authentication for the protected operation.
• Security-information registration provisions the authentication method needed to satisfy that requirement.
• Because these accounts currently have no registered method, the MFA requirement sends them through the combined registration wizard—the “Let’s keep your account secure” experience.

Combined registration calls this interrupt mode. It can be triggered by Conditional Access, per-user MFA, Identity Protection, SSPR, or other MFA policies. The wizard then exposes methods permitted by the relevant authentication-method policies.^2^

Therefore, exclusion from a registration campaign does not provide an exception from mandatory MFA. Registration campaigns encourage enrollment; they do not disable an independent application-level MFA requirement.

Supported exception

There is no documented break-glass exception to mandatory MFA for the affected applications. Microsoft explicitly says emergency-access accounts must complete MFA and recommends:

• Passkey (FIDO2), preferably using a hardware security key.
• Certificate-based authentication (CBA) configured to satisfy MFA.^1^

Continue excluding the accounts from Conditional Access policies that block or restrict sign-in. That protects against tenant policy misconfiguration, but it does not override Microsoft’s mandatory MFA enforcement.^3^

Supported shared-account architecture

Microsoft’s current emergency-access guidance expressly allows accounts that are not associated with an individual. For your shared operational model:

1. Retain at least two cloud-only .onmicrosoft.com emergency accounts.
2. Assign Global Administrator as permanent active, not PIM-eligible.
3. Register FIDO2 hardware keys or CBA credentials.
4. Keep the credentials available to multiple authorized responders through a controlled process.
5. Store credentials or devices in separate, secure, fireproof locations.
6. Require a designated secure workstation or Privileged Access Workstation.
7. Alert on every sign-in and audit event involving either account.
8. Test each account at least every 90 days.^3^

For remote out-of-hours operation, Microsoft also documents the alternative of individual emergency-access accounts for authorized administrators. That improves accountability and allows remote use without distributing one shared physical credential. The trade-off is more emergency identities and credentials to govern.^3^

A practical shared design is to provision multiple hardware keys for each emergency identity, store them under controlled custody at separate staffed or securely accessible locations, and document checkout, approval, use, and return procedures. Avoid tying the account to an engineer’s personal phone.

Check separately for SSPR registration

Mandatory MFA can explain the need to establish an MFA-capable method, but SSPR can independently add registration requirements, especially if the wizard requests two methods.

Global Administrators are subject to a predefined two-gate administrator SSPR policy. If SSPR is enabled for these accounts, combined registration can request Authenticator plus another method even though the registration campaign and Conditional Access policies exclude them.^4^

If that applies:

• Exclude the emergency accounts from the tenant’s user SSPR scope.
• If the organization intentionally wants to disable SSPR for all administrators, the tenant-wide authorization policy supports:

Connect-MgGraph -Scopes Policy.ReadWrite.Authorization

Update-MgPolicyAuthorizationPolicy `
    -AllowedToUseSspr:$false

This affects administrator SSPR tenant-wide and can take up to 60 minutes; it does not remove mandatory MFA.^4^

References

1. Mandatory multifactor authentication for Azure and admin portals
2. Combined security information registration for Microsoft Entra overview
3. Manage emergency access accounts in Microsoft Entra ID
4. Password policies and account restrictions in Microsoft Entra ID