How to Configure Entra ID Emergency Access for Mandatory MFA

How to Configure Entra ID Emergency Access for Mandatory MFA

Table of Contents

Imagine the scenario: Entra ID is experiencing a partial outage, MFA requests are timing out globally, and your federated ADFS server just crashed. You are the Global Admin, and you need to get in to fix it. But you can’t.
This is the “locked out” nightmare. Historically, the solution was simple: a “Break Glass” account protected by a long, complex password and excluded from all policies.
But in 2025, that strategy is effectively dead.
Microsoft’s rollout of Mandatory MFA for Azure has shifted the landscape. If your emergency strategy relies on a password alone, you are walking into a trap. Here is how to modernize your Break Glass strategy to survive the new compliance requirements without sacrificing emergency access.

The Rationale: Why “Password-Only” is Dangerous

For years, the standard advice was to exclude emergency accounts from MFA to avoid a dependency on the Azure MFA service. If the service went down, your password still worked.
However, Microsoft has begun enforcing Mandatory MFA at the tenant level for all admin portals. This enforcement phase (Phase 1 began Oct 2024) overrides Conditional Access exclusions.
The Risk: If you rely on a password-only account, one of two things will happen during a crisis:

  1. You will be blocked from signing in because the account lacks Strong Authentication.
  2. You will be forced to register for MFA on the spot, exactly what you can’t do if the service is degraded.

The Fix: FIDO2 Hardware Keys

It’s now recommended to provision two emergency accounts secured with FIDO2 hardware keys (e.g., YubiKeys).

  • Compliance: FIDO2 satisfies the “Strong Authentication” requirement, bypassing the mandatory MFA block.
  • Resilience: It does not rely on cellular networks, mobile batteries, or the standard Azure MFA backend service (like push notifications or SMS).

Configuration: The “Safe” Architecture

To build a robust emergency access system, you need to isolate these accounts from your standard infrastructure.

1. Identity Basics

  • Cloud-Only: These accounts must never be synced from on-premises AD. If your on-prem environment is compromised or offline, your cloud admin access must survive.
  • Domain: Always use the *.onmicrosoft.com domain. This removes dependencies on your public DNS registrars and federation services.
  • Redundancy: Create a minimum of two accounts. Store the physical keys in geographically separate, secure locations (e.g., a physical safe at the office and a bank deposit box).

2. The “Moat”: Conditional Access Exclusions

Even though you are using FIDO2, you must still rigorously exclude these accounts from ALL Conditional Access policies.

  • Why? Policies like “Compliant Device Required” or “Block Non-US Locations” can create logic loops during an outage.
  • How: Add the specific Object IDs of your emergency users to the Exclude list of every single policy.

Monitoring: The “Tripwire”

Because these accounts are excluded from your security policies, they are high-risk targets. They must never be used for routine administration. They are “sleeping” accounts.
You need a “tripwire”: An alert that screams if these accounts ever wake up.
I recommend connecting your Entra Sign-in Logs to Azure Monitor (Log Analytics) or Microsoft Sentinel. Configure a Sev0 (Critical) alert to trigger if any sign-in attempt is detected.

The KQL Query

Use the following KQL query to detect activity on your specific Break Glass accounts:

SigninLogs
| where UserId in ("00aa00aa-bb11-cc22-dd33-44ee44ee44ee", "11bb11bb-cc22-dd33-ee44-55ff55ff55ff")
| project TimeGenerated, UserPrincipalName, ResultType, ResultDescription, IPAddress, Location, AppDisplayName
| sort by TimeGenerated desc

Note: Replace the GUIDs with the actual Object IDs of your emergency users.

Validation: The 90-Day Fire Drill

A Break Glass account that hasn’t been tested is just a hope, not a strategy.
Implement a 90-day validation rule:

  1. Physical Retrieval: Physically retrieve the hardware key from its secure storage.
  2. Sign In: Log in to the Azure Portal using the FIDO2 key. This confirms the credential works and the account hasn’t been disabled or deleted.
  3. Verify the Alert: Confirm that your SOC or Admin team received the “Tripwire” alert (Email/SMS) within 5 minutes.
  4. Document: Log the test for your compliance audit.

Conclusion

The era of the “password in an envelope” is over. By shifting to FIDO2 keys, you satisfy Microsoft’s modern security baseline while maintaining the independence required for a true emergency account.
Audit your current Break Glass accounts today. If they are password-only, you are sitting on a ticking time bomb.

Tags :
Share :