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

At a glance

What this is: This is an editorial analysis of just-in-time access and how it supports zero trust and zero standing privilege by time-bounding elevated access.

Why it matters: It matters because IAM teams need to decide where JIT improves control, where it only moves risk, and how to apply it consistently across human, NHI, and autonomous identity programmes.

👉 Read Delinea's blog post on just-in-time access and zero standing privilege

Context

Just-in-time access is a time-bound privilege model that grants elevated access only when a task requires it and removes it when the task ends. In identity programmes, it sits at the junction of PAM, Zero Trust Architecture, and NHI governance because the same control logic now has to work for administrators, service accounts, APIs, and AI-enabled workflows.

The governance problem is not whether JIT is useful. It is whether organisations can define, approve, observe, and revoke access fast enough across identity types that behave very differently at runtime. That is the practical question for IAM, IGA, PAM, and workload identity teams.

Key questions

Q: How should security teams implement JIT access across human and machine identities?

A: Security teams should separate human request workflows from workload identity controls and treat service accounts, API keys, and AI systems as different actors. Human JIT can rely on approvals and session controls, while machine JIT needs ephemeral credentials, deterministic revocation, and policy enforcement that survives cloud and pipeline boundaries.

Q: Why does JIT access fail when privilege is still effectively standing?

A: JIT fails when a temporary grant does not fully disappear from downstream systems, cached sessions, or inherited roles. In that case, the organisation has only renamed standing privilege instead of removing it, and attackers can still reuse the access after the intended window closes.

Q: How do organisations know if zero standing privilege is actually working?

A: They know it is working when access cannot be reused outside the intended task window and revocation is provable across every system that accepted the privilege. Evidence should include audit logs, session termination checks, and tests that confirm cached authority does not persist.

Q: What is the difference between JIT access and zero trust in practice?

A: JIT is a time-bound privilege pattern, while zero trust is a broader model of continuous verification. JIT can support zero trust, but it is not enough on its own if access is still granted once and then left unchallenged for the rest of the session.

Technical breakdown

How JIT access changes privilege lifecycle control

JIT access replaces persistent elevation with short-lived privilege grants tied to a specific action or session. In practice, that means the identity platform must create a temporary entitlement, validate the request context, and then tear down the privilege state cleanly. The control only works when the grant and revoke events are deterministic and logged. If session boundaries are unclear, or if downstream systems cache authority longer than the JIT window, the model breaks and leaves residual access behind.

Practical implication: map every elevated path to a revocation event and verify the downstream systems actually honour it.

JIT access for service accounts, APIs, and AI systems

When JIT is extended beyond humans, it becomes a workload identity pattern rather than a convenience feature. Service accounts, API keys, and AI models do not wait for a helpdesk-style approval flow in the same way a person does, so JIT depends on orchestration, policy evaluation, and ephemeral credential delivery. The risk is that teams treat machine access as if it were human access with a shorter timer. That misses the real issue, which is whether the workload can be authenticated, scoped, and revoked without leaving standing secrets behind.

Practical implication: separate human JIT workflows from workload identity workflows and enforce different control paths for each.

Why zero standing privilege depends on reliable policy enforcement

Zero standing privilege only exists when no durable entitlement remains between tasks. That sounds simple, but in distributed environments the actual control plane has to enforce it across cloud IAM, PAM, CI/CD, and federated identity boundaries. If approvals are inconsistent, or if some systems allow cached access outside the policy engine, standing privilege reappears in disguised form. JIT therefore behaves less like a feature and more like a governance test of whether the organisation can maintain continuous least privilege in practice.

Practical implication: test JIT policies against cloud, pipeline, and federated access paths before claiming zero standing privilege.

Threat narrative

Attacker objective: The attacker wants short-lived privilege to behave like standing privilege long enough to reach sensitive systems and data.

1. Entry occurs when attackers target privileged identities that still rely on long-lived secrets, cached sessions, or weak approval logic rather than true time-bound access.
2. Escalation happens when elevated access persists beyond the intended session window, letting the attacker reuse or pivot from a privilege grant that was supposed to expire.
3. Impact follows when the attacker uses transient but high-value access to move laterally, alter systems, or exfiltrate data before controls notice the privilege should have vanished.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

JIT access is a privilege lifecycle control, not a substitute for governance. The control only works when approval, provisioning, revocation, and audit all align across the full access path. Many programmes adopt JIT as if the timer itself creates security, but the real issue is whether the entitlement disappears everywhere it matters. Practitioners should treat JIT as one control in a larger identity governance chain, not as an endpoint.

Standing privilege is the failure mode JIT is meant to suppress, but machine identity makes the failure easier to hide. Service accounts, APIs, and automation often hold credentials longer than teams assume, especially in CI/CD and multi-cloud environments. That means the same JIT label can mask a persistent secret if revocation is not truly enforced. Practitioners should audit whether machine access is genuinely ephemeral or merely time-limited on paper.

Zero Trust Architecture makes JIT more defensible, but only when verification extends through the full session. Continuous verification is not just an approval gate at the start of access, it is a requirement that access remains justified while it exists. If the organisation cannot re-evaluate context during use, then JIT becomes a one-time exception process wrapped in zero trust language. Practitioners should align JIT design with ZT-NIST-207 rather than treat it as a separate access shortcut.

Ephemeral credential trust debt is the hidden cost of modern NHI governance. The more teams rely on short-lived access, the more they depend on perfect orchestration, logging, and offboarding across fragmented identity systems. That debt accumulates when teams cannot prove that a secret truly expired everywhere it could be used. Practitioners should measure that debt as a governance risk, not just a technical inconvenience.

Human access models and machine access models are converging, but the controls cannot be copied unchanged. A developer request workflow, a service account token, and an AI-driven task have different runtime behaviours, even when they all look like privileged access on paper. Treating them as equivalent creates false confidence in JIT programmes. Practitioners should design governance by actor type, not by a single access-request pattern.

From our research:

• 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to The 2024 Non-Human Identity Security Report.
• 59.8% of organisations see value in a solution that simplifies non-human access management and introduces dynamic ephemeral credentials.
• For a deeper governance lens, see Ultimate Guide to NHIs , Why NHI Security Matters Now for the broader access-risk context.

What this signals

Ephemeral credential trust debt: the operational risk is no longer whether teams can issue short-lived access, but whether they can prove that access really disappears across cloud, pipeline, and federation boundaries. That proof burden rises as identity types multiply, which is why JIT should be measured as a lifecycle control, not a convenience feature.

With 59.8% of organisations seeing value in dynamic ephemeral credentials, the market signal is clear: practitioners want shorter-lived access, but they still need governance evidence that the privilege lifecycle is actually enforced. For implementation guidance, the next step is to align JIT with the control patterns in OWASP Non-Human Identity Top 10.

As AI-enabled workflows gain more privileged access, JIT becomes a test of whether policy engines can handle actor-specific behaviour rather than a generic approval queue. That is why teams should watch for access paths where the timer expires but the authority does not, especially in workload identity and delegated automation.

For practitioners

• Map every privileged path to a revocation checkpoint Document where elevated access is created, where it is consumed, and which systems must confirm that revocation actually propagated. Include cloud IAM, PAM, CI/CD, and any federated workload identity path in the same control test, because JIT fails when one downstream system keeps the privilege alive.
• Separate human and machine JIT workflows Do not force service accounts, API tokens, and AI workloads through the same request-and-approval pattern used for people. Build distinct policy logic for workload identity so ephemeral credentials, not human approvals, are the primary control surface.
• Validate zero standing privilege with session-level testing Run test cases that confirm access disappears before the next task can begin, not just after a nominal expiry timer. Verify that cached sessions, inherited roles, and API tokens do not preserve authority beyond the intended JIT window.
• Instrument JIT for audit, drift, and exception reporting Track which privileges were requested, why they were approved, how long they lasted, and where revocation failed or was bypassed. Use the audit trail to identify patterns of privilege creep, repeated exceptions, and systems that cannot enforce time-bound access consistently.

Key takeaways

• JIT access reduces exposure only when privilege is fully removed across the entire access path, not just in the primary console.
• Machine identities make JIT harder to govern because ephemeral access can still hide persistent secrets, cached sessions, or incomplete revocation.
• Security teams should validate JIT as a lifecycle control, with separate treatment for human and workload identities and evidence that zero standing privilege is real.

Key terms

• Just-in-time access: Just-in-time access is a privilege model that grants elevated access only for a specific task and removes it when that task is complete. In practice, it depends on policy, session control, and revocation behaving correctly across every system that can use the entitlement.
• Zero standing privilege: Zero standing privilege is the state where no durable elevated access remains available between tasks. For identity teams, it is not a slogan but an enforcement outcome, and it fails if cached sessions, inherited roles, or unmanaged secrets preserve authority beyond the intended window.
• Ephemeral credentials: Ephemeral credentials are short-lived secrets or tokens issued for a narrow purpose and then invalidated. They are central to workload identity governance because they reduce persistence, but only if creation, propagation, and revocation are all trustworthy and observable.
• Workload identity: Workload identity is the identity assigned to a non-human system such as an API, service account, bot, or AI-enabled process. It requires different governance than human identity because the subject can act continuously, automatically, and at machine speed.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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.

This post draws on content published by Delinea: Just-in-time access: Strengthening security in a zero-trust world. Read the original.