Privileged access
Break-glass accounts
The accounts you keep for when normal administration fails. What the standards say, what is only common practice, and how to keep them usable without making them a backdoor.
A break-glass account (also called an emergency access account) is a highly privileged account kept for when the normal way of administering a system has failed. Typical triggers: the identity provider is down, a federation certificate expired, an MFA service is unavailable, or a bad access policy locked every administrator out. Break-glass accounts are deliberately outside some normal controls, so they need different controls of their own. This page separates what the standards say from what is common practice, and says which is which.
What the standards say, and a distinction they make
SP 800-53 Rev. 5 discusses emergency accounts in AC-2 (Account Management). The AC-2 discussion says organizations establish emergency accounts "in response to crisis situations and with the need for rapid account activation", and that emergency activation "may bypass normal account authorization processes". It also lists emergency accounts among the types organizations may wish to prohibit because of increased risk.
AC-2(2) then asks that temporary and emergency accounts be removed or disabled automatically after an organization-defined period.
The same discussion draws a distinction that matters for how most organizations actually build break-glass access:
Emergency and temporary accounts are not to be confused with infrequently used accounts, including local logon accounts used for special tasks or when network resources are unavailable (may also be known as accounts of last resort). Such accounts remain available and are not subject to automatic disabling or removal dates.
A pre-provisioned cloud or identity-provider break-glass account, created in advance and kept ready, behaves like an account of last resort in this vocabulary. It is not an emergency account created during the crisis and auto-disabled afterwards. Both patterns are legitimate. Decide which one you are building, because the controls differ:
| Emergency account (AC-2, AC-2(2)) | Account of last resort (AC-2 discussion) | |
|---|---|---|
| When it exists | Created or enabled during the crisis. | Exists all the time. |
| Ends how | Removed or disabled automatically after a defined period. | Not subject to automatic disabling. |
| Depends on | Someone (or something) able to create or enable it during the outage. | Only its own credentials. |
| Main risk | The path that creates it may be unavailable in exactly the failure you are planning for. | A standing, powerful account that attackers can target at any time. |
For US federal agencies, OMB M-22-09 expects agencies to "maintain exceptional procedures for emergency situations and account recovery processes". It describes recovery processes as a potential bypass of standard authentication that should require "high-friction methods that are costly for an adversary to overcome".
Designing break-glass accounts
The practices below are widely used for accounts of last resort in identity providers and cloud tenancies. Each row says whether it rests on a standard or is common practice.
| Practice | Why | Basis |
|---|---|---|
| Keep a small number, typically two | One may be unusable (lost key, custodian unavailable). More than a few becomes hard to monitor. | Common practice |
| Make them independent of the thing that might fail | Cloud-only accounts, not federated or synchronized from the on-premises directory, and not dependent on a single MFA provider or network location. | Common practice |
| Use phishing-resistant MFA, typically hardware security keys | A password alone is a standing, high-value secret. IA-2(1) requires MFA for privileged accounts, and phishing-resistant authenticators remove the remote-phishing route. | IA-2(1) for MFA; choice of authenticator is common practice |
| Exclude them only from the specific policies that could lock everyone out | Exclusions are what make the account work during an outage. Every exclusion is also a gap, so keep the list short and documented. | Common practice |
| Split knowledge and dual control of the credentials | No single person can use the account alone. | Related to AC-3(2) dual authorization; specific custody scheme is common practice |
| Alert on every sign-in and every use | There is no legitimate routine use, so any use is a signal. | AC-2(12) atypical usage, AC-6(9) logging privileged functions |
| Test on a schedule | An untested break-glass account is a guess. Credentials expire, keys get lost, policies change. | Common practice; aligns with AC-2 j account reviews |
| Rotate and review after every use | After use, assume the credential has been exposed. | IA-5 f (change authenticators when defined events occur) |
Exclusions: excluded from what, and why
The account is meant to work when something else does not, so it is usually excluded from policies that depend on fallible components:
- Federation or synchronization from another directory, so an on-premises outage or a broken trust does not take it down.
- Access policies that require a compliant or domain-joined device, a specific network, or a risk score from a service that might be unavailable.
- Automated disablement for inactivity, which would otherwise quietly remove it. AC-2(3)(d) leaves the inactivity period organization-defined, and the AC-2 discussion says accounts of last resort "are not subject to automatic disabling or removal dates".
Do not exclude it from logging, and avoid excluding it from MFA if you can. A common approach is to register hardware security keys directly on the account, so the second factor does not depend on any external MFA service.
Credential custody
Split knowledge means no single person knows the whole secret. Dual control means two people must act together to use it. A typical arrangement for one break-glass account:
Variations include storing the secret in an offline safe that requires two keyholders, or in a secrets manager whose own break-glass path does not depend on the identity provider. The important property is that the scheme still works during the outage you are planning for. A vault that needs the identity provider to unlock does not help when the identity provider is down.
Monitoring and testing
Monitoring
Because legitimate use is rare, alerting can be strict: any successful or failed sign-in, any MFA method change, any password reset and any role change on these accounts goes straight to the people on call. The alerting path should not depend on the system that might fail. If the identity provider's own alerting is down during an outage, you still want to know.
Testing
- On a schedule (quarterly is common; set your own), two custodians retrieve the credentials and sign in.
- Confirm that the account still holds the expected role and that the exclusions still apply after recent policy changes.
- Confirm that the alert fired and reached a human.
- Rotate the password, reseal the materials, and record the test.
After a real use
- Record who used it, when, from where and why. Correlate with the incident ticket.
- Review every action taken with the account (AC-6(9) logs).
- Rotate the password and, if a key left its sealed storage, consider re-registering it (IA-5 f).
- Re-seal custody materials and update the custody log.
- Fix the root cause that required it, so the next outage does not need it.
Common mistakes
- Break-glass accounts that are federated from the directory whose failure they are meant to cover.
- A password in a shared vault that every administrator can open, which makes it a shared admin account.
- Excluded from MFA and from logging "to keep it simple".
- Never tested, so the first real use discovers an expired password or a key nobody can find.
- Used for routine work because it is convenient. Once it is used routinely, it is no longer break-glass.
Sources
- NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations, NIST. Public domain (U.S. government work).
- OMB M-22-09: Moving the U.S. Government Toward Zero Trust Cybersecurity Principles, Office of Management and Budget. Public domain (U.S. government work).