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.
Why a break glass protocol exists
A break glass protocol is a controlled exception path, not a second operating mode. Its job is to keep urgent remediation, outage recovery, and safety-critical production work moving when waiting for normal approvals would create more harm than the temporary access itself.
The key design tension is speed versus control. A good protocol makes the exception possible without making it easy to reuse casually, because once emergency access becomes familiar, it starts behaving like standing privilege.
That is why break glass should always be treated as a named exception with a clear trigger, a bounded scope, and a defined owner. The protocol is only justified when the business or operational impact of delay is greater than the control relaxation required to resolve the incident.
How break glass access should behave
The protocol should grant only the minimum access needed for the urgent task, for the shortest practical time, and in a way that can be traced after the fact. In mature environments this often means separate emergency accounts, strong approval criteria, time limits, session logging, and explicit post-use review.
It is also important that break glass access does not rely on the same everyday credentials used for routine administration. If the emergency path is indistinguishable from normal admin access, the organisation loses both accountability and the ability to prove that the exception remained exceptional.
Because the purpose is recovery, not convenience, the protocol should be usable under stress and still leave a reliable record of who used it, when, why, and what changed. That record is what turns the access event into something governable rather than merely permissive.
Common failure modes and control gaps
Break glass breaks down when organisations leave emergency access too broad, too permanent, or too hard to audit. A protocol that has no expiry, no logging, or no review becomes a hidden backdoor rather than a recovery control.
Another common weakness is poor maintenance of the emergency path itself. If break glass account are not tested, rotated, and periodically validated, they can fail during the exact moment they are needed most, or they can accumulate stale access that no one can confidently explain.
The other major gap is ownership. If no team is responsible for approving, monitoring, and reviewing emergency use, then the process may exist on paper but not in practice. That often shows up first as missing evidence after an incident, then as uncontrolled reuse.
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 |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | Emergency access must be scoped, approved, and removed under access control governance. |
| Recommendation — Restrict break glass access to approved use cases and promptly revoke emergency privilege after use. | ||
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication and Access Control | Break glass is an access-control exception that must still preserve least privilege and accountability. |
| PR.PT — Protective Technology | Logging, session capture, and time-bound technical enforcement are core to emergency-access control. | |
| DE.CM — Continuous Monitoring | Break glass use needs monitoring so every emergency elevation is visible and reviewable. | |
| Recommendation — Apply PR.AC to limit emergency access, require strong authentication, and preserve traceability. Use PR.PT to enforce session logging and technical limits on break glass access. Monitor emergency-access events continuously and alert on unexpected or prolonged use. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secrets and Credential Management | Emergency access often depends on privileged credentials that must be tightly managed and rotated. |
| NHI-04 — Access Control and Least Privilege | Break glass is a deliberate privilege exception that should remain narrowly constrained. | |
| NHI-08 — Audit, Monitoring and Detection | Emergency use must be auditable to support after-action review and abuse detection. | |
| Recommendation — Rotate emergency credentials and keep them out of everyday operational paths. Grant only the minimum emergency permissions needed and expire them immediately after use. Log every break glass action and review it for unauthorized or excessive activity. | ||
Practitioner Guidance
Why practitioners should care: A break glass protocol should be reserved for exceptional production urgency, not as a workaround for weak access design. In practice, the usefulness of the control depends on whether teams can distinguish genuine emergencies from avoidable process delays.
Common misunderstanding: Many teams assume emergency access is safer simply because it is rare. Rarity does not reduce impact if the account is over-privileged, poorly monitored, or available to too many people.
Practitioner takeaway: Treat break glass as an incident-only capability with clear ownership, strict expiry, and mandatory review, so the exception remains recoverable without becoming normal.
Risk and Threat Considerations
Break glass protocols create concentrated exposure because they intentionally suspend normal control layers at the moment the environment is already under stress. If the access path is overbroad, weakly logged, or poorly time-bound, it can become an attractive route for abuse during an incident or a cover path after compromise.
Failure mechanism: The control fails when emergency access is easier to obtain, retain, or reuse than the normal approval path, especially if the account has broad privileges or the post-use review is weak. That creates an opportunity for misuse, persistence, or unauthorised change under the guise of emergency action.
Impact: The organisation can lose visibility into who changed production, expand blast radius during a recovery event, and leave a standing high-risk path available long after the emergency has passed.
