Setting up Entra ID break-glass accounts before touching Conditional Access

One of the golden rules when managing Microsoft 365 and Entra ID environments is simple: never create or edit a Conditional Access policy until your emergency break-glass accounts are tested and verified.

It only takes one misconfigured grant control, an inverted group exclusion, or an upstream outage at a federated IdP to lock every administrative user out of a production tenant. When that happens, calling Microsoft Support will not get you back in quickly—escalating a tenant lockout through Tier-3 data protection engineering can take days.

Every tenant needs two dedicated emergency access accounts configured to the following architecture:

1. Cloud-Only Identity

The accounts must be created directly in the cloud under the tenant’s default *.onmicrosoft.com domain namespace (e.g., [email protected]). Never synchronize these accounts from on-premises Active Directory and never federate them through third-party SSO. If your domain controllers, Entra Connect server, or SSO federation services go offline, cloud-only accounts can still authenticate.

2. Permanent Global Admin (Non-PIM)

Assign the Global Administrator role permanently. While Privileged Identity Management (PIM) is mandatory for normal administrators, break-glass accounts must bypass PIM entirely. If an Entra ID infrastructure issue impacts the PIM activation service or dependent approval workflows, emergency access must remain immediate.

3. Excluded from Every Conditional Access Policy

Create a dedicated cloud security group (e.g., SG-CA-Emergency-Exclusions) containing both break-glass accounts. In every single Conditional Access policy across the tenant, add this group under Users > Exclude.

4. Device-Bound Hardware FIDO2 Authentication

Protect each account with a 40+ character random password stored in an enterprise password safe, and register separate device-bound FIDO2 hardware tokens (such as a YubiKey 5 Series). Store the primary and secondary hardware keys in separate physical safes or locations. Never register them to an individual engineer’s mobile phone or Authenticator app.

5. Automated Real-Time Sign-In Alerting

These accounts should never authenticate during normal day-to-day operations. Route Entra ID Sign-In logs to Azure Monitor / Log Analytics and configure an alert rule:

SigninLogs
| where UserPrincipalName in ("[email protected]", "[email protected]")
| project TimeGenerated, UserPrincipalName, IPAddress, Location, ResultType

Any login attempt must immediately trigger a high-severity alert to the security operations team. If a break-glass account signs in and no scheduled maintenance was declared, treat it as an active compromise.