Key points
- Exempt from SSO and federation (so it works when the IdP is down)
- Credentials split, sealed, and stored offline
- Every use triggers SIEM alert and post-incident review
- Required by SOC 2, ISO 27001, and FedRAMP audits
- Typically two or more accounts per critical system
What it is
Break-glass accounts are the in case of fire, break glass of identity. They're local admin accounts on critical systems — IdP tenant, cloud master account, payment processor — that bypass SSO so they remain usable when the SSO provider itself is unavailable.
How it works
Credentials are generated, written down or stored in a sealed envelope / offline password manager, and split between two trusted owners (Shamir-style or two-person rule). The accounts are exempt from SSO and Conditional Access. Every authentication triggers an alert in SIEM. After use, the credential is rotated and re-sealed.
When buyers care
- IdP outages (the 2022 Okta and 2023 Auth0 incidents)
- Cloud root account recovery
- Ransomware response where normal IAM is compromised
- Audit requirements for documented emergency procedures
Common misconceptions
- Break-glass is not a backup for sloppy access management. It's an outage-resilience and recovery control.
- Don't store break-glass passwords in the same SSO-protected vault. That defeats the purpose.
FAQ
How many break-glass accounts do I need?
At minimum two per critical system, owned by different humans, stored in different physical locations.
Should break-glass accounts have MFA?
Yes — but with a factor that doesn't depend on the failing system (hardware key stored offline, not a phone-based push tied to the broken IdP).