Break-glass access is an emergency path that bypasses normal access controls when standard authentication fails or a critical incident demands immediate intervention. It must be tightly time-bound, logged, and reviewed, because it exists to restore operations without becoming a permanent back door.
Expanded Definition
Break-glass access is an emergency exception path used when normal authentication, approval, or automation would block urgent restoration of a critical service. It is not a synonym for shared admin access or a convenience override; it should exist only for tightly defined incidents, with explicit scope, strong authentication, time limits, and post-event review. In NHI operations, it often applies to service accounts, vault access, orchestration pipelines, or agent control planes where delay creates operational or safety risk.
Definitions vary across vendors, especially when products blur break-glass with temporary elevation, JIT access, or emergency role assignment. NHI Management Group treats the concept as a controlled exception inside a broader Zero Trust Architecture, consistent with the risk framing in the Ultimate Guide to NHIs and the access abuse patterns described in the OWASP Non-Human Identity Top 10.
The most common misapplication is leaving emergency access permanently enabled, which occurs when teams treat incident readiness as a standing privilege instead of a short-lived control with formal expiry.
Examples and Use Cases
Implementing break-glass access rigorously often introduces response friction, requiring organisations to weigh rapid recovery against the operational cost of stronger approval and logging controls.
- An incident commander activates emergency vault access to recover a failed signing key after a production outage, then the session is automatically revoked and reviewed.
- A platform engineer uses a documented override to restore a broken CI/CD pipeline when an NHI credential rotation fails, with every action recorded for later audit.
- A security operator unlocks a constrained service account during a ransomware event to preserve logging and containment tooling, following a pre-approved incident playbook.
- An AI agent’s tool access is suspended during abnormal behavior, then break-glass privileges are granted only to a human operator to halt execution and isolate secrets.
These scenarios align with the governance concerns in the Ultimate Guide to NHIs — Key Challenges and Risks, because emergency paths are most dangerous when they become a substitute for lifecycle control. They also fit the access-hardening focus of the OWASP guidance, where exceptional privilege must be explicit, logged, and bounded. In practice, break-glass should be pre-registered, tested, and tied to incident criteria rather than improvised during outage pressure.
Why It Matters in NHI Security
Break-glass access matters because NHIs are frequently overprivileged, persistent, and under-observed. NHI Mgmt Group research shows that 97% of NHIs carry excessive privileges, which means any emergency override can become a fast path to broad compromise if it is not constrained. The operational problem is not the existence of emergency access, but the tendency for teams to fail to remove it, monitor it, or distinguish it from routine administration. That is especially risky in environments with API keys, vaults, service accounts, and autonomous agents that can continue acting after the initial incident has passed.
Practitioners should connect break-glass design to the wider identity lifecycle discussed in the Ultimate Guide to NHIs and to incident patterns documented in the 52 NHI Breaches Analysis. Where Zero Trust Architecture is the goal, emergency access should still preserve verification, narrow scope, and explicit session accountability. Organisations typically encounter break-glass as a necessary control only after an outage, lockout, or breach forces emergency intervention, at which point it becomes operationally unavoidable to govern properly.
The control pattern is also reinforced by the OWASP Non-Human Identity Top 10, which treats weak exception handling as a practical avenue for privilege abuse.
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 address the attack and risk surface, while 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-03 | Emergency access must not become standing privilege or unmanaged secret exposure. |
| NIST Zero Trust (SP 800-207) | AC-2 | Zero Trust requires narrowly scoped, verified access even for exceptional recovery actions. |
| NIST CSF 2.0 | PR.AA-5 | Access exceptions must be governed, monitored, and reviewed as part of identity assurance. |
Bind break-glass access to strict expiry, logging, and post-use review before re-enabling any NHI path.
