Break the glass is an emergency access process that allows a user to open a protected record in urgent circumstances while creating an audit trail. It is meant for exceptional situations, not routine use, and it requires later review to confirm that the access was justified and appropriate.
What break the glass means in practice
Break the glass is an emergency access path, so its purpose is to override normal access friction only when a business or safety-critical exception exists. That makes it different from routine privilege elevation, because the access decision is supposed to be exceptional, time-bound, and reviewable.
In practice, the design question is not whether emergency access exists, but how tightly it is constrained. Good implementations define who can invoke it, what conditions justify it, and what evidence must remain after the event.
Where break the glass fits in access control
The term sits at the intersection of access control, privileged administration, and auditability. A protected record, root console, or critical system may be inaccessible under ordinary policy, yet still need to be opened during an outage, lockout, or high-severity incident.
That is why break-the-glass access is usually paired with stronger controls such as explicit approval, limited duration, and post-access logging. The process exists to reduce business disruption without turning emergency privilege into standing privilege.
NHIMG’s Break-Glass and Emergency Access Account Guide explains how emergency access accounts are designed and monitored in real environments, while Privileged Access Management Guide shows how break-glass access fits into broader privileged access controls, including vaulting, just-in-time elevation, and session oversight.
Why the audit trail matters
The audit trail is what separates accountable emergency access from an undocumented exception. It gives reviewers a way to confirm who opened the protected item, when the access occurred, what condition triggered it, and whether the action stayed within the emergency purpose.
Without that record, break-the-glass access can become a hidden bypass that is difficult to govern after the fact. With it, the organisation can reconcile urgent availability needs against later oversight, recertification, and incident review.
For broader control context, NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5 Security and Privacy Controls both reinforce the need for access governance, logging, and traceable control operation around privileged actions.
Typical conditions that justify break-the-glass access
Break the glass is most defensible when normal access paths fail or would cause unacceptable delay, such as an administrator lockout, identity provider outage, broken MFA flow, or a critical production incident that cannot wait for the standard approval chain. It is not meant to substitute for everyday delegated administration.
That distinction matters because the more often emergency access is used, the less meaningful the control becomes. A healthy process is rare, clearly documented, and easy to review precisely because it is not the default operating path.
Risk and Threat Considerations
Break-glass access creates a narrow but meaningful exposure: if the emergency path is too easy to invoke, poorly logged, or left active longer than intended, it becomes an attractive bypass for misuse and post-compromise escalation. The core risk is not the emergency access itself, but the possibility that an exception behaves like a hidden permanent privilege.
Failure mechanism: Weak invocation controls, weak verification, or weak time-bounding can let an attacker, insider, or over-privileged operator use the emergency path as a shortcut around normal approval and monitoring.
Impact: A compromised emergency path can expose protected records, administrative functions, and audit integrity, and it can also undermine trust in the access model after the event.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Emergency access should remain tightly constrained and exceptional. |
| AU-2 — Event Logging | Break-glass use depends on a durable audit trail of privileged access events. | |
| IA-5 — Authenticator Management | Emergency access depends on controlling credentials and other authenticators safely. | |
| Recommendation — Limit break-glass access to the minimum privilege needed for the incident. Log every emergency access event with actor, time, scope, and reason. Protect and rotate emergency credentials so they cannot become standing access. | ||
| ISO/IEC 27001:2022 | A.8.15 — Logging | Emergency access must leave evidence for later review and accountability. |
| A.5.15 — Access control | Break-glass is an access-control exception that still needs policy and enforcement. | |
| Recommendation — Retain logs that prove how and why break-glass access was used. Define, approve, and enforce emergency access rules as a controlled exception. | ||
Practitioner Guidance
Why practitioners should care: Emergency access is only safe when the exception is operationally controlled, because the business value of rapid recovery depends on preserving evidence and limiting reuse. Treat the process as a governance mechanism, not just a login workaround.
What to watch for: Repeated use, unclear justification, shared credentials, or emergency access that lacks a mandatory review step are signs that the control is drifting away from its intended purpose. If the process is being used routinely, it is no longer functioning as break-the-glass access.
Practitioner takeaway: The best break-glass design is the one you can explain, justify, and audit after the incident without relying on informal memory.
