Break-the-Glass Override

What a break-the-glass override changes

A break-the-glass override is not just a shortcut, it is a controlled exception to normal access governance. It exists because some failures, outages, or urgent recovery situations cannot wait for ordinary approval chains, but the privilege to bypass controls must be narrowly scoped, time-limited, and accountable.

The defining feature is that the override is exceptional rather than routine. That matters because any access path that relaxes standard checks also weakens the usual separation between requester, approver, and reviewer, so the control design must assume the access path will be used under stress and with incomplete information.

Where break-the-glass is used

Organisations usually reserve break-the-glass access for situations such as production outages, locked-out administrators, failed federation, or emergency recovery when service restoration is more important than maintaining the normal approval workflow. In practice, it is a resilience control as much as an access control.

It is most defensible when the ordinary path is unavailable or too slow to preserve availability, not when the team simply wants convenience. That distinction is important because a broad emergency path can become a shadow administration route if it is repeatedly used for everyday tasks.

Good implementations pair the emergency path with strong identity evidence, restricted targets, and explicit justification. Even when approval is bypassed, the organisation should still know who invoked the override, what system was accessed, and why the exception was needed.

Why exceptional access needs extra control

Break-the-glass access is inherently powerful because it concentrates privilege exactly when the environment is already fragile. That makes it a high-value target for misuse, mistaken use, or post-compromise persistence if the exceptional path is not tightly governed.

It should be treated as a compensating control for urgent continuity, not as a substitute for normal privilege management. A well-designed override still needs clear ownership, strong logging, and a mechanism to ensure the elevated path does not become a standing access entitlement.

The same logic applies to both human and non-human access patterns, because the security issue is the temporary relaxation of authority, not the label on the actor. The control must therefore limit privilege by context, duration, and scope rather than assume the emergency use case makes the access safe.

What good review and auditability look like

After use, the event should be easy to reconstruct. That means preserving request context, the identity that triggered the override, the resource touched, the duration of access, and the actions taken while the exception was active.

Post-event review is not optional because emergency access can mask mistakes, unauthorised changes, or attacker activity that blended into a legitimate recovery action. Review should answer whether the override was justified, whether the access was narrower than necessary, and whether the event exposed any control weakness that needs correction.

Where organisations use identity and privilege governance frameworks, the same principles that guide least privilege and auditability should apply here as well, even though the access path is exceptional. A break-the-glass process is only trustworthy when the exception itself is visible, explainable, and reversible.

Risk and Threat Considerations

Emergency override paths create a deliberate control gap, so the main risk is that an attacker, a careless operator, or a confused responder uses the gap for broader access than intended. The same mechanism that restores service can also bypass normal approval, which makes the path especially sensitive during outages and incident pressure.

Failure mechanism: Exceptional access can be abused for persistence, privilege expansion, or unauthorised system changes if the override is not tightly bound to a specific purpose, duration, and review trail.

Impact: The result can be hidden administrative activity, weakened accountability, or a faster path from initial compromise to sensitive systems, especially when emergency use is not closely monitored and revalidated after the fact.

Practitioner Guidance

Why practitioners should care: A break-the-glass control is only safe when it behaves like a narrow emergency valve, not a convenience layer. The practical question is whether the organisation can restore service without creating a durable alternative to normal privilege governance.

Governance implication: Assign clear ownership for when the override may be used, who can authorise it, and how each use is reviewed afterward. If the process cannot be explained, audited, and revoked cleanly, it is too broad for emergency use.

Practitioner takeaway: Design the override so that urgency relaxes delay, not accountability.

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?
• Why do break glass accounts need separate governance from normal IAM controls?