Your break-glass account probably can't sign in anymore. Test it this quarter.

Your organization has a break-glass account. It’s named in a document, maybe with a password in a vault, created during tenant setup by someone who has since moved on. The last time anyone signed into it was never.

That’s the account you’re betting on the day a Conditional Access policy locks every admin out, your identity provider goes dark, or the MFA service stops answering. And there’s a good chance it no longer works, for a reason that didn’t exist two years ago. Mandatory Microsoft Entra MFA now gates the Azure and Entra admin portals for every account, break-glass included. A password-only emergency account that was best practice in 2023 hits an MFA prompt it can’t answer and leaves you locked out during the one event it exists for.

An emergency account you have never tested is not a safety net. It’s a document that describes one.

Microsoft’s emergency-access guidance is specific and was refreshed this year. This runbook turns it into something you can audit, fix, and put on a recurring test.

Who this affects

Any Microsoft Entra ID or Microsoft 365 tenant. It bites hardest in three cases: you federate to on-premises AD FS or another identity provider, where an IdP outage is one of the exact scenarios break-glass exists for; you enforce MFA and Conditional Access broadly; or you stood up the emergency account before mandatory MFA landed and never revisited it.

The timing matters. Phase 2 mandatory Azure MFA enforcement began October 1, 2025 for the CLI, PowerShell, and REST paths, and the last postponement window closed July 1, 2026. As of now it is in force with no opt-out, and Microsoft’s own FAQ confirms the enforcement “applies to all user accounts, regardless if they are a student account, break-glass account” or anything else. The same enforcement wave that’s closing Entra’s identity opt-outs is why the password-in-a-safe model quietly stopped working.

Check whether yours actually works

Five questions. Each one has a failure mode that turns a “we have a break-glass account” into a locked tenant.

1. Can it pass the MFA gate right now? The real test is not “is the password in the vault.” It is whether the account has a registered phishing-resistant method. Open the account under Entra ID > Users > [account] > Authentication methods. If a passkey (FIDO2) or certificate-based credential is not registered, the account cannot clear the portal MFA prompt, and a password alone is now a locked door. This is the most common silent failure today.

2. Is it cloud-only? The UPN must be on the *.onmicrosoft.com domain and the account must not be synced from on-premises. Microsoft is explicit that these accounts should be “cloud-only accounts that use the *.onmicrosoft.com domain and that aren’t federated or synchronized.” A synced emergency account dies with your on-prem AD or AD FS during the outage you built it to survive.

3. Is it excluded from the policies that would block it? “Excluded from Conditional Access” is too vague to trust. Check each CA policy that blocks or restricts sign-in and confirm your emergency-access group sits in its exclusions. Report-only policies don’t block access and don’t need the exclusion. One blocking policy that forgot the exclusion is enough to trap the account.

4. Can you activate the role without a human in the loop? If the Global Administrator role is PIM-eligible behind an approval workflow, and the approvers are the admins who are locked out, the account is decorative. Microsoft’s guidance is to make the role assignment “active permanent rather than eligible” for break-glass.

5. Does anyone find out when it’s used? Sign in with it and watch for an alert. If nothing lands in an inbox or on a phone, you are running an unmonitored Global Administrator account, which is a problem on its own.

Build it right

If the audit turned up gaps, rebuild to this checklist. The sequence matters, because a couple of these steps lock you out of finishing if you do them out of order.

• Two accounts, minimum. Cloud-only, on *.onmicrosoft.com, not synced. Two so a single lost key or disabled account still leaves a way in.
• Global Administrator, permanent active in PIM. Not eligible, no activation approval.
• A phishing-resistant method on each account. FIDO2 security key is the default; certificate-based auth if you already run PKI. Use a Temporary Access Pass to bootstrap the FIDO2 registration, then remove the TAP. Pick a different method family than your daily admin accounts use, so a compromise of one does not reach both.
• A dedicated EmergencyAccess security group, excluded from every CA policy that blocks or restricts sign-in. Leave report-only policies alone. Exclude the same group from any contingency policies you build.
• Exempt the account and its key from password expiry and inactivity cleanup. Microsoft warns the credential “must not expire or be in scope of automated cleanup due to lack of use.” An account you touch once a quarter is exactly what a stale-account job deletes.
• Split-store the credentials. Two FIDO2 keys in two separate, secure, fireproof locations, per Microsoft’s storage guidance. Account details known to more than one administrator, tied to no individual’s phone or personal detail.
• Wire the sign-in alert (query below) at Severity 0.
• Write the procedure down. Who is authorized, where the keys are, what to do. During a lockout is the wrong time to discover the runbook was in the wiki behind the SSO you can’t reach.

The quarterly drill

A build you never exercise decays. Keys wander, a new CA policy ships without the exclusion, the alert rule silently breaks, someone with safe access leaves. Microsoft’s floor is validating these accounts “at least every 90 days” and testing “every quarter” that they can still sign in under your current Conditional Access configuration. Practitioners who audit these for a living report that untested legacy accounts are one of the three most common failures, alongside no account at all and no monitoring.

The drill has one rule: prove the account works without using it to change anything, and without weakening the policies protecting everyone else. You are testing the fire alarm, not setting a fire.

Run this once a quarter, per account:

1. Tell security monitoring a drill is running. Otherwise the Severity-0 alert reads as a live breach and someone burns an evening on it.
2. From a clean, isolated session (a private window or a privileged access workstation), sign in to the Entra admin center with account #1 using its FIDO2 key. Complete the full MFA flow. “The password works” is not a pass, because mandatory MFA now gates the portal.
3. Confirm Global Administrator is live. The role should already be permanent active. Verify it, don’t rely on memory.
4. Do one trivial read to confirm the session has real rights, open Users or read a policy, then sign out. Make no changes.
5. Confirm the alert fired and reached the on-call inbox or phone. A sign-in that triggers no alert is a failed drill even if the sign-in succeeded.
6. Repeat for account #2 using its own key from its own location. This is the step that catches both keys living in one drawer.
7. Verify no MFA or SSPR method is bound to an individual’s device or personal detail. People and phones leave; the account can’t depend on them.
8. Check the account and key aren’t drifting toward an expiry or cleanup window.
9. Log the result with a date. Rotate the safe combination if anyone with access has left since the last drill.

The sign-in alert that step 5 tests comes straight from Microsoft’s monitoring guidance. Ship your Entra sign-in logs to a Log Analytics workspace, then create an alert rule on this query with both accounts’ object IDs, threshold static, greater than 0, severity 0 - Critical:

SigninLogs
| where UserId == "00aa00aa-bb11-cc22-dd33-44ee44ee44ee" or UserId == "11bb11bb-cc22-dd33-ee44-55ff55ff55ff"
| project TimeGenerated, UserPrincipalName, UserId, IPAddress, ResultType, ResultDescription

Any hit that isn’t a scheduled drill or a declared emergency is an incident. Microsoft’s model pairs the alert with a post-mortem review after every use to classify it as drill, real emergency, or misuse.

When it becomes an incident

Escalate out of the routine checklist when any of these show up. A break-glass sign-in you can’t tie to a drill or a declared outage: preserve the logs, run the post-mortem, regenerate the credentials, and re-secure the keys before you close it. A tenant where both emergency accounts fail the drill: you no longer have a break-glass path, and that is a same-day fix, not a next-sprint ticket. And a live lockout where no working emergency account exists, the case Microsoft’s resilient-access guidance is written to prevent, drops you into contingency CA policies and, past those, a tenant-lockout case with Microsoft Support while the business waits.

The account is cheap to build and cheaper to test. The version of this that hurts is the one nobody ran until the day it was the only way back in.

Sources

• Manage emergency access admin accounts - Microsoft Entra ID — 2026-06-04
• Plan for mandatory Microsoft Entra multifactor authentication (MFA) — 2026-04-03
• Create a resilient access control management strategy - Microsoft Entra ID — 2025-03-04
• Break-Glass Accounts Done Right: Securing Emergency Access in Microsoft Entra
• Break Glass Account With Phishing-resistant MFA in Entra ID
• Best Practices for Break Glass Accounts in Microsoft Entra