A break glass protocol is an emergency access process that lets approved personnel bypass normal controls when urgent production work cannot wait. It should be tightly scoped, logged, and reviewed after use. The purpose is to preserve recovery speed without turning exceptional access into a standing privilege.
What Break Glass Protocols Do
Break glass protocols are designed for exceptional situations, not routine convenience. They let approved responders override normal approval chains or access barriers when production recovery, safety, or continuity would be materially delayed by waiting for standard process.
The protocol matters because the real control is not just the emergency path itself, but the discipline around when it can be used and who can invoke it. Well-run break glass access is narrow, time-bound, and explicitly treated as an exception that must be justified after the fact.
Why They Exist in Mature Access Models
Mature access programmes assume that normal controls are the safest default, but there are moments when normal controls become the obstacle. A locked-out administrator, an identity provider outage, or a critical production incident can create a genuine need for emergency access that preserves recovery speed without creating permanent privilege.
That is why break glass should be understood as a control pattern inside privileged access, not as a separate permission model. It exists to preserve operational resilience while still reinforcing least privilege, separation of duties, and post-use accountability. NHIMG’s Privileged Access Management Guide places break-glass access in the broader context of vaulting, just-in-time access, and session oversight.
How Break Glass Access Should Be Governed
Governance is the difference between a legitimate emergency process and a standing back door. The protocol should define who can approve or invoke it, what systems it may reach, how long access lasts, what evidence is captured, and when post-event review becomes mandatory.
That discipline usually includes separate emergency credentials, strong authentication, logging, alerting, and periodic testing to ensure the path still works when needed. NHIMG’s Break-Glass and Emergency Access Account Guide focuses on designing, protecting, monitoring, and testing that control for cloud directories, PAM, and critical systems.
What Good Use Looks Like After the Event
A break glass event should always leave a trace that can be reviewed. Teams need to know what action was taken, why the emergency route was justified, whether the activity matched the declared incident, and whether any standing access or secret material must now be rotated or removed.
The strongest programmes treat each invocation as a learning event as well as a recovery event. That means validating the reason for use, checking for privilege creep, and confirming that the emergency path did not silently become the normal path for a recurring operational problem.
Risk and Threat Considerations
Emergency access is attractive to attackers because it is purpose-built to bypass ordinary friction. If the control is too broad, poorly monitored, or rarely reviewed, it can become the easiest route to high-value systems during a real incident or after an account compromise.
Failure mechanism: The protocol fails when exceptional access is treated as a permanent convenience, when its credentials or approvals are reused, or when logging is too weak to distinguish legitimate recovery from abuse.
Impact: That failure can produce rapid privilege escalation, unauthorized production change, data exposure, and a compromised recovery process that is harder to trust during the next incident.
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 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Break glass access depends on tightly governed account lifecycle and exception handling. |
| AC-6 — Least Privilege | Emergency access should remain narrowly scoped and temporary to avoid standing privilege. | |
| AU-2 — Event Logging | Break glass use must be auditable so emergency access can be reviewed after the event. | |
| Recommendation — Define and review emergency accounts as controlled exceptions, with explicit authorization and periodic validation. Limit emergency access to the minimum permissions needed for the incident and revoke them promptly after use. Log emergency access activity with enough detail to reconstruct who used it, when, and for what purpose. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | The term is an emergency access pattern within identity and access control governance. |
| Recommendation — Use emergency-access governance to preserve recovery while keeping normal authentication and access controls intact. | ||
Practitioner Guidance
What to watch for: If a break glass path is being used frequently, it is no longer exceptional. Repeated use usually signals a broken normal process, missing operational ownership, or access design that is too restrictive for the work the platform actually has to support.
Governance implication: Assign explicit ownership for approval, logging, review, and periodic testing, and make sure the emergency path remains narrower than routine privileged access. The objective is resilience under duress, not a second administrative model that quietly becomes standard practice.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org