A break-glass user (or break-glass account, emergency access account) is a privileged account that exists outside the normal access control workflow — bypassing PAM approval gates, MFA requirements, or SSO dependencies — and is reserved for situations where those normal mechanisms are themselves unavailable or would prevent responding to a critical incident in time. The name is a physical analogy: like the fire alarm panel behind a pane of glass that reads break glass in emergency, the account is designed so that accessing it requires a deliberate, detectable act. It is not a convenience mechanism; it is an organisational safety net for scenarios such as an identity provider outage locking all administrators out of their own infrastructure, a PAM platform failing during an active incident, or a ransomware attack disabling the tooling needed to contain it.
The defining properties of a well-designed break-glass account are immediate detectability, attributability, and post-use discipline. Immediate detectability means that any use of the account — including failed attempts — triggers real-time alerts to security operations, senior leadership, and the incident response chain, regardless of the state of other monitoring systems; the alert path must be independent of the systems the account might be used to access, since those may themselves be impaired. Attributability means the account is not a shared anonymous credential: it is checked out from a sealed store (a physical safe, a sealed envelope, a tightly controlled vault entry) by a named individual under documented circumstances, so that every action taken during the break-glass session can be traced to a specific person and a specific incident timeline. Post-use discipline means that once the emergency is resolved, the credential is immediately rotated or destroyed, the session recording and audit log are reviewed, the reason for use is formally documented, and a retrospective determines whether normal controls should have handled the situation and what process change would prevent the next break-glass activation — the goal being that break-glass events become rare enough that each one is individually memorable.
Break-glass accounts sit in deliberate tension with the zero-standing-privilege principle that PAM and just-in-time access are designed to enforce: they are, by construction, standing privileges outside normal oversight. This tension is managed through strict scope limitation (one account per critical system or control plane, as few as possible), physical or multi-party access controls on the credential itself (sealed envelope requiring two people, HSM-backed secret requiring dual approval even in an emergency), regular testing (quarterly drills to verify the account still works and alerts fire correctly), and treating every activation as an incident in its own right regardless of the reason for activation. In cloud environments, identity providers and cloud platforms provide first-class break-glass patterns: Azure Entra ID defines emergency access accounts as accounts excluded from all Conditional Access policies, stored with their credentials in a physically secured location, monitored via a dedicated sign-in alert. The Kubernetes equivalent is a static kubeconfig with a certificate-authenticated cluster-admin binding stored offline, for use when the API server’s normal authentication backends are unavailable.