Organisations should use a break glass protocol when a trusted operator needs time-bound access to production for an urgent incident or recovery task, and normal access paths are too slow or restrictive. The protocol should be tightly governed, auditable, and exceptional. It is a safety valve, not a replacement for day-to-day least privilege or access planning.
When break glass access is justified
A break glass protocol is justified when the business need is urgent, the normal approval path would delay recovery, and the operator already has a legitimate operational role. That usually means production incident response, service restoration, containment, or a time-sensitive change needed to prevent material harm. It should be reserved for exceptional access, not convenience or routine administration.
Because break glass access overrides normal controls, the trigger should be narrow and explicit. The right question is whether the situation is time-critical enough that waiting for standard access would worsen outage, loss, or exposure. If the task can safely wait, use the ordinary workflow instead.
A useful way to frame the decision is to treat break glass as a controlled exception to normal access governance. It is most defensible when the operator needs immediate reach into production, but the organisation still wants strong attribution, limited scope, and a clear post-event review. That makes the protocol a safety mechanism, not a standing privilege path.
- Use it for urgent incident containment, restoration, or recovery work.
- Use it when normal access is unavailable, too slow, or blocked by an outage.
- Use it only for a named purpose, a defined time window, and a specific production target.
- Avoid it for routine debugging, planned maintenance, or access shortcuts.
When organisations describe the trigger too loosely, break glass tends to drift into everyday use. That is where the control loses value: the exception becomes the default, and the normal privilege model stops reflecting actual operating practice. The protocol should therefore be tied to a clearly documented emergency condition and an explicit approval or escalation path.
Risk and Threat Considerations
Break glass access concentrates power at the exact moment an environment is already stressed, which makes misuse, error, and post-compromise abuse more consequential. If the access path is not tightly bounded, an attacker or careless operator can turn an emergency override into broad production control, data exposure, or destructive change.
Failure mechanism: The normal control path is bypassed, but the emergency account or credential is overprivileged, weakly monitored, or reused too broadly, so the exception expands blast radius instead of containing it.
Impact: A supposedly temporary recovery action can become unauthorized persistence, hard-to-attribute change, or rapid escalation into production systems and sensitive data.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8, NIST Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Break glass access depends on tightly controlled emergency credentials and time-bound secrets. |
| NHI-03 — Least Privilege and Access Scope | Emergency production access should remain narrowly scoped even when normal controls are bypassed. | |
| NHI-08 — Logging and Detection | Break glass is only safe when emergency use is fully logged and alertable. | |
| Recommendation — Limit emergency credentials, rotate them after use, and keep the access path auditable. Grant only the minimum production scope needed for the incident and revoke it immediately after. Alert on every emergency access use and preserve immutable records for review. | ||
| CIS Controls v8 | 6 — Access Control Management | Break glass is an exceptional access-control process that must be governed and reviewed. |
| 8 — Audit Log Management | Emergency access must produce reliable audit evidence for incident and recovery review. | |
| Recommendation — Enforce approvals, time bounds, and post-use review for emergency production access. Log every break glass action and retain the records for investigation and accountability. | ||
| NIST Zero Trust (SP 800-207) | 3 — Policy Continuously Evaluated and Enforced | Break glass is a policy exception that should still be narrowly enforced and time limited. |
| Recommendation — Apply conditional policy checks and expire emergency access as soon as the task ends. | ||
| NIST CSF 2.0 | PR.AA-01 — Identity Management, Authentication, and Access Control | Emergency production access is an identity and access control exception requiring strong governance. |
| DE.CM-08 — Monitoring for Unauthorized Access | Break glass use should be monitored as a high-signal event that may indicate abuse or compromise. | |
| Recommendation — Define a dedicated emergency-access process with strong authentication and tight privilege scope. Detect and escalate every unexpected emergency-access event in production. | ||
| MITRE ATT&CK | T1078 — Valid Accounts | Emergency credentials can be abused as valid accounts if they are overly broad or poorly monitored. |
| Recommendation — Treat break glass credentials as high-value valid accounts and hunt for misuse quickly. | ||
Practitioner Guidance
What to verify: Before you trust a break glass process, verify that the trigger condition, time limit, approval trail, and post-use review are all mandatory, not optional. The protocol should be visibly harder to use than normal access, except during a genuine incident.
What good looks like: A mature setup has a unique emergency account or path, strong logging, rapid alerting, and automatic expiry or rotation after use. The operator can act immediately, but the organisation can still answer who used the access, why it was used, and what changed.
Practitioner takeaway: Break glass works best when it is rare, narrow, and auditable, because the more often it is used, the more it starts behaving like unmanaged standing access.
Related resources from NHI Mgmt Group
- When should organisations use automated break-glass access for on-call engineers instead of relying on manual emergency grants?
- How can organisations test AI agent access before production use?
- Who should approve break-glass and privileged access changes when policy automation is in use?
- What happens when organisations keep shared credentials and break-glass access in a FedRAMP environment?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
