Break Glass Accounts in Entra ID: How to Never Lose Tenant Access Again

TL;DR: A single misconfigured Conditional Access policy can lock every admin out of your tenant simultaneously — and Microsoft Support recovery takes 3–7 business days. Break glass accounts are the only protection, but only if built correctly: cloud-only accounts on .onmicrosoft.com, FIDO2 hardware keys from different vendors, permanently active Global Admin role (not PIM eligible), and Azure Monitor alerts that fire the moment anyone signs in. This guide covers everything without skipping the edge cases that bite you.

The Problem

The Microsoft Q&A forum has a recurring thread type: "URGENT — Global Administrator locked out after enabling Conditional Access." One admin pushed a CA policy requiring Intune-compliant devices for all administrators. The problem: none of the admin devices were enrolled in Intune yet. Result: complete tenant lockout. The support ticket sat in the "Data Protection / Tenant Recovery" queue for 72 hours before a Microsoft engineer looked at it.

In early 2025, Microsoft itself caused a mass lockout across thousands of organizations. A botched rollout of MACE Credential Revocation — a feature designed to detect leaked credentials — generated false positives and automatically locked accounts at scale. One MDR provider reported over 20,000 notifications from different customers in a single night. Accounts protected by strong unique passwords and active MFA were locked with zero evidence of actual compromise.

Organizations with properly configured break glass accounts survived this incident without significant impact. Everyone else waited in Microsoft's support queue.

Common lockout triggers in production environments:

• Conditional Access policy that blocks all admins (wrong compliance requirement, missing MFA registration, location condition pointing to an unavailable network)
• Federation outage — AD FS or a third-party IdP like Okta or Ping Identity goes down; federated accounts become inaccessible regardless of Entra availability
• MFA service disruption — all admins registered to the same MFA method; when that method fails, nobody can authenticate
• Last Global Admin leaves the organization without transferring credentials
• Microsoft-side incidents like the MACE rollout

The critical point: a tenant lockout cannot be resolved from inside the tenant once all admins are blocked. You must open a support case through Microsoft's "Data Protection / Tenant Recovery" path — which takes 3–7 business days, during which your tenant is effectively unmanageable.

Why This Happens

Entra ID's built-in lockout protection is intentionally narrow: it prevents deleting the last Global Administrator account. That's the entire protection surface. There's nothing preventing:

Conditional Access from blocking all admins simultaneously. CA evaluates every sign-in, including admin sign-ins. There's no "admin override" mode. If the policy says "require compliant device" and no admin device meets the condition, everyone is blocked — including the person who created the policy. Entra doesn't know that logically you need access to fix the mistake; it just enforces the policy.

Federated accounts becoming inaccessible during IdP outages. Accounts synchronized from on-premises Active Directory authenticate through your identity provider. When AD FS goes down, the SAML trust breaks, or the Okta tenant has an incident — those accounts can't authenticate at all, regardless of Entra's own availability. Cloud-only accounts on the .onmicrosoft.com domain authenticate directly against Entra and have no dependency on your on-premises infrastructure.

PIM-eligible role activation requiring MFA in an MFA outage. If your Global Administrator assignments are eligible (requiring PIM activation) rather than permanently active, you need MFA to activate the role. No MFA → no role → no access. Classic chicken-and-egg deadlock.

Old break glass accounts that stopped working in May 2024. Microsoft began enforcing mandatory MFA for all Global Administrator sign-ins to admin portals (Azure Portal, Intune, Entra admin center) starting May 2024. Accounts that relied solely on passwords — including break glass accounts created years ago — stopped working for portal access from that point forward.

Configuration Step by Step

Step 1: Create Two Break Glass Accounts

Two accounts minimum. One FIDO2 key can physically fail. One account can get accidentally locked by a cleanup script. You may need to isolate one account after a security incident while using the other to investigate.

Requirements for both accounts:

• Domain: your-tenant.onmicrosoft.com — not your custom domain, not synchronized from on-premises AD
• Role: Global Administrator, permanently active — not eligible in PIM, not time-limited
• No M365 license required — licenses aren't needed for sign-in
• Not tied to any individual person — the account belongs to the organization

On naming conventions: avoid anything that obviously identifies the account's purpose. Names like breakglass@, emergency@, or bg-admin@ are first-pass targets in password spray and credential stuffing attacks. Use something non-descriptive:

svc-infra-01@contoso.onmicrosoft.com
svc-cloud-mgmt@contoso.onmicrosoft.com

Creating accounts via Microsoft Graph PowerShell:

Connect-MgGraph -Scopes "User.ReadWrite.All","Directory.ReadWrite.All","RoleManagement.ReadWrite.Directory"

# Generate a strong password (80+ characters — serves as backup credential if FIDO2 is unavailable)
$password = "$(New-Guid)-$(New-Guid)-$(New-Guid)"

$passwordProfile = @{
    Password = $password
    ForceChangePasswordNextSignIn = $false
}

$user1 = New-MgUser `
    -DisplayName "Infra Service Account 01" `
    -UserPrincipalName "svc-infra-01@contoso.onmicrosoft.com" `
    -AccountEnabled $true `
    -PasswordProfile $passwordProfile `
    -PasswordPolicies "DisablePasswordExpiration,DisableStrongPassword"

Write-Host "Account 1 Object ID: $($user1.Id)" -ForegroundColor Green
Write-Host "STORE THIS PASSWORD IN A PHYSICAL SAFE: $password" -ForegroundColor Yellow

# Assign Global Administrator role — permanently active, NOT via PIM eligible assignment
$gaRole = Get-MgDirectoryRole | Where-Object {$_.DisplayName -eq "Global Administrator"}
New-MgDirectoryRoleMember -DirectoryRoleId $gaRole.Id `
    -BodyParameter @{"@odata.id" = "https://graph.microsoft.com/v1.0/directoryObjects/$($user1.Id)"}

Write-Host "Global Administrator role assigned permanently." -ForegroundColor Green

Record the Object ID of both accounts — needed for monitoring configuration later.

Step 2: Configure FIDO2 Hardware Keys as the Authentication Method

Break glass accounts must not use Microsoft Authenticator (requires a functional device and app), SMS/voice (SIM swap risk, mobile network dependency), or TOTP apps (registered-device dependency). The only appropriate method for break glass accounts: a physical FIDO2 security key.

Why FIDO2 is the right choice for break glass:

• Hardware-based: works when phone, email, and mobile network are all unavailable
• Phishing-resistant: cryptographic keys are domain-bound, can't be stolen via phishing
• No expiry date: unlike certificates, FIDO2 keys don't have validity periods to track
• Satisfies Microsoft's Mandatory MFA requirement (enforced May 2024 for Global Admins)

Key selection: Buy two keys from different vendors — e.g., YubiKey 5 NFC for account 1 and a Nitrokey 3 or Token2 key for account 2. A firmware bug or manufacturing defect at one vendor shouldn't disable both accounts simultaneously.

To register a FIDO2 key on a break glass account:

1. Sign in to the break glass account in an InPrivate/incognito browser (avoid session conflicts with your regular admin account)
2. Navigate to myprofile.microsoft.com → Security info → Add sign-in method
3. Select "Security key" and complete the registration flow

Important ordering: Register FIDO2 keys before adding accounts to Conditional Access exclusions. Configuring exclusions before registration creates a window of inconsistent policy state.

Step 3: Exclude Accounts from Conditional Access Policies

Recommended exclusion strategy:

• Account 1: excluded from all CA policies. FIDO2 key stored in an on-site physical safe.
• Account 2: covered by one dedicated CA policy requiring FIDO2 authentication strength only. FIDO2 key in a separate physical location.

After configuring exclusions, validate using the What-If tool — this step is not optional:

• Entra admin center → Protection → Conditional Access → What If
• Set: User = svc-infra-01, Apps = All cloud apps, all other conditions at defaults
• Expected result: zero policies applied, or only the dedicated break-glass FIDO2 policy
• If any other policy appears: fix the exclusion before proceeding

Run this What-If check every time you add or modify a CA policy. One missed exclusion during a routine policy update is enough to silently remove break glass protection.

Step 4: Configure Monitoring in Azure Monitor

Most administrators skip this step entirely. Without monitoring, you won't know that someone signed into a break glass account — whether it was a legitimate emergency use, an accident, or an attacker who obtained the credentials.

First, configure Entra ID to send sign-in logs to a Log Analytics Workspace: Entra admin center → Monitoring → Diagnostic settings → Add diagnostic setting → check SignInLogs and AuditLogs → send to Log Analytics Workspace.

Then create an alert rule using this KQL query:

// Alert on any sign-in attempt to break glass accounts (success or failure)
SigninLogs
| where TimeGenerated > ago(5m)
| where UserPrincipalName in (
    "svc-infra-01@contoso.onmicrosoft.com",
    "svc-cloud-mgmt@contoso.onmicrosoft.com"
)
| project
    TimeGenerated,
    UserPrincipalName,
    IPAddress,
    Location,
    AppDisplayName,
    ResultType,
    ResultDescription,
    DeviceDetail,
    ConditionalAccessStatus
| order by TimeGenerated desc

Alert rule settings that matter:

• Threshold value: 0 — trigger on any single result
• Evaluation frequency: 1 minute
• Lookback period: 5 minutes
• Severity: Critical (Sev 0)
• Action Group: email + SMS to all Global Administrators, plus an ITSM ticket if you have that integration

Alert on both successful and failed sign-ins — a failed attempt on a break glass account is worth investigating just as much as a successful one.

Step 5: Physical Credential Storage

A break glass account is worthless if you can't locate the FIDO2 key and PIN during an actual emergency. This is the operational part most IT teams underinvest in.

Account 1 (excluded from all CA):

• FIDO2 key + PIN written on paper: sealed envelope in a server room safe or equivalent
• Password (backup credential): separate sealed envelope held by IT Director or CTO
• Emergency procedure documentation: wiki page with account name and "where to find credentials" only — never the credentials themselves

Account 2 (covered by FIDO2 CA policy):

• FIDO2 key + PIN: different physical location — secondary office, bank safety deposit box, offsite facility
• Password (backup): different authorized individual

Never store both keys in the same location. A fire or physical theft of one safe should not eliminate access to both accounts simultaneously.

Step 6: Quarterly Testing — Every 90 Days

Schedule a recurring calendar event — not a reminder to schedule a test, an actual calendar block with a named owner:

1. Retrieve the FIDO2 key from its storage location
2. Sign in to the break glass account in an InPrivate browser
3. Confirm access to Entra admin center and Azure Portal
4. Verify that the Azure Monitor alert fired within 1–2 minutes of sign-in
5. Confirm that all Global Admins received the notification
6. Document the test: date, tester name, result, any issues found
7. Return the key to its secure storage location

Without quarterly testing you have no confirmation that: the FIDO2 key still works, the PIN hasn't been forgotten, the account wasn't accidentally disabled by a cleanup script, the monitoring is still properly configured, or the action group notification contacts are still current.

Common Pitfalls and Edge Cases

Pitfall 1: Eligible PIM Role Instead of Permanently Active

If the Global Administrator role is eligible on a break glass account, you've defeated the entire purpose. In an emergency, you still need to go through PIM activation — which requires MFA. If MFA is what's broken in your emergency, the role is unreachable.

Verify the assignment type:

# Check whether break glass accounts have permanently active (not eligible) GA role
$gaRoleDefinitionId = "62e90394-69f5-4237-9190-012177145e10"  # Global Administrator role definition ID

$activeAssignments = Get-MgRoleManagementDirectoryRoleAssignment `
    -Filter "roleDefinitionId eq '$gaRoleDefinitionId'"

Write-Host "Permanently active Global Admin role assignments:"
$activeAssignments | ForEach-Object {
    $user = Get-MgUser -UserId $_.PrincipalId `
        -Property DisplayName,UserPrincipalName -ErrorAction SilentlyContinue
    if ($user) {
        Write-Host "  $($user.UserPrincipalName) - $($user.DisplayName)"
    }
}

# If your break glass accounts don't appear in this output,
# their role is eligible-only. Fix this before moving on.

Pitfall 2: Legacy Break Glass Accounts That Stopped Working in May 2024

Microsoft's mandatory MFA enforcement for admin portal sign-ins (Azure Portal, Intune, Entra admin center) became effective in May 2024 for all Global Administrator accounts — including break glass accounts. Password-only authentication no longer works for portal access, regardless of CA policy exclusions.

If you have break glass accounts set up before mid-2024 with only password configured: they're non-functional for tenant administration right now. Register FIDO2 keys on these accounts as your highest priority remediation item.

Pitfall 3: Group-Based CA Exclusions That Break Silently

A common pattern: break glass accounts added to a security group, that group excluded from CA policies. The vulnerability: any admin doing routine group membership cleanup can remove an account from the group without understanding the consequences. The account silently loses its CA exclusion — no alerts, no policy violations triggered — and is now subject to all the same Conditional Access requirements as regular users.

Better approaches:

• Exclude accounts directly by UPN in each CA policy — eliminates the group-membership dependency entirely
• If you use a group: protect it with a Restricted Management Administrative Unit (RMAU) so that modifying group membership requires explicit delegation, not just standard group admin rights
• Run the CA What-If check on both break glass accounts as part of every quarterly test

Pitfall 4: No Monitoring — Account Repurposed as a Regular Admin Account

Real-world scenario: during a security review, an IT admin discovered break glass account sign-in events from four months prior. Investigation found that a colleague had used the account because they forgot their regular admin password — and told no one. For four months, the team had no idea whether the break glass account had been compromised, what actions had been taken with Global Admin rights, or whether credentials needed rotation.

Every break glass sign-in requires an immediate response: identify who used it and why, audit every action taken during that session, rotate credentials if the use wasn't authorized. Without Azure Monitor alerts this entire response process never starts.

Pitfall 5: Certificate-Based Authentication with Untracked Certificate Expiry

Some organizations configure certificate-based authentication (CBA) as the MFA method for break glass accounts instead of FIDO2 keys. This is technically acceptable if your PKI is mature — but certificates expire. Break glass accounts are tested only every 90 days. If no one tracks the certificate expiration date, it can expire between test cycles. In an actual emergency, you discover mid-crisis that the authentication method is expired.

If you choose CBA over FIDO2: set calendar alerts at 60 and 30 days before certificate expiry, include certificate validity verification in your quarterly test checklist, and document the renewal procedure so it can be done under pressure.

Summary

• Two cloud-only accounts on .onmicrosoft.com — no federation dependency, no on-premises AD dependency
• FIDO2 keys from two different vendors — meets Mandatory MFA (May 2024+), phishing-resistant, hardware-based with no phone dependency
• Permanently active Global Administrator role — not eligible, not time-limited, no PIM activation required in an emergency
• What-If validation after every CA policy change — one account outside all policies, one covered only by the FIDO2 policy
• Azure Monitor alert on every sign-in attempt — Severity 0, immediate notification to all Global Admins plus ITSM ticket
• Physical key separation — different locations, different vendors, different authorized individuals
• Quarterly testing with documentation — sign in, verify alert fires within 2 minutes, document the test date and result
• DisablePasswordExpiration explicitly set — default 90-day password expiry will silently make backup credentials useless