Organisations should prioritise just-in-time access when the work is urgent but predictable, because JIT gives temporary privilege with a clearer end state. Break-glass should be reserved for true recovery scenarios where normal controls cannot be used. The trade-off is that JIT is easier to govern, while break-glass carries more exception risk and stronger audit requirements.
When should JIT be the default, and what problem does it solve better than standing break-glass access?
JIT access is the better default when the task is time-bound, expected, and still needs approval or policy control. It gives operators the privilege they need only for the window they need it, which reduces standing access, narrows blast radius, and makes normal work easier to review. That is especially useful for admin tasks, cloud operations, and routine production support.
Just-in-time access is also the cleaner fit for organisations trying to remove standing privilege with just-in-time access and for teams building broader privileged access programmes around privileged access management. The practical distinction is that JIT is an access model, not an emergency exception, so it works best when you can predict the need, define the role, and enforce expiry cleanly.
In that sense, organisations should prefer JIT whenever the user or automation can wait for a normal approval path without harming recovery time or operational safety. It is usually the right default for recurring tasks because it keeps the access request, activation, and revocation steps visible and repeatable rather than relying on a permanently armed emergency credential.
When should break-glass accounts stay reserved for true emergencies?
Break-glass accounts make sense when normal identity controls are unavailable, such as an IdP outage, MFA failure, lockout, or a recovery event that blocks the ordinary path to production. They are not a convenience tier for speed. Their purpose is to restore control when the standard path is broken, which means they should be few, tightly protected, and rarely used.
That boundary matters because break-glass access is intentionally exceptional and therefore harder to govern than JIT. Organisations should treat it as a last resort for recovery, not as an alternate route for routine administration. When a task can be completed through JIT, the emergency account should stay untouched so that its use remains meaningful and reviewable.
Break-glass should also be isolated from day-to-day privilege design. The account, secrets, activation steps, logging, and post-use review all need a higher assurance standard than ordinary admin access. Otherwise, an account that was meant for recovery becomes a standing back door with a weak operational story attached to it.
How should teams decide between the two in practice?
The decision usually turns on predictability and recoverability. If the need is predictable, delay-tolerant, and can be approved in advance, JIT is the right choice. If the need is unpredictable and tied to regaining access after normal controls fail, break-glass is the right choice.
JIT should be the first question teams ask for production work, because it forces privilege to expire by design. Break-glass should be the fallback only when access is needed to restore service, investigate a lockout, or bypass a control failure that prevents normal administration. That separation keeps your control model aligned with the actual business event, not just with the convenience of the operator.
A useful rule is that JIT answers, “How do we grant the minimum privilege for this job?” while break-glass answers, “How do we regain control when the normal path is unavailable?” If the answer is the former, a temporary grant is usually safer and easier to audit. If the answer is the latter, the emergency path must exist, but it should remain an exception path with stronger governance.
Risk and Threat Considerations
Break-glass accounts concentrate risk because they often carry broad privilege, weak day-to-day visibility, and a temptation to use them outside real emergencies. If they are not tightly controlled, they can become a standing escape hatch that attackers will value for persistence or privilege escalation.
Failure mechanism: The control fails when emergency access is treated as a routine operational shortcut, when the secret is widely known, or when post-use review is weak enough that repeated misuse is not detected.
Impact: Misused break-glass access can bypass normal approval, logging, and least-privilege controls, creating a high-blast-radius path to production systems and making incident forensics harder.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | JIT and break-glass both depend on credential lifecycle and controlled use of authenticators. |
| IA-9 — Service Identification and Authentication | Applies where JIT or break-glass protects non-human admin paths and service access. | |
| AC-6 — Least Privilege | JIT directly operationalises least privilege by limiting standing access and reducing exception exposure. | |
| Recommendation — Enforce short-lived, revocable credentials and rotate any emergency authenticator after use. Apply separate service authentication controls for automated and emergency privileged access paths. Grant the minimum access needed and time-box elevation to the task window. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The choice between JIT and break-glass is fundamentally an access-control design decision. |
| A.5.18 — Access rights | JIT and break-glass both require explicit granting, review, and revocation of rights. | |
| A.8.2 — Privileged access rights | Privileged access rights need stricter handling when comparing temporary and emergency elevation models. | |
| Recommendation — Define access rules that favour temporary elevation and tightly govern emergency access. Review and revoke elevated rights promptly after the task or emergency ends. Restrict privileged rights to named, justified, and time-limited use cases. | ||
Practitioner Guidance
What to prioritise: Use JIT for recurring administrative work, standard production support, and any access request that can be tied to a task, duration, and approver. Reserve break-glass for the small set of recovery scenarios where the normal path is genuinely unavailable.
What to verify: Confirm that every break-glass account has a documented emergency purpose, a protected secret distribution method, tested activation steps, and a mandatory review after use. If any of those are missing, it is not a recovery control, it is unmanaged privilege.
Common mistake: Teams often keep break-glass accounts because they feel safer during outages, then quietly use them for convenience. That erodes the exception model and makes audit evidence less meaningful over time.
Practitioner takeaway: The right default is the control that matches the work pattern, JIT for predictable access, break-glass for genuine recovery. The more routine the use case, the more strongly you should prefer time-bounded privilege over emergency access.