Break The Glass

What Break the Glass Means in Access Control

Break the glass is an emergency override pattern in access control. It exists so a protected record or restricted system can be opened in a genuine urgent situation when normal approval paths would be too slow, but the access must remain exceptional, time-bound, and visible for later review.

The key design idea is not “more access”, but controlled exception handling. A break-glass path should be narrow, explicit, and auditable so teams can respond to urgent operational, safety, or incident conditions without turning emergency access into a routine shortcut.

How Break the Glass Differs from Ordinary Privileged Access

Ordinary privileged access is planned and governed through standard roles, approvals, and least-privilege rules. Break the glass is different because it is reserved for unusual circumstances where business continuity or safety takes priority over the usual delay of approval workflows.

That distinction matters because emergency access is often broader than day-to-day access, even when only for a moment. If an organisation cannot clearly separate routine elevation from emergency override, it risks normalising exceptional access and weakening its control model.

A well-designed break-glass process also creates a clear accountability boundary. The user acts first under exceptional conditions, then the access event is reviewed after the fact to confirm necessity, scope, and appropriateness.

What Makes Break-the-Glass Controls Trustworthy

Trust in this pattern comes from the controls around the exception, not from the exception itself. Strong designs log who used the emergency path, what was accessed, when it happened, and why the override was triggered.

The process should also limit duration and scope so the emergency session does not become an uncontrolled standing privilege. Review should be meaningful, not ceremonial, because the whole point is to prove that the emergency path was justified and constrained.

In practice, break-the-glass access is only as reliable as the surrounding governance: clear criteria for use, a visible approval or notification trail, and a reliable post-event validation step.

Where Break the Glass Fits in Security Operations

This pattern is common in high-impact environments where delayed access can create operational or safety harm, such as incident response, regulated records handling, or recovery workflows. It is a resilience control as much as an access control.

It also creates an important detection use case. Because break-glass access is supposed to be rare, each event should stand out in logging and alerting so security teams can distinguish legitimate emergency use from abuse or compromise.

Used well, the pattern reduces the risk of workarounds, shadow access, and policy exceptions made outside the system. Used poorly, it can become a hidden backdoor with a better name.

Risk and Threat Considerations

Break-the-glass access concentrates privilege into a rare but powerful exception, which makes it attractive both to insiders and to attackers who can trigger or steal an emergency path. The main risk is not the existence of the override, but weak controls around when it can be used, how long it lasts, and how well it is reviewed afterward.

Failure mechanism: If emergency access is too easy to invoke, insufficiently logged, or not followed by strict review, it can bypass normal authorization controls and create an abuse path that looks legitimate at the moment of use. A compromised account, stolen session, or socially engineered support action can exploit that exception window.

Impact: Unjustified emergency access can expose sensitive records, enable privilege escalation, defeat segregation of duties, and leave the organisation with poor evidence for incident review, compliance investigation, or post-incident reconstruction.

Practitioner Guidance

Governance implication: Treat break-the-glass as a formally owned exception process, not an informal convenience feature. Define what counts as an emergency, who may invoke the path, and what evidence must exist after use so the process remains defensible.

What to watch for: Repeated emergency use, broad access beyond the immediate task, or missing justification are warning signs that the control is drifting from exception handling into routine privilege.

Practitioner takeaway: The control should be designed so that urgent access is possible, but every use is uncomfortable enough to justify itself later.

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?