Key takeaway: Break-glass accounts are deliberately exempt from the controls protecting everything else. That exemption is necessary, and it makes them the highest-value target you own.
Why They Exist
Every mature access model has a failure mode. The identity provider is unavailable. The conditional access policy blocks the only administrator. A misconfiguration locks everyone out of the cloud account.
Break-glass credentials solve this: a small number of accounts with full privilege, independent of the systems that might fail, usable when nothing else works.
The requirement is real. An organisation without one discovers during an outage that recovery requires the access the outage removed.
Why They Are Dangerous
The properties making them reliable are the same properties making them attractive.
| Property | Operational reason | Security consequence |
|---|---|---|
| Full privilege | Must fix anything | Complete compromise if taken |
| Independent of SSO | SSO may be the failure | No conditional access applies |
| Password-based | Federation may be down | Phishable and replayable |
| Rarely used | Emergency only | No baseline of normal activity |
| Widely known to exist | Must be findable in a crisis | Known target |
The rarity is the subtle problem. A credential used daily has a behavioural baseline, so anomalous use is detectable. A credential used twice a year has no baseline at all, and its use is either an emergency or an intrusion with no way to distinguish them from activity patterns.
Controls That Preserve the Function
The goal is not restricting break-glass access — that defeats its purpose. It is making every use loud and every possession verifiable.
Alert unconditionally on any authentication. Any use, at any time, pages the security team immediately. If it was legitimate, someone confirms within a minute. If it was not, response begins at once. This is the single most important control.
Split the credential. Store the password and the second factor with different people, or split the password itself so no individual can use it alone. Two-person control makes solitary misuse impossible.
Use hardware tokens rather than app-based factors. A physical key in a safe is verifiable by inspection and cannot be phished. An authenticator app on someone’s phone is neither.
Record possession physically. A sealed envelope in a documented safe with a tamper-evident seal means an audit can confirm the credential has not been taken without needing to trust any log.
Test on a schedule. An emergency credential that has never been used may not work — the password expired, the account was disabled by a policy sweep, the token battery died. Quarterly verification catches that, and it also rehearses the procedure.
The Documentation Requirement
Every use needs a written record: who, when, why, what was done, and what the alternative was. That record is what distinguishes a legitimate emergency from an unexplained privileged session six months later.
The location and procedure must be documented somewhere reachable during the outage it exists for. Instructions stored in a system that depends on the identity provider are useless in exactly the scenario they were written for.
The Bottom Line
Keep break-glass accounts, and make them loud rather than restricted. Alert on every authentication without exception, split control between two people, use hardware tokens sealed in a documented location, test quarterly, and store the procedure somewhere that survives the failure it addresses.
