Break-glass accounts aren't just another MFA-protected admin

Every MSP eventually gets asked why a customer needs dedicated emergency-access accounts if every admin is already required to use multi-factor authentication. The answer is that break-glass accounts solve a different problem: staying usable when the identity provider or MFA system itself is unavailable, not adding another layer on top of a system that's already working.

What Microsoft recommends

Microsoft's guidance for Entra ID calls for at least two cloud-only emergency-access accounts, not synchronized from an on-premises directory or federated through an external identity provider — because an account that depends on the same infrastructure it's meant to rescue isn't really an emergency account. Microsoft recommends phishing-resistant authentication such as FIDO2 keys or certificate-based auth, deliberately independent from the methods routine admins use, and a permanent — not eligible or time-limited — Global Administrator role assignment in Privileged Identity Management, since an activation workflow is exactly what might not work during an outage. These accounts should still be covered by Conditional Access policies requiring phishing-resistant MFA; the recommended exclusion is from geolocation-based blocking specifically, not from access controls generally, given past cases of legitimate sign-ins being geo-misclassified for hours at a time.

What NIST and OWASP add

NIST SP 800-53's AC-2(2) control frames emergency accounts as something activated for a defined crisis and then automatically disabled or removed afterward, rather than standing indefinitely. OWASP's MFA guidance flags recovery and bypass processes as an attacker target in their own right: whatever mechanism restores access during an emergency must not quietly become a way to skip MFA under normal conditions.

What "prove it works" looks like

• Monitor sign-ins to these accounts specifically, with an alert on every attempt — successful or failed.
• Run access drills on a fixed schedule, commonly every 90 days, rather than assuming the setup still works.
• Write a short post-mortem after every real use or drill, and adjust the setup based on what it found.
• Document who can retrieve credentials and how, since redundancy without a retrieval process is not actually redundant.

An emergency-access design that has never been tested under simulated failure is not a safeguard — it's an assumption.

Sources: Microsoft Learn — emergency access accounts, NIST SP 800-53 Rev. 5.