How break-glass access works
The name comes from the fire alarm: break the glass only in a real emergency. A break-glass account is a highly privileged account that is deliberately kept outside the normal access path, excluded from federation and, where safe, from dependencies that might themselves fail, so it still works when the identity provider is down, MFA is unavailable or the PAM platform is unreachable.
The credentials are stored sealed: in a physical safe, an offline vault or a separate secured system, split between two custodians in stricter setups. Using the account requires a defined procedure, typically incident declaration and senior authorization, and every use is expected to be rare, justified and fully reviewed afterwards.
Why break-glass accounts matter
Strong identity controls create a new failure mode: locking yourself out. If every admin login requires the identity provider, and the identity provider is what just failed, no one can log in to fix it. The same trap exists with conditional access misconfigurations, expired federation certificates and PAM outages. Break-glass accounts are the designed escape hatch for these scenarios.
The risk cuts both ways. A permanently powerful account that bypasses MFA and normal controls is exactly what attackers hunt for, so an unmanaged break-glass account can become the weakest link in an otherwise hardened environment. The discipline around sealing, monitoring and reviewing these accounts matters as much as their existence.
Managing break-glass accounts well
Good practice keeps the number of break-glass accounts to a bare minimum, usually one or two per critical platform, with long random passwords stored sealed and rotated immediately after every use and on a regular schedule regardless of use. Any login to a break-glass account should trigger a high-priority alert, since legitimate uses are announced and everything else is an incident.
Procedures need testing: teams periodically verify the sealed credentials still work and that the emergency path does not silently depend on the systems it is meant to bypass. Where a PAM platform is in place, break-glass credentials for other systems can be vaulted with alerting and automatic post-use rotation, and Monopam supports this pattern with its credential vault, usage history and rotation policies.