Only when normal access paths are unavailable or unsafe to rely on, such as during authentication outages, federation failures, or incident response where speed matters. It should not be used to bypass routine controls for convenience. The decision point is operational necessity, not administrative preference.
When Break-Glass Is the Right Access Path
Break-glass is the exception path for moments when the normal privileged workflow cannot be completed in time or cannot be trusted to work. That usually means an outage, a federation or directory failure, a broken approval chain, or an active incident where restoring service or containing harm matters more than waiting for standard elevation.
The practical test is whether the organisation needs immediate, bounded privileged action and cannot safely depend on the usual path. If the same task can still be done through normal approvals, JIT, or session controls, break-glass is usually the wrong choice because it weakens governance without adding real operational value.
What Makes Break-Glass Different From Ordinary Privileged Access
Normal privileged workflows are designed to make access deliberate, traceable, and time-bound. Break-glass trades some of that convenience and control for availability under failure conditions, so it should be treated as a separately engineered control, not as a shortcut version of PAM. That is why strong organisations keep it isolated, tightly monitored, and rarely used. A good starting point is Privileged Access Management Guide, which places break-glass in the context of vaulting, JIT, ZSP, and session oversight.
In practice, break-glass access should be reserved for a small number of pre-defined emergency scenarios: restoring administrator access after lockout, recovering critical services during identity provider failure, remediating production impact when delay increases damage, or performing containment when speed is essential. The Break-Glass and Emergency Access Account Guide is useful here because it focuses on protecting, testing, and monitoring that exception path rather than treating it as ordinary admin convenience.
Where teams struggle is not the definition, but the boundary. Break-glass should be available only when the normal path is unavailable, unsafe, or materially too slow for the situation. If an engineer is simply trying to avoid waiting for approval, that is a workflow issue, not a reason to activate emergency access.
How Organisations Should Decide and Govern the Exception
The decision rule should be explicit: use break-glass only when the business impact of delay exceeds the governance cost of bypassing the normal workflow, and only for the minimum access needed to restore control or contain damage. That means the organisation needs a clear activation trigger, a named owner, and a post-use review process.
The workflow also needs technical guardrails. Emergency access should be separate from day-to-day privileged roles, protected by stronger monitoring, and ideally time-limited or rapidly revocable once the incident or outage is resolved. The Just-in-Time Access and Zero Standing Privilege Guide is relevant because it shows the preferred baseline: standing privilege should be removed wherever possible, with emergency access kept as an exception rather than a normal operating model.
That same logic is why break-glass should be tested before it is needed. A dormant emergency account that has never been exercised may fail at the exact moment it is required. Organisations should verify that credentials, recovery paths, audit logging, and approvals still work after directory changes, MFA changes, vendor migrations, and platform upgrades.
Risk and Threat Considerations
Break-glass creates exposure if it becomes a habitual bypass route or if the emergency account is less protected than the controls it replaces. The main threat is not the existence of the account itself, but the combination of broad privilege, weak monitoring, and unclear activation criteria, which can turn an exception into a standing backdoor.
Failure mechanism: Attackers and insiders exploit emergency access when normal controls are broken, delayed, or overly permissive, especially if the account is shared, poorly audited, or reachable through weak recovery paths.
Impact: A misuse event can lead to full administrative compromise, uncontrolled changes during an outage, weakened incident containment, or a false assumption that privileged actions were properly authorised and attributable.
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 addresses the attack surface, NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Break-glass depends on tightly controlled emergency credentials. |
| AC-2 — Account Management | Emergency accounts need distinct ownership, approval, and review. | |
| AC-6 — Least Privilege | Break-glass should grant only the minimum access needed during the exception. | |
| Recommendation — Rotate and protect emergency credentials with strict lifecycle controls. Maintain separate emergency accounts with documented ownership and review. Limit emergency access to the minimum permissions required. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Break-glass is an access-control exception that needs explicit governance. |
| A.8.2 — Privileged access rights | Emergency admin access must be restricted and monitored as privileged access. | |
| Recommendation — Define and approve emergency access criteria and review them regularly. Restrict privileged emergency access and monitor every activation. | ||
| CIS Controls v8 | CIS-5 — Account Management | Break-glass accounts are special accounts requiring controlled management. |
| Recommendation — Inventory, protect, and review emergency accounts separately from normal admin access. | ||
| OWASP ASVS | V8 — Authorization | Break-glass bypasses ordinary authorisation paths and must still be bounded. |
| Recommendation — Ensure emergency access is narrowly authorised and fully auditable. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Emergency non-human access can become excessive privilege if not constrained. |
| NHI-01 — Improper Offboarding | Emergency accounts can persist after their need has passed if lifecycle is weak. | |
| Recommendation — Keep emergency machine access narrowly scoped and time bound. Retire emergency access promptly when it is no longer required. | ||
Practitioner Guidance
What to verify: Confirm that every break-glass account has a documented trigger, a unique owner, a separate authentication path, and reliable alerting on every use. If the account can be used without generating immediate review evidence, it is too weak to trust in production.
Decision rule: If the situation is urgent but the normal workflow still works, keep using the normal workflow. If the normal workflow is unavailable or dangerously slow, activate break-glass, scope it to the minimum task, and require post-event review as part of closure.
Common mistake: Treating break-glass as a convenience path for privileged work. That pattern erodes the difference between emergency access and routine administration, which is exactly what makes emergency access dangerous over time.
Practitioner takeaway: Break-glass is justified by operational necessity, not privilege preference; the better the normal privileged workflow, the rarer and safer the emergency exception should be.
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?
- Who should approve break-glass and privileged access changes when policy automation is in use?
- Why do organisations use SSO for privileged access tools and vaults instead of separate credentials?
- What is the difference between break glass access and normal privileged access?