Just-in-time access exposes the limits of standing privilege

At a glance

What this is: This is a practitioner analysis of just-in-time access that finds JIT only reduces risk when approval, monitoring, and automatic revocation are enforced, because standing privilege is still the baseline in many programmes.

Why it matters: It matters because IAM and PAM teams have to decide whether JIT is a true control shift or just a process layer over standing access, with direct implications for privileged exposure, auditability, and insider risk.

Context

Just-in-time access is a time-bound privilege model, not a new identity type. It grants access only when a task requires it and revokes that access when the task ends, but the control only changes risk if the standing privilege model is actually removed.

The governance gap is that many IAM programmes still treat privileged access as persistent by default, then add requests, approvals, and logging around it. That helps, but it does not by itself erase the assumption that access can remain in place indefinitely until someone notices.

For organisations trying to reduce insider risk, excessive privilege, and audit exposure, the real question is whether JIT is being used to replace standing privilege or merely to decorate it.

Key questions

Q: What breaks when standing privilege is used for short-lived business tasks?

A: The identity no longer matches the work. Access persists after the task ends, which expands blast radius, complicates audits, and makes separation-of-duties issues harder to catch. Short-lived work needs short-lived access if governance is going to stay aligned to reality.

Q: When does just-in-time access reduce more risk than it adds?

A: Just-in-time access reduces more risk when the organisation can reliably automate approval, scope the privilege to a task, and revoke it immediately after use. It adds risk when teams keep broad base roles, weak review processes, or manual workflows that delay revocation. JIT is most effective as part of a broader zero-standing-privilege model.

Q: What are the signs that a JIT programme is not really enforcing least privilege?

A: Common warning signs include rubber-stamped approvals, long approval delays, frequent bypasses, and repeated access requests that look identical regardless of context. Those patterns show the process is moving access around, not actually constraining it.

Q: How should security teams govern privileged access across cloud and legacy systems?

A: Teams should govern privileged access by resource class, not with one uniform assumption set. Legacy servers can often tolerate traditional PAM patterns, but cloud databases, Kubernetes, and internal web apps usually need shorter-lived access, broader protocol coverage, and stronger lifecycle controls. The right test is whether the control plane can revoke, log, and prove access consistently across all estates.

Technical breakdown

Standing privilege keeps the attack surface open

Standing privilege means the account, token, or elevated role exists continuously, even when no task is being performed. In practice, that creates a persistent window for abuse because the control is about who may use access, not when access exists. JIT changes the exposure model by tying elevation to a task and a time bound, but only if the underlying privileged path is truly dormant outside the approved window. If approval exists but access remains broadly usable, the programme has improved workflow without materially changing the privilege model.

Practical implication: remove always-on elevation paths, not just add approval steps around them.

Approval, monitoring, and revocation are separate control layers

JIT access is often described as a single capability, but it is really a sequence of controls. Approval validates the request, monitoring records what happened during the session, and revocation removes access at the end of the task. If any one layer is weak, the model degrades quickly: approvals can become rubber stamps, monitoring can become passive logging, and revocation can be delayed or incomplete. That is why JIT should be evaluated as an end-to-end privilege lifecycle, not as a front-end request form.

Practical implication: test each stage independently, especially whether revocation is automatic and enforced across all privilege paths.

Temporary elevation only works when policy boundaries are precise

Temporary elevation is effective only when the policy defines who can request access, for what purpose, to which systems, and for how long. Vague policy creates either overgranting or operational delays, both of which undermine the control. The article’s examples, including justification-based access and ephemeral accounts, show that different implementation patterns still depend on the same governance question: can the organisation prove the access was necessary, bounded, and removed on schedule? Without that evidence, JIT becomes a procedural label rather than a security boundary.

Practical implication: define scope, duration, and approval criteria tightly enough that access can be audited end to end.

Threat narrative

Attacker objective: The objective is to exploit persistent privileged access to reach sensitive systems or data with less friction and less chance of timely containment.

1. Entry occurs through standing privileged access that remains available outside the task window, giving an attacker or insider a reusable route into sensitive systems.
2. Privilege is abused when the account or elevation path is used beyond the intended task, especially if approval was weak or access was not tightly scoped.
3. Impact follows when the excessive access window is long enough to support unauthorised action, data exposure, or privileged misuse before revocation is enforced.

Breaches seen in the wild

• Coinbase insider bribery breach 2025: Criminals bribed overseas Coinbase support agents to copy data on 69,461 customers, then tried to extort $20 million.
• Twitter source code leak 2023: Twitter source code and internal tools were posted to GitHub by "FreeSpeechEnthusiast" and stayed public for months before a 2023 takedown.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Standing privilege is the control assumption JIT is meant to break. Traditional IAM and PAM programmes often presume access can remain available until a review cycle catches it. That assumption fails the moment privilege is left open between tasks, because the exposure window becomes the control weakness itself. The practitioner conclusion is simple: if privilege remains always-on anywhere in the estate, JIT has not yet replaced the old model.

Just-in-time access works as a governance model only when it is enforced as a privilege lifecycle. Request, approval, issuance, monitoring, and revocation are not supporting details, they are the control boundary. Organisations that focus on the request step alone are managing process, not risk. The practitioner conclusion is to treat JIT as lifecycle governance for elevated access, not as an identity convenience feature.

Temporary elevation exposes the same least-privilege gap across human and machine-driven administration. Whether the subject is a person using an admin path or a service workflow using privileged access, the risk is persistent entitlements that outlive the task. That makes JIT relevant to broader identity governance because it shows how privilege should be time-bound, task-bound, and automatically withdrawn. The practitioner conclusion is to align PAM decisions with actual task duration, not with role permanence.

Ephemeral access only changes outcomes when policy precision matches operational reality. If systems, approvals, and revocation logic are inconsistent across platforms, the organisation still has standing privilege in practice even if the policy says otherwise. This is where many programmes create false confidence: they document least privilege without enforcing it at runtime. The practitioner conclusion is to measure whether access truly disappears when the task ends, not whether a workflow was completed.

JIT reveals the difference between auditability and prevention. Logs, approvals, and reports improve accountability, but they do not stop access from being misused if revocation and scope control are weak. That distinction matters because many teams overestimate the security value of visibility alone. The practitioner conclusion is to use monitoring as evidence, not as a substitute for privilege containment.

From our research library:

• 91% of organisations say at least half of their privileged access is always-on, and only 1% have fully implemented just-in-time privileged access, according to a CyberArk study.

What this signals

JIT exposes a control design problem, not just an access pattern change. If approval and revocation are not enforced as hard boundaries, the programme still depends on standing privilege in practice. That is why IAM teams should measure whether access disappears at the end of the task, not whether the request was approved.

Privilege lifecycle is the real governance unit. The article’s model shows that request, issuance, monitoring, and removal have to be aligned, or JIT becomes a partial control. For practitioners, the next step is to inspect whether their PAM and IAM processes actually remove privilege across all admin paths.

Task-bound access should be evaluated alongside PAM policy design. When policies are too broad or too slow to enforce, teams either overgrant access or create workarounds. The practical signal is whether the organisation can prove that elevated access was necessary, bounded, and removed on schedule.

For practitioners

• Map every standing privileged path Identify admin, support, and service access paths that remain active outside task windows, then classify which can move to time-bound elevation and which should be removed entirely.
• Separate approval from enforcement Make sure request approval, session start, activity logging, and access revocation are independently controlled so a successful approval cannot outlive the intended task duration.
• Define task-specific access policies Specify which systems can be requested, who can approve them, what justification is required, and the maximum duration for each class of privileged request.
• Audit revocation as a control outcome Check whether access is actually removed at the end of the session across all platforms, including cloud, on-premise, and third-party admin paths.

Key takeaways

• Standing privilege remains the baseline risk that JIT is meant to replace, and leaving it in place preserves a large abuse window.
• The article’s core control logic is that approval, monitoring, and automatic revocation must operate together, or JIT becomes only a process wrapper.
• For IAM and PAM teams, the real test is whether privileged access truly disappears after the task finishes across every platform and admin path.

Key terms

• Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
• Just-in-Time Access Request: Just-in-Time Access Request is a pattern that grants access only when it is needed and only for the duration required. It reduces standing privilege by making access temporary, policy driven, and task scoped. This approach is especially useful for contractors, sensitive systems, and short-lived operational work.
• Temporary Elevation: A method of raising permissions on demand for a limited period so a user or operator can complete a defined task. The control is useful only when the scope is narrow, the request is well evidenced, and revocation happens reliably after use.
• Ephemeral Account: A short-lived account created for a specific task and removed or disabled after use. In NHI governance, ephemeral accounts are valuable only when their associated secrets, tokens, or certificates are also invalidated and their activity is fully logged.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.