Entra ID Break Glass Emergency Access Accounts: Missing, Unmonitored, Unexcluded

What Is an Entra ID Break Glass Emergency Access Account

An Entra ID break glass emergency access account is a Global Administrator account held in reserve for the one scenario every other admin path is designed to prevent: total lockout. Microsoft's own guidance lists the situations these accounts exist for — a federation outage that strands every synced admin, an MFA device or service outage that blocks role activation, the departure of the last active Global Administrator, a natural disaster taking out phone networks, or a Privileged Identity Management (PIM) approval deadlock where every eligible Global Administrator or Privileged Role Administrator assignment needs an approver and none are active. For a broader look at how PIM assignments and standing Global Admin counts drive tenant risk, see Azure Privileged Access: Too Many Global Admins.

None of these are exotic. They are the specific edge cases that "just use MFA" and "just use PIM" don't cover, because MFA and PIM are exactly what can fail.

The governance gap this article covers isn't the concept — most security teams have heard of break-glass accounts. It's that Microsoft's audit catalogue tracks three distinct, common ways the control fails in real tenants:

1. No emergency access account exists at all (PA_NO_EMERGENCY_ACCOUNTS) — the base case, and per EtcSec's catalogue the critical-severity default: zero break-glass coverage means zero recovery path if the primary admin path fails.
2. The account exists but isn't excluded from Conditional Access (PA_EMERGENCY_NO_EXCLUSION / CA_NO_BREAK_GLASS_EXCLUSION) — so the exact policy meant to protect the tenant is what locks the recovery account out during the emergency it was built for.
3. The account exists and is excluded, but nobody watches it (PA_EMERGENCY_NO_MONITORING) — so a sign-in event that should be a five-alarm fire (a Global Admin account outside normal CA controls just authenticated) generates no alert at all.

A fourth, related gap shows up in the same catalogue family: stale credentials (PA_EMERGENCY_CREDENTIAL_STALE) — an emergency account whose authentication method or device hasn't been validated in so long that nobody actually knows if it still works.

How the Gap Happens in Practice

Break-glass accounts are usually created once, during initial tenant setup or a compliance push, and then left alone — which is precisely the problem, because "left alone" cuts both ways.

Missing entirely

Smaller tenants, tenants migrated from an older identity provider, or tenants that assumed "our admins all have MFA" counts as coverage, frequently have zero dedicated emergency access account. Microsoft recommends creating two or more cloud-only accounts on the tenant's default *.onmicrosoft.com domain — not federated, not synced from on-premises — specifically so an on-prem or federation outage can't take out the recovery path along with everything else.

Not excluded from Conditional Access

This is the failure mode that turns a control into a trap. A CA policy that requires a compliant device, a specific MFA method, or blocks by location will happily apply to the emergency account like any other Global Administrator — meaning the exact policy that's supposed to protect the tenant becomes the reason the emergency account can't sign in during the outage or lockout it exists for. Microsoft is explicit here: exclude break-glass accounts from any CA policy that blocks or restricts sign-in; policies running in report-only mode don't block access and don't need the exclusion. This is a specific case of a broader pattern — see Entra ID Conditional Access Gaps for how exclusion scope mistakes show up across policies generally.

Not monitored

Even with an account correctly created and excluded, most tenants have no alerting on its use. A break-glass account is designed to almost never sign in. That property makes monitoring cheap and high-signal: any authentication from it is either a scheduled validation drill or an active incident (a legitimate emergency, or an attacker who found and compromised the one account explicitly carved out of your policy enforcement). Without a standing alert, that signal is invisible until someone happens to review sign-in logs — which for most tenants is rare or never. This blind spot sits alongside the broader risk-signal gaps covered in Azure Identity Protection: Blocking Leaked Credentials.

Detection

Confirm the state of break-glass emergency access account coverage against these checks, mapped to the catalogue entries:

Building the sign-in alert query

For the monitoring check specifically, Microsoft's documented approach is a Log Analytics custom-log alert rule against the SigninLogs table, keyed on the account's Object ID (found under Entra ID → Users → [account] → Object ID):

// Alert query — any sign-in from an emergency access account
SigninLogs
| where UserId == "00aa00aa-bb11-cc22-dd33-44ee44ee44ee" or UserId == "11bb11bb-cc22-dd33-ee44-55ff55ff55ff"
| project TimeGenerated, UserPrincipalName, UserId, IPAddress, ResultType, ResultDescription

Set the alert's Threshold value to 0 (greater than), Severity to 0 – Critical, and attach an action group that emails and SMS-pages your security team — because per Microsoft's guidance, any sign-in from this account should trigger review, whether it turns out to be a scheduled drill or an actual incident.

Also pull the account's audit log entries (not just sign-in log) — role assignment changes, credential registrations, and CA policy membership changes touching the account are all events worth alerting on independently of sign-in activity. If you're building out this kind of check as part of a broader tenant review rather than a one-off, How to Audit Microsoft Entra ID Security walks through the full review scope this fits into.

Remediation

1. Create at least two emergency access accounts. Cloud-only, *.onmicrosoft.com domain, not federated or synced. Microsoft's guidance recommends two or more so a single compromised or unavailable credential doesn't remove recovery capability entirely.
2. Use phishing-resistant, passwordless authentication. Passkey (FIDO2) is Microsoft's recommended method; certificate-based authentication is the alternative if your organization already runs a PKI. Do not reuse the MFA method your normal admin accounts use — if Microsoft Authenticator push is standard for admins, put the emergency account on a FIDO2 hardware key instead, so a single outage or compromise class can't take out both paths at once.
3. Assign Global Administrator as permanent, active — not eligible — in PIM. An emergency account gated behind a PIM activation step defeats the purpose if PIM itself is part of the outage.
4. Exclude the accounts from every Conditional Access policy that blocks or restricts sign-in. Create a dedicated security group (Microsoft's example name: EmergencyAccess) and exclude that group from enforced policies — report-only policies don't need the exclusion since they can't block access. Re-verify the exclusion list every time a new CA policy ships.
5. Wire up sign-in monitoring before you need it. Build the Log Analytics alert rule above, route it to a real action group (email + SMS, not a mailbox nobody watches), and set severity to Critical.
6. Store credentials in a secured, access-controlled location — physically separate, fireproof storage for hardware tokens or CBA certificates, accessible to more than one authorized person, tied to no single employee's device.
7. Validate every 90 days, and after any admin team change. Confirm the account still signs in successfully under the current CA configuration, confirm the alert still fires, and confirm the authorized-user list is current. Microsoft's guidance is explicit that this validation must happen at least every 90 days and after any staffing change — an emergency access account nobody has tested under real failure conditions isn't a working control, it's an assumption.
8. Run a post-mortem on every trigger, drill or real, to confirm the use was authorized and the actions taken matched the incident.

Break-glass coverage is one piece of a wider tenant hardening baseline — see Azure Tenant Hardening: Fix Insecure Default Settings for the other default-config gaps worth closing alongside this one.

How EtcSec Detects This

EtcSec's Entra ID audit checks for all three failure modes covered here: PA_NO_EMERGENCY_ACCOUNTS flags tenants with zero qualifying emergency access accounts, PA_EMERGENCY_NO_EXCLUSION (paired with CA_NO_BREAK_GLASS_EXCLUSION) flags accounts still in scope of an enforced Conditional Access policy, PA_EMERGENCY_NO_MONITORING flags accounts with no corresponding sign-in alert configuration, and PA_EMERGENCY_CREDENTIAL_STALE flags accounts whose credentials haven't been validated within the recommended window.