A break glass procedure is a heavily controlled emergency access process used when normal access paths are not allowed. It is designed for exceptional situations, usually with strong auditing and approval requirements. The point is to preserve zero trust principles while still allowing urgent, documented recovery actions.
What a Break Glass Procedure Is
A break glass procedure is an exceptional access path, not a convenience path. It exists so an authorised responder can act during an emergency when standard approval, segregation, or workflow controls would otherwise block urgent recovery.
The defining idea is controlled exception handling. Organisations intentionally preserve their normal zero trust and least-privilege posture, then allow a narrow, documented override only when the business or security impact of waiting would be greater than the access risk.
That makes the procedure as much about governance as access. It usually depends on pre-approved criteria, a named emergency role, strong logging, and post-event review so the override remains rare, explainable, and auditable.
How Break Glass Access Fits Security Architecture
Break glass procedures sit between access control and resilience. They are commonly used for system recovery, outage response, incident containment, and urgent remediation when ordinary identity or approval routes are unavailable, broken, or too slow for the situation.
In practice, the procedure may involve a highly privileged account, a temporary elevation path, or a pre-positioned emergency secret. The important point is not the mechanism itself, but that the mechanism is tightly constrained, time-bound, and monitored so it does not become standing privilege in disguise.
Because the process bypasses normal friction, it should be designed with a clear trigger condition and an explicit owner. The procedure is only legitimate when the emergency use case is narrower than the broad access it momentarily unlocks. That is why it is often discussed alongside NIST Cybersecurity Framework 2.0 resilience and response expectations, and with zero trust concepts such as NIST SP 800-207 Zero Trust Architecture.
For identity-heavy environments, the same emergency access pattern is central to Privileged Access Management Guide, because break glass is usually a privileged control, not a generic operations shortcut.
Common Design Traits and Operational Safeguards
A sound break glass procedure usually separates emergency access from everyday administration. That can mean a dedicated account, a sealed credential, an emergency vault workflow, or a tightly controlled approval path that activates only under defined conditions.
Strong auditability is essential because the procedure trades normal prevention for rapid recovery. Logging, session recording, after-the-fact review, and prompt credential reset help ensure the emergency path can be inspected and retired as soon as the incident ends.
Many organisations also pair break glass with explicit expiry, justification capture, and secondary notification so the event is visible to control owners and incident responders. The procedure should be easy to invoke under stress, but hard to abuse without leaving evidence.
That is why emergency access is often framed next to NIST SP 800-53 Rev 5 Security and Privacy Controls, especially controls around access enforcement, account management, auditing, and configuration control.
Why Break Glass Matters in Zero Trust Environments
Zero trust does not eliminate emergency access, it forces emergency access to be exceptional, visible, and revocable. A break glass procedure is the compromise that lets an organisation recover systems without abandoning the underlying security model.
The practical tension is speed versus control. If the procedure is too restrictive, responders may be unable to restore service in time. If it is too loose, the emergency path becomes a hidden standing privilege channel that undermines the rest of the access model.
For that reason, break glass procedures are best understood as part of the same governance layer as privileged access, emergency operations, and privileged session controls. The objective is not to remove the override, but to make the override accountable enough that it remains defensible when the event is reviewed later.
External guidance on phishing-resistant authentication and strong credential assurance is also relevant when the emergency path depends on a human operator proving they are the right responder, which is why NIST SP 800-63 Digital Identity Guidelines is a useful reference point.
Risk and Threat Considerations
break glass access is attractive to attackers because it is designed to bypass normal friction. If the emergency path is poorly protected, it can become a high-value target for privilege escalation, credential theft, or covert administrative access.
Failure mechanism: The control fails when emergency credentials are stored too broadly, reused too often, activated without strong verification, or left active after the incident ends. In that case, the exception becomes a durable back door rather than a temporary recovery path.
Impact: A compromised break glass path can expose the highest-privilege systems in the environment, defeat separation of duties, and create hard-to-detect persistence because defenders may assume the access was legitimate emergency activity.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RR-01 — Roles, Responsibilities, and Authorities | Break glass requires clearly assigned emergency authority and ownership. |
| PR.AA-05 — Identity Management, Authentication, and Access Control | Break glass is a constrained access override within identity and access control. | |
| DE.CM-09 — Monitoring for Anomalies and Events | Emergency access must be detectable and reviewable through monitoring. | |
| Recommendation — Define emergency access owners and approval authority before an incident starts. Enforce strong authentication and narrowly scoped emergency access controls. Monitor break glass activity and alert on unexpected emergency access use. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Break glass relies on tightly governed emergency accounts and lifecycle control. |
| AC-6 — Least Privilege | The procedure is an exception to least privilege and must stay narrow. | |
| AU-2 — Event Logging | Break glass requires auditable records of who used emergency access and when. | |
| Recommendation — Restrict emergency accounts, track their use, and remove them when no longer needed. Limit emergency access to the minimum authority needed for recovery. Log every emergency access activation with justification and timing. | ||
| NIST Zero Trust (SP 800-207) | 0 — Never Trust, Always Verify | Break glass is a controlled exception that must preserve zero trust principles. |
| Recommendation — Require verification and bounded access even for emergency overrides. | ||
| CIS Controls v8 | CIS-5 — Account Management | Break glass is a special account-management pattern for privileged recovery. |
| CIS-8 — Audit Log Management | The procedure depends on traceable logs for emergency access review. | |
| Recommendation — Govern emergency accounts separately from standard admin access. Collect and retain logs for every break glass invocation. | ||
Practitioner Guidance
Why practitioners should care: Break glass is one of the few controls that intentionally relaxes normal access discipline under pressure, so its governance must be explicit before an incident happens. If the trigger, approval expectation, and post-use review are vague, the control will either be unusable in an emergency or overused as a convenience path.
Common misunderstanding: Teams sometimes treat break glass as a one-time account rather than an operating model. The account or secret is only the mechanism; the real control is the documented, monitored, and reversible process wrapped around it.
Practitioner takeaway: Design break glass so responders can move fast without creating permanent privilege, and validate the full emergency-to-recovery lifecycle before you need it.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
