JITA versus JITP: what zero standing privilege really requires

At a glance

What this is: This is an analysis of why just-in-time provisioning and just-in-time access are not equivalent, and why only the latter removes standing privilege.

Why it matters: For IAM and NHI practitioners, the difference changes whether access is merely time-limited or actually ephemeral, which affects blast radius, revocation, and auditability.

By the numbers:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• NHIs outnumber human identities by 25x to 50x in modern enterprises.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.

👉 Read SGNL's analysis of JITP versus JITA for Zero Standing Privilege

Context

Just-in-time access is a control pattern for reducing persistent privilege, but it only works if access truly disappears when the work is done. In NHI governance, that distinction matters because many enterprises still rely on time-limited accounts, role assignments, and delayed cleanup, which leaves a residual attack window even when the process is described as temporary.

The article’s central claim is that Zero Standing Privilege depends on session-scoped authorisation, not simply shorter-lived provisioning. That is a familiar problem for IAM teams managing human access, and it becomes more pronounced for non-human identities because service accounts, tokens, and automated workflows are often designed to persist unless they are explicitly revoked or re-evaluated.

Key questions

Q: How should security teams implement just-in-time access without leaving standing privilege behind?

A: Treat access as a live session, not a temporary account. Enforce real-time policy evaluation at request time, bind access to context such as device posture and business justification, and revoke it when the session or context changes. If the identity or role remains reusable after the task, the organisation has not achieved Zero Standing Privilege.

Q: What is the difference between just-in-time provisioning and just-in-time access?

A: Just-in-time provisioning creates an account or role for a limited period, then removes it later. Just-in-time access evaluates the request in real time and grants privileges only for the session, with no lingering entitlement to reuse. The first reduces duration, while the second removes persistence and better supports Zero Standing Privilege.

Q: When does just-in-time access reduce risk, and when does it still leave exposure?

A: It reduces risk when access is truly session-scoped and revocation is immediate. It still leaves exposure when the process relies on fixed time windows, manual cleanup, or pre-created identities that remain usable during the window. In those cases, attackers may still exploit the access before it disappears.

Q: Why do non-human identities make Zero Standing Privilege harder to achieve?

A: Non-human identities are often built to persist, automate, and reuse credentials, which makes them harder to tie to a single interactive session. That means time-boxed controls can leave behind usable secrets or roles unless lifecycle management, rotation, and runtime revocation are enforced. For machine access, persistence is the default risk.

Technical breakdown

JIT provisioning versus session-based access

Just-in-time provisioning creates an account or entitlement at the moment it is needed, then removes it later on a schedule. The access is temporary, but the identity and permission model still exists in a static form during that window. Session-based access works differently: authorisation is evaluated at request time, access is bound to a live session, and privilege evaporates when the session ends or context changes. That difference matters because a temporary role assignment can still be harvested, abused, or chained into other actions before revocation occurs.

Practical implication: Practitioners should treat time-limited provisioning as a reduction in exposure, not as Zero Standing Privilege.

Why Zero Standing Privilege depends on continuous evaluation

Zero Standing Privilege requires more than short-lived credentials. It depends on continuous access evaluation, where identity, device state, business justification, and environmental context are checked before and during the session. That allows access to be revoked when the user or workload no longer meets policy. In NHI environments, the same logic must extend to service accounts and agent-driven workflows, because context can change after initial approval and automated activity can outlive the original request.

Practical implication: Security teams should design access controls that can re-evaluate privilege mid-session, not only at issuance.

Where standing privilege hides in modern IAM and NHI workflows

Standing privilege often survives in places that look temporary on paper. Examples include pre-created service accounts, cached credentials, delegated roles, and approvals that end access only after the window closes. For non-human identities, the problem is sharper because machines do not self-report intent or stop using privileges when a task changes. That makes cleanup jobs, fixed TTLs, and manual revocation insufficient on their own. If the control still leaves a usable identity behind, the organisation has not eliminated standing privilege.

Practical implication: Map every access path to find where residual credentials or roles remain usable after the task ends.

Threat narrative

Attacker objective: The attacker wants to turn temporary access into a broader operational foothold before the organisation removes it.

1. Entry occurs when an attacker acquires a temporary but usable credential or role before the access window closes.
2. Escalation follows if that access can be reused, chained, or converted into broader permissions during the active session.
3. Impact comes from the attacker moving laterally or operating under legitimate-looking access before revocation takes effect.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.

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

NHI Mgmt Group analysis

JITP is a risk-reduction pattern, not a standing-privilege solution. Short-lived provisioning can shrink exposure, but it still creates a usable identity, a usable role, and a usable window. That is enough for attackers who move quickly or automate exploitation. Practitioners should reserve the term Zero Standing Privilege for controls that remove persistent privilege rather than merely shortening it.

Session-scoped authorisation is the real control boundary for Zero Standing Privilege. The important decision is not when access was requested, but whether the system can continuously validate that access remains justified. That is where contextual signals, policy evaluation, and revocation hooks become the governance layer. Practitioners should align access design to live authorisation, not static approval records.

Non-human identities expose the weakness in time-boxed access models. Service accounts, tokens, and agent workflows do not naturally stop when a task changes, which means temporary access often persists in practice even when policies say otherwise. That creates what we can call ephemeral credential trust debt: the gap between assumed expiration and actual operational risk. Practitioners should close that gap with explicit lifecycle controls and runtime revocation.

ZSP becomes credible only when access removal is deterministic. Manual cleanup and delayed revocation leave room for misuse, especially in environments where machine identities outnumber humans by large multiples and operate at machine speed. The discipline now is to combine policy, telemetry, and automation so that access disappears as reliably as it is granted. Practitioners should measure whether revocation is immediate, provable, and universal across identity types.

From our research:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
• From our research: 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• For a deeper control lens, NHI Lifecycle Management Guide shows how provisioning, rotation, and offboarding should work together across machine identities.

What this signals

Ephemeral credential trust debt: the governance problem is no longer whether access is temporary, but whether the organisation can prove it truly vanished. That becomes a programme issue when cleanup, rotation, and revocation are handled as separate tasks instead of one control chain. For practitioners, the operational question is whether access removal is observable and automated across human and non-human identities.

With 71% of NHIs not rotated within recommended time frames, the control gap is already visible in machine identity operations. Teams that continue to rely on expiry alone will keep inheriting a delay between theoretical removal and actual risk reduction, which is exactly the window attackers exploit. Practitioners should prepare for stricter evidence requirements around revocation timing and access history.

Zero Standing Privilege also aligns closely with established guidance in the NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10, because both emphasise controlled access, monitoring, and response. The practical signal is that machine access governance is moving from design intent to measurable operational proof.

For practitioners

• Separate provisioning from authorisation Classify each access path by whether it creates an identity first or evaluates access at session start. Prefer controls that grant access only after real-time policy checks and remove it when the session ends. This is the difference between temporary access and Zero Standing Privilege.
• Inventory residual privilege in non-human identities Review service accounts, API tokens, and delegated roles for permissions that remain usable after the task completes. Pay special attention to cached credentials, long-lived sessions, and manual cleanup steps that can leave access active beyond its intended window.
• Bind revocation to context change Trigger access removal when device state, workload state, or business justification changes. If the system can only revoke at expiry, it still tolerates a compromise window. Use continuous evaluation for high-risk production access and all automation paths.
• Adopt lifecycle controls for machine identities Apply the same discipline you would use for human access, including issuance approval, rotation, expiry, and offboarding. The goal is to make every non-human credential traceable from creation to retirement, not just time-limited.
• Map ZSP to measurable controls Track whether access is ephemeral, whether revocation is immediate, and whether no persistent entitlement remains after the session. If any of those three fail, the control is reducing standing privilege rather than eliminating it.

Key takeaways

• Temporary access is not the same as ephemeral access, and that distinction determines whether standing privilege remains in the environment.
• Machine identities make the gap between policy and reality larger because they can retain reusable credentials long after a task changes.
• Practitioners should measure revocation speed, residual entitlements, and lifecycle coverage before calling a control Zero Standing Privilege.

Key terms

• Just-in-Time Access: Just-in-time access grants privilege only when a task is actively underway and removes it when the session ends or context changes. It is a runtime authorisation model, not merely a shorter approval window, and it is the control pattern most aligned to Zero Standing Privilege.
• Just-in-Time Provisioning: Just-in-time provisioning creates an account or entitlement at the moment it is needed, then removes it later. It reduces standing access duration, but it still relies on a static identity or role existing during the access window, which leaves room for misuse if revocation lags.
• Zero Standing Privilege: Zero Standing Privilege is an access model where no identity retains persistent, reusable privilege outside an active task. The control goal is not just short duration but the absence of standing access, supported by continuous evaluation and deterministic revocation.
• Continuous Access Evaluation: Continuous access evaluation is the practice of rechecking authorisation after access has been granted, using fresh signals such as device posture, session context, and policy state. It helps ensure that access remains valid throughout the session rather than only at the start.

Deepen your knowledge

JIT access, Zero Standing Privilege, and machine identity lifecycle controls are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a governance programme around session-based access, it is worth exploring.

This post draws on content published by SGNL: Beyond the buzzwords, why JITA not JITP delivers true Zero Standing Privilege. Read the original.