A break-glass recovery key is an emergency credential or key material kept offline for exceptional restoration or account recovery. It is only useful if the organisation can locate it, protect it, and test the procedure for using it without improvisation during an incident.
Expanded Definition
A break-glass recovery key is emergency key material reserved for exceptional restoration, account recovery, or access reconstitution when normal administrative paths are unavailable. Its defining feature is not convenience, but controlled exception handling: it should exist outside the routine access path, yet remain retrievable under pressure.
The term is often used alongside offline escrow, emergency access, and recovery procedures, but it is narrower than general backup. A backup can be restored through ordinary systems; a break-glass key is specifically meant for rare, high-stakes recovery where the usual control plane may be damaged, unavailable, or compromised. That distinction matters because the key is only valuable if the organisation can prove where it is, who may use it, and how its use is authorised without improvisation.
In practice, this is a governance object as much as a technical one. A common misunderstanding is to treat the key as a “just in case” spare and then leave its storage, custody, and invocation undefined. That turns an emergency safeguard into an unmanaged secret.
Examples and Use Cases
Break-glass recovery keys appear in environments where recovery must survive outages, lockouts, or control failure. Typical use cases include:
- Restoring access to a core identity or admin account when the primary authenticator is unavailable.
- Recovering a tenant, vault, or key management service after misconfiguration blocks normal administration.
- Unlocking an encrypted system when the standard recovery workflow cannot be completed during an incident.
- Regaining control of a cloud or SaaS environment after a delegated admin path is lost or disabled.
These scenarios share a tradeoff: the more survivable the recovery path, the more carefully it must be protected from misuse. Offline storage improves resilience, but it also creates a custody problem because the organisation must still know where the key is, how it is accessed, and whether the procedure has been rehearsed. The most effective implementations make recovery slow enough to be safe, but not so opaque that nobody can execute it under incident conditions.
For broader NHI context, NHI Management Group reports that 96% of organisations store secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools, which shows how easily exceptional secrets can drift into unsafe handling. Ultimate Guide to NHIs
Security Implications
Break-glass recovery keys reduce the risk of permanent lockout, but they also create a high-value secret that can bypass normal control layers. If the key is exposed, copied too widely, or stored in a place that is not truly offline, it can become a privileged backdoor rather than a recovery mechanism.
Mismanagement usually fails in one of three ways: the key cannot be found during an incident, it is found but cannot be used safely, or it is used without clear approval and auditability. Each failure creates a different consequence. Missing keys delay recovery. Untested procedures create operational uncertainty at the exact moment speed matters. Weak custody turns recovery material into an attack target for insiders or an intruder who has already compromised adjacent systems.
NHI Mgmt Group reports that 91.6% of secrets remain valid five days after the targeted organisation is notified, showing how weak revocation and recovery discipline can prolong exposure after compromise. That is especially relevant here because emergency secrets often survive longer than intended when ownership is unclear.
Practitioners should watch for signs that the recovery path exists only on paper: no named custodian, no restore drill, no revocation process after use, or no audit trail for when the key is retrieved.
Domain and Governance Relevance
Break-glass recovery keys matter in NHI governance because machine and service identities often depend on secrets, certificates, and recovery artifacts that outlive human memory and normal admin access. When those identities are critical to systems, the organisation needs an emergency path that can restore access without creating a standing privilege channel.
That makes the key part of lifecycle governance, not a one-time contingency. Its owner, storage location, retrieval conditions, and post-use revocation should be treated as controlled attributes of the identity estate. If an agent, service account, or encrypted workload cannot be recovered cleanly, organisations are forced into unsafe improvisation, which is exactly when break-glass material tends to be misused or duplicated.
In NHI-heavy environments, the main governance question is whether emergency access is truly exceptional and auditable, or simply a hidden alternative admin path. The distinction affects trust, separation of duties, and recovery confidence across the entire identity stack.
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 CIS Controls v8 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-02 — Secrets and Credential Management | Break-glass keys are emergency secrets that need controlled storage and recovery handling. |
| NHI-04 — Access and Privilege Management | Emergency recovery keys can bypass normal access controls if use is not tightly constrained. | |
| NHI-06 — Lifecycle Management | Break-glass keys require issuance, testing, rotation, and post-use revocation discipline. | |
| Recommendation — Classify, escrow, and monitor break-glass keys as high-risk NHI secrets with explicit ownership. Restrict emergency-key use to named recovery workflows and limit who can invoke it. Test, rotate, and revoke recovery keys on a defined lifecycle instead of leaving them static. | ||
| CIS Controls v8 | 6.3 — Access Rights Management | Emergency recovery keys create privileged access paths that need tight rights control. |
| 3.3 — Data Protection | Offline recovery keys are sensitive data whose storage and handling must be protected. | |
| Recommendation — Limit break-glass access to a minimal set of approved custodians and recovery operators. Protect recovery keys with strong storage controls and separate them from routine operational secrets. | ||
| NIST CSF 2.0 | PR.AA-01 — Identity and Credential Lifecycle Management | Recovery keys are identity recovery material that must be inventoried and governed. |
| RC.RP-01 — Recovery Plan Execution | Break-glass keys exist to enable recovery when standard access paths fail. | |
| Recommendation — Inventory emergency recovery material and define who can create, hold, and use it. Rehearse recovery execution so break-glass procedures work during an incident. | ||
