Break-glass Access

What Break-glass Access Is For

Break-glass access is an exceptional control path, not a convenience feature. It exists so operators can regain control during account lockout, identity provider failure, or a live incident when the normal path is unavailable and delay would increase harm. That emergency intent is what justifies the bypass, and it is also why the path must remain tightly governed.

The defining characteristic is temporary exception handling. A well-designed break-glass path should be narrowly scoped to a specific recovery need, with explicit ownership and clear criteria for when it may be used. In practice, this makes it part of resilience engineering as much as access management.

How Break-glass Access Differs From Ordinary Privileged Access

Ordinary privileged access is meant to be controlled through steady-state policy, such as approvals, role assignment, strong authentication, and session oversight. Break-glass access is the exception route used only when those normal controls cannot support the response requirement. The difference matters because a break-glass account or workflow is deliberately designed to survive a failure in the primary control plane.

That distinction is why organisations usually separate emergency credentials from day-to-day administrative access. If the same path is used for routine work, the emergency control loses its purpose and becomes another standing privilege path. The Privileged Access Management Guide is useful here because break-glass access only makes sense when seen as part of a broader privileged access model that already assumes least privilege, session control, and review.

In mature environments, the emergency path is often paired with strong separation of duties, limited membership, and explicit recovery ownership. That keeps the exception usable under pressure without turning it into a general-purpose administrative shortcut.

Operational Design Considerations

Break-glass access is most valuable when the normal authentication or directory path is unavailable, but the organisation still needs a trusted way to restore service. That means the design has to anticipate failure modes such as identity provider outages, MFA disruption, broken federation, or loss of admin sessions. The control should also be usable when remote access dependencies are impaired, which is why many teams maintain an offline or out-of-band recovery path.

Good design also includes a clear recovery journey. The emergency method should be simple enough to use under incident pressure, but specific enough that operators can prove when it was activated and why. The Emergency Identity Operations When the Primary IdP Is Unavailable guide is a strong match for that scenario because break-glass access is often part of a wider continuity plan for identity failure.

For infrastructure and cloud estates, the same principle extends to management planes. The Out-of-Band Management Network Design Guide shows why emergency access should be separated from ordinary production paths wherever possible, so recovery remains available even when the primary access fabric is affected.

Logging, Review, and Post-use Accountability

Break-glass access should always be auditable. The reason is simple: the same privilege that makes it useful in an emergency also makes it dangerous if it is left unexamined. Every activation should be logged, time-bounded, and reviewed after the event so the organisation can confirm the action was necessary and determine whether the emergency path exposed any weak points.

That review should not be treated as a formality. The post-use question is whether the emergency path functioned as intended, whether the triggering condition was valid, and whether the event revealed a control gap that needs remediation. The CIS Control 17 Incident Response Management Guide is relevant because break-glass use often occurs during incident response and should feed into the same evidence, escalation, and post-incident review discipline.

In platform-specific environments, such as Kubernetes or cloud administration, organisations should also verify that emergency activity is visible in platform logs and not just in identity logs. The AKS Identity Hardening Guide is a useful example of how emergency administrative paths need to be observable at the platform layer as well as at the access layer.

Risk and Threat Considerations

Break-glass access creates concentrated risk because it intentionally weakens normal access barriers during a high-pressure moment. If the emergency path is poorly protected, overused, or insufficiently monitored, it can become a persistent back door that attackers target after they gain adjacent access or exploit weak operational discipline.

Failure mechanism: The emergency route is usually the one path that remains available when normal controls fail, so compromise of its credentials, misuse of its workflow, or failure to review its activation can bypass the very controls the organisation depends on most.

Impact: Successful abuse can lead to privileged access, persistence, unauthorized administrative change, and delayed detection, especially if the emergency event is treated as expected noise rather than a security signal.

Practitioner Guidance

Governance implication: Treat break-glass access as a formally owned exception with a named purpose, a narrow activation condition, and a defined review owner. The control should be easy to invoke in a real incident, but difficult to use casually. That balance is what preserves both resilience and accountability.

What to watch for: Repeated use, vague activation rationale, shared credentials, or emergency paths that are never tested are all signs that the control is drifting from exception handling into standing privilege. If the path cannot be validated under controlled conditions, it is not reliably available when a real incident happens.

Practitioner takeaway: A good break-glass design is one that is rarely used, clearly logged, and routinely rehearsed, so the organisation can restore control quickly without normalizing the exception.

Related resources from NHI Mgmt Group

• What breaks when break-glass access is not tightly governed?
• How do security teams know whether break-glass access is actually working?
• What breaks when break glass accounts are treated like everyday admin access?
• Who should be accountable for break glass access when a breach occurs?