When the identity provider is down, MFA is broken or administrators are locked out, someone still needs to get in. Break-glass (emergency access) accounts provide that route. They are also some of the most dangerous accounts an organisation owns: highly privileged, often excluded from normal controls and rarely used, which means misuse can go unnoticed. This guide explains how to design, protect, test and monitor break-glass access for cloud directories, on-premises systems, PAM and critical applications.
Key takeaways
- Keep a small number of break-glass accounts (commonly two per critical platform), independent of the systems they are meant to recover.
- Protect them with phishing-resistant, independent authentication, such as FIDO2 security keys held in secure physical storage, not the same MFA path that might fail.
- Alert on every use. Break-glass sign-ins should wake someone up.
- Test regularly and after changes. An emergency account that does not work in an emergency is worse than useless.
When break-glass is needed
- Identity provider or federation outage.
- MFA service outage or misconfiguration locking out administrators.
- Conditional access policy error blocking all admins.
- Loss of the only administrators (departure, incident, account compromise).
- PAM platform outage preventing credential retrieval.
- Cyber incident where normal admin accounts may be compromised.
Designing break-glass accounts
- Independence: cloud-only accounts that do not depend on on-premises federation or synchronisation; local accounts for critical on-premises systems.
- Minimal number: usually two per platform, so one can be used while the other is protected.
- Clear naming that does not advertise purpose to attackers scanning directories, while being documented internally.
- Exclusion design: exclude from conditional access policies that could lock them out, but still require strong authentication; review exclusions carefully.
- No day-to-day use: never used for routine administration, email or browsing.
Protecting credentials
- Use FIDO2 security keys or certificate-based authentication for each account, stored in separate secure physical locations (for example, safes at two sites).
- If passwords are also used, make them long and random, split between custodians (dual control) and stored securely offline.
- Do not store break-glass credentials only in the PAM platform or password manager that might itself be unavailable.
- Record custody: who holds what, and when it was last checked.
Monitoring
- Alert immediately on any sign-in, attempted sign-in or change to break-glass accounts, to several people through channels independent of the identity platform.
- Alert on changes to exclusions, authentication methods or role assignments for these accounts.
- Investigate every use, even tests, and record the reason.
Testing
- Test each account on a schedule (for example, quarterly) and after major identity platform or policy changes.
- Verify authentication works, the account retains required roles and alerts fire.
- Rotate secrets after each use or test where appropriate.
After use
- Record who used it, when, why and what was done.
- Review all actions taken during the session.
- Rotate credentials and re-secure physical tokens.
- Fix the root cause that required emergency access.
Break-glass beyond the directory
- PAM platforms: an emergency procedure for retrieving vaulted credentials if the vault is unavailable. See the PAM Buyer's Guide.
- Cloud root and organisation accounts: secure the root user or equivalent with hardware MFA and alerting.
- Critical applications: emergency admin access for payment, ERP and operational technology systems.
- Automation: do not give AI agents or scripts access to break-glass credentials.
Common failure patterns
- Break-glass accounts that depend on the same federation or MFA service they are meant to bypass.
- Emergency accounts used for routine work because it is convenient.
- No alerting, so misuse goes unnoticed.
- Accounts never tested, discovered not to work during an outage.
- Credentials held by one person who has left.
Practitioner checklist
- Define break-glass accounts for each critical platform, independent of the systems they recover.
- Protect them with phishing-resistant authentication and secure, split physical custody.
- Exclude them from lockout-prone policies deliberately and document why.
- Alert on every use and change through independent channels.
- Test on a schedule and after changes; rotate after use.
- Review every use and fix root causes.
Standards and references
- Microsoft: Manage emergency access accounts in Entra ID
- NIST SP 800-53 Rev. 5 (AC-2 Account Management)
- CISA: Implementing Phishing-Resistant MFA
Related NHI Mgmt Group resources: Privileged Access Management Guide · Active Directory and Entra ID Hardening Guide · IdP and SSO Security Guide · JIT Access Guide
