Break-glass accounts should be boring, visible, and tested

Emergency access accounts exist for the day the normal identity path stops working. If they share the same federation, authentication method, device dependency, or approval chain as ordinary administrators, they are not a recovery path. They are another part of the outage.

Microsoft’s current guidance recommends two or more emergency access accounts. The practical design goal is simple: create a small, independent path into the tenant, make every use noisy, and test it before an incident does.

Remove shared failure modes

Emergency accounts should be cloud-only users on the tenant’s onmicrosoft.com domain rather than identities synchronized or federated from another system. That keeps an on-premises directory or identity-provider outage from taking the recovery accounts down with everything else.

Authentication needs the same treatment. Microsoft currently recommends phishing-resistant methods such as FIDO2 passkeys or certificate-based authentication. The selected method should not depend on the same device, network, or service used by normal administrator accounts. Credentials and devices must also be protected from expiry and automated cleanup.

These accounts are unusual by design. Microsoft recommends a permanent active Global Administrator assignment rather than an eligible assignment that could depend on an unavailable approval workflow. That exception raises the stakes for storage, monitoring, and testing.

Exclude with intent

Emergency accounts should be excluded from Conditional Access policies that can block or restrict sign-in. A compliant-device requirement, unavailable MFA dependency, or location rule can make the account useless during the exact event it is supposed to handle. Report-only policies do not block access and do not require the same exclusion.

Keep the exception narrow and reviewable. Use a dedicated emergency-access group, document why it is excluded, and prevent the account from becoming a convenient route around normal administration controls. Routine work should continue through named administrator identities and privileged-access processes.

Make every event visible

An emergency account should be quiet enough that any activity is suspicious or planned. Alert on sign-ins and relevant audit events, including credential, authentication-method, group, and role changes. Route alerts to people who can investigate without relying on the account being monitored.

After any use, preserve the logs and review why the account was used, what actions were taken, and whether the event was a drill, a real emergency, or unauthorized activity. Monitoring only failed sign-ins misses the event that matters most: successful privileged access.

Test the complete recovery path

Microsoft recommends validation at least every 90 days and after important staffing or subscription changes. A useful drill checks more than whether the password or passkey works:

1. Confirm the authorized-user list and recovery documentation are current.
2. Sign in from the designated secure workstation and expected network paths.
3. Verify the account can perform the minimum administrative task needed for recovery.
4. Confirm sign-in and audit alerts reach the right responders.
5. Check that no personal device or individual recovery detail has been attached to the account.
6. Record the result, fix failures, and rotate physical access when authorized staff change.

What to verify in your tenant

This article was not lab-tested. Before changing emergency access, verify the current Microsoft guidance, mandatory MFA requirements, authentication-method dependencies, Conditional Access exclusions, alert delivery, secure credential storage, and privileged-workstation process in your own tenant. A recovery account that has not completed an end-to-end drill is still an assumption.