Just-in-Time Access & Break-Glass Accounts

Just-in-Time Access and Break-Glass Accounts

Administrative accounts with permanent, broad privileges are the most valuable target in any environment. If an engineer has production database admin rights every day, a phished password or stolen session gives an attacker the same rights every day. Most of the time, nobody needs those privileges. Just-in-time (JIT) access removes standing privileges: engineers are eligible for elevated roles, request them for a specific reason and duration, receive them after approval or policy checks, and lose them automatically afterward — with every grant logged.

JIT systems depend on identity providers, approval workflows, and networks that can themselves fail. Break-glass accounts are the planned exception: a small number of emergency accounts that work when everything else does not, protected so heavily and monitored so closely that any use is an event.

TL;DR

Replace standing admin rights with eligibility plus time-bound activation.
Every elevation records who, what, why, and for how long; approvals can be human or policy-based for low-risk roles.
Record sessions and send all grants and actions to centralized audit logs.
Break-glass accounts must work when SSO, MFA providers, or JIT tooling are down — and nothing else should depend on them.
Protect break-glass credentials with phishing-resistant hardware keys, split custody, and alerts on every sign-in.
Test emergency access on a schedule, rotate credentials after each use, and review every use.

Quick Example

Requesting temporary elevation through an access platform, with the incident as justification:

An access request record that auditors and responders can read later:

Alerting on any use of the AWS root account, which serves as a break-glass identity (EventBridge rule pattern):

Core Concepts

Standing Versus Just-in-Time Privilege

The JIT Workflow

Eligibility: users or groups are eligible for specific roles in specific scopes (one account, project, cluster, or database).
Request: the user selects a role, duration, and justification, often a ticket or incident ID.
Approval: a peer, manager, or on-call lead approves — or policy auto-approves low-risk roles during on-call shifts.
Activation: the role is granted for a bounded time, with step-up MFA.
Revocation: access ends automatically; users can release it early.
Audit: grants, approvals, and actions are logged and, for sensitive systems, sessions are recorded.

Tooling

Break-Glass Accounts

Break-glass accounts exist for when the normal path is unavailable: the identity provider is down, a conditional access policy locks out all administrators, the MFA service fails, or the JIT tool itself is broken during an incident. Design principles:

Independent of normal dependencies: cloud-only accounts not federated to the IdP, excluded from policies that could lock them out, and not dependent on the systems they might be needed to fix.
Few and named: typically two per critical platform, each with a documented purpose.
Strongly protected: long random passwords or, better, FIDO2 hardware keys stored in separate secure locations, with split custody so no single person can use them alone.
Highly visible: alerts to security and leadership on every sign-in attempt, successful or not.
Never used for routine work.

Testing and Reviewing Emergency Access

Scheduled tests (for example quarterly): sign in with each break-glass account in a controlled exercise, confirm alerts fire, then rotate credentials if they were exposed.
After every real use: rotate credentials, review all actions taken, document why normal access failed, and fix that root cause.
Documented procedure: where the credentials are, who may authorize use, and how to use them — accessible offline during an outage.
Review eligibility for JIT roles regularly as teams and responsibilities change.

Best Practices

Start With the Most Powerful Roles

Move global administrators, production database admins, and cloud account owners to JIT first; these carry the most risk.

Keep Requests Fast

If elevation takes an hour, engineers will demand standing access again. Use policy-based approval for on-call responders and short default durations.

Tie Grants to Work

Require ticket or incident references and link session logs to them, so access reviews and post-incident analysis can see what was done and why.

Separate Break-Glass From Everything Else

No automation, service, or person should depend on break-glass accounts during normal operations.

Common Mistakes

JIT With Unlimited Durations

Break-Glass Accounts That Depend on SSO

Silent Break-Glass Use

FAQ

What is just-in-time access?

A privileged access model in which users have no standing elevated permissions; they request a specific role for a limited time, receive it after approval or policy checks, and lose it automatically when the time expires.

What is a break-glass account?

An emergency account reserved for situations when normal administrative access is unavailable, such as an identity provider outage. It is tightly protected, rarely used, and monitored so that any use is immediately visible.

How many break-glass accounts should we have?

Usually two per critical platform, so one remains available if the other's credentials or holder are unavailable, while keeping the number small enough to monitor closely.

Should break-glass accounts use MFA?

Yes, with methods that do not depend on the systems that might be failing — typically phishing-resistant FIDO2 hardware keys stored securely — while excluding the accounts from policies that could lock them out.

Does JIT access slow down incident response?

It can if poorly designed. Policy-based approval for on-call responders, short request flows, and pre-defined emergency roles keep elevation to seconds while preserving audit trails.