Just-in-time access and the limits of zero standing privilege

At a glance

What this is: This is Delinea's analysis of just-in-time access as a way to replace standing privilege with short-lived access windows across human and non-human identities.

Why it matters: It matters because IAM and PAM teams need controls that reduce privilege exposure without breaking operational workflows for users, service accounts, APIs and AI-driven automation.

Context

Just-in-time access is a time-bound privilege model that grants access only when it is needed and removes it when the task is complete. In this article, the governance question is not whether the pattern is useful, but whether current IAM and PAM programmes can actually define, approve and audit it across humans and NHIs.

The pressure point is zero standing privilege. The article treats JIT as a practical control for cloud, remote work and automation-heavy environments, but the real challenge is policy precision: who can request access, what conditions trigger approval, and how tightly the resulting access window is monitored.

For IAM teams, the interesting part is that the same access pattern is being applied to administrators, service accounts, APIs and AI models. That makes JIT a lifecycle governance problem, not just a privileged access feature.

Key questions

Q: What breaks when just-in-time access is not revoked reliably?

A: The control becomes standing privilege with a temporary label, which means the security benefit disappears after the approval window closes. If revocation fails, the account remains exposed for misuse, lateral movement, and audit exceptions. JIT must be judged by removal as well as granting, otherwise it is only partial governance.

Q: When should organisations replace standing privilege with just-in-time access?

A: Organisations should replace standing privilege with just-in-time access whenever elevated access is not required continuously. JIT reduces the time window in which credentials can be abused, especially for admin tasks, break-glass use, and sensitive automation. It works best when paired with approval, expiry, and logging so temporary access does not become another form of standing privilege.

Q: How do security teams know whether JIT access is actually reducing risk?

A: Look for shorter credential lifetime, fewer always-on permissions, and lower exposure of credentials in code, pipelines, and runtime environments. If the same identities remain broadly reachable or access still persists between tasks, JIT is only changing the workflow, not the risk model.

Q: What happens when service accounts and AI models use JIT access?

A: The same governance problem moves from human privilege management to runtime identity issuance. Teams must control when the non-human identity receives access, what it can reach during execution, and whether the credential disappears before the next task starts.

Technical breakdown

How JIT access replaces standing privilege

Just-in-time access works by issuing elevated rights only for a defined task or session, then revoking them automatically. In practice, that means the identity starts from a base permission set, receives temporary elevation through an approval or policy workflow, and then loses the additional rights when the task ends. The security value comes from collapsing the window in which privilege can be stolen, misused or left behind. For PAM teams, the control is less about the elevation event itself and more about making sure the privilege state is short-lived, traceable and enforced without manual cleanup.

Practical implication: model elevated access as an ephemeral state with explicit expiry, not as a durable entitlement.

JIT access for service accounts, APIs and AI models

When JIT is extended beyond people, it becomes an NHI governance pattern. Service accounts, APIs, bots and AI models do not need permanent credentials if their access can be issued just for execution and then withdrawn. That usually means short-lived credentials, tightly scoped permissions and stronger lifecycle controls around issuance and revocation. The important shift is that non-human identities are no longer treated as always-on infrastructure accounts. They are governed as identities with a start, a task scope and an end state, which is where many programmes are still immature.

Practical implication: treat machine access as issued runtime privilege, not as a permanent account property.

Policy, approval and auditability are the real control surface

JIT does not remove governance burden. It moves the burden into policy design, approval logic and evidence generation. The article points to contextual checks such as risk, location and device validation, which means the decision engine becomes part of the control. That matters because a weak approval policy can still produce overbroad access, while poor logging can make a short-lived elevation effectively unauditable. The control is strongest when request conditions, time limits and revocation events are all machine-enforced and retained as reviewable evidence.

Practical implication: review approval rules and audit logs as primary control points, not administrative afterthoughts.

Breaches seen in the wild

• Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
• BeyondTrust breach 2024: A stolen BeyondTrust Remote Support API key let a China state-sponsored actor reset accounts and reach US Treasury workstations in 2024.

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

JIT access is only a privilege-control pattern if the lifecycle is actually enforced. The article correctly frames the value of short-lived access, but the security outcome depends on whether elevation, expiry and revocation are all machine-held states rather than policy aspirations. Where revocation is delayed or approval is too broad, JIT becomes a naming convention for standing privilege with a shorter lease. Practitioners should evaluate the enforced lifecycle, not the label.

Zero standing privilege is a governance model, not a feature flag. The article shows that ZSP only works when request rules, contextual gates and audit evidence are coherent across identities. That matters because human admins, service accounts and AI-driven systems fail in different ways, but they all need the same governance discipline: no persistent privilege, no untracked elevation, and no orphaned access state. The control surface is policy and evidence, not just automation.

Short-lived access changes the IAM problem from assignment to issuance. Traditional access governance focuses on who has what role at rest. JIT shifts the question to who can obtain privilege at runtime, under which conditions, and with what trace. That is a sharper model for cloud and automation-heavy environments, where long-lived access is the exception that attackers exploit. Practitioners should re-centre their programmes on issuance controls and revocation evidence.

Machine identities make JIT a lifecycle problem across actor types. Once APIs, service accounts and AI models are included, the programme can no longer assume that access review alone will catch privilege risk. The article's real message is that non-human access needs task-scoped governance from request to expiry. Teams that keep machine access in static account models will keep rediscovering the same exposure window under a different name.

JIT narrows exposure, but it does not solve trust by itself. The article links JIT to zero trust, and that is directionally right. The deeper lesson is that continuous verification only works when entitlement scope, contextual approval and post-use revocation are aligned. Without that alignment, the environment still depends on assumptions about who may ask for access and how much authority the workflow is willing to issue.

From our research library:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
• Read next: Just-in-Time Access and Zero Standing Privilege Guide

What this signals

Ephemeral privilege only works when issuance and revocation are treated as the control, not the convenience. That is the practical shift for IAM and PAM teams: stop judging access by who requested it and start judging it by how tightly the privilege state is bounded, monitored and removed. When that lifecycle is weak, standing privilege reappears under a time-limit label.

Access review cadences do not solve short-lived access risk on their own. Short-lived credentials can still be over-scoped, over-approved or left insufficiently evidenced, so the governance programme has to move closer to issuance-time controls. That is especially true where service accounts, APIs and AI models are in the same operational path as human admins.

For practitioners

• Define task-scoped elevation policies Set explicit rules for which roles, systems and actions can receive temporary privilege, including time limits and contextual conditions such as risk or device posture.
• Replace standing machine credentials Move service accounts, APIs, bots and AI workflows to short-lived credentials that expire automatically after the approved task completes.
• Instrument revocation and audit trails Log every approval, privilege grant and automatic revocation so reviewers can reconstruct who had access, when they had it and why it was issued.
• Validate approval logic for overgranting Test whether request workflows and contextual checks can still issue access that is broader than the task requires, especially in cloud and automation-heavy environments.
• Extend governance to non-human identities Include service accounts, APIs and AI models in the same lifecycle controls used for privileged human access, with the same expectation of expiry and review.

Key takeaways

• Just-in-time access reduces the exposure created by standing privilege, but the control only works when expiry and revocation are reliably enforced.
• The article's core evidence is a mixed-identity operating model in which humans, machines, APIs and AI models all need time-bound privilege.
• Practitioners should focus on policy precision, auditability and lifecycle governance, because those are the points where JIT succeeds or fails.

Key terms

• 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.
• Zero Standing Privilege: A control model in which an identity does not keep persistent access unless it is actively needed. For NHIs, this means credentials and permissions are issued for a narrow task and then removed. It reduces the time window and reuse value of stolen access.
• Ephemeral Credentials: Ephemeral credentials are short-lived access artefacts issued for a limited task or session. They reduce the window for abuse, but they only improve security when paired with strong scope limits, telemetry, and automatic revocation at task completion.
• Privilege Persistence Window: Privilege persistence window is the period during which a credential, token, or privileged relationship remains usable after it should have been revoked or rotated. Longer windows increase blast radius because compromised access can survive long enough to be reused, moved laterally, or hidden from review.

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 building or maturing an IAM programme, it is worth exploring.