Zero standing privileges: why JIT alone does not remove access risk

At a glance

What this is: This analysis argues that JIT access is not the same as zero standing privileges because temporary access can still sit on top of persistent accounts and permissions.

Why it matters: IAM and NHI teams need to distinguish access checkout from permission lifecycle control, or they will keep approving ephemeral sessions that still leave durable privilege behind.

👉 Read Britive's analysis of zero standing privilege and JIT access

Context

Zero standing privileges means there should be no persistent privilege available when no task is active. In practice, many JIT models only time-limit the session, while the privileged account, entitlement, or shared credential remains in place. That distinction matters for NHI governance because service accounts, bot accounts, and admin identities often outlive the work they were created to do.

The governance gap is not the idea of temporary access. The gap is whether the permission itself is granted and removed at the resource level, or whether a user is simply borrowing a standing privileged path for a short period. For teams managing cloud and SaaS access, that is the difference between reducing exposure and merely narrowing the window of abuse.

Key questions

Q: What is the difference between JIT access and zero standing privilege?

A: JIT access limits when a session can be used, but zero standing privilege removes the underlying entitlement when it is not needed. If the account or permission remains permanently assigned, the organisation still has standing privilege. The practical test is simple: after the task ends, is any elevated right still present anywhere in the target system?

Q: How should security teams implement JIT for privileged access?

A: Security teams should implement JIT at the permission layer, not only at the session layer. That means granting the exact entitlement needed for the task, limiting the duration, and removing the right from the target system automatically. A broker alone is not enough if static permissions remain behind it.

Q: When does JIT access fail to reduce risk?

A: JIT access fails when it wraps a permanent account, a shared privileged identity, or a static entitlement that still exists after the session ends. In those cases, the organisation has shortened exposure time but not removed standing privilege. That is operationally convenient, but it is not a strong least-privilege model.

Q: Should organisations prioritise zero standing privilege over traditional PAM checkout?

A: Yes, when the goal is to reduce privilege persistence rather than just manage access requests. Traditional checkout can still leave durable privileged identities in place, while zero standing privilege removes rights after use. For cloud and NHI environments, the safer benchmark is whether privilege disappears completely when the task is done.

Technical breakdown

JIT access versus JIT permissions

Just-in-time access means a user can reach a privileged resource only for a limited period. Just-in-time permissions go further because the entitlement itself is created only when needed and then removed automatically. In older PAM patterns, the user may check out a session or a credential, but the privileged account still exists permanently with static rights. That is why JIT access can reduce convenience friction without removing the underlying standing privilege. For NHI governance, the important question is whether the system is changing who can act, or merely how long a pre-existing privilege is exposed.

Practical implication: Treat access checkout as insufficient unless the entitlement lifecycle is also enforced at the target system.

Why persistent accounts create residual risk

A persistent privileged account is an enduring control point, even if it is rarely used. If an attacker compromises the account, the platform, or the approval path, the account can still be abused during its active window. Shared privileged accounts add another layer of uncertainty because multiple operators may rely on the same identity, which weakens attribution and complicates audit trails. For NHIs, this is especially relevant because machine identities often accumulate rights over time and are rarely reviewed with the same rigor as human access. The risk is not just exposure duration, but the existence of durable privilege at all.

Practical implication: Review every privileged account for whether it truly needs to exist as a standing identity.

How dynamic permission delivery supports zero standing privilege

A zero standing privilege model applies access at the point of use and removes it when the task is complete or the approved window expires. That requires integration with the target application or cloud control plane, not only with the access broker. The control objective is least privilege at the permission layer, not a proxy session that hides static entitlements underneath. This model aligns more closely with modern zero trust thinking because authorization is conditional, task-bound, and revocable. For NHI programs, the architecture should emphasize ephemeral rights, short-lived authorization, and continuous removal of unnecessary access.

Practical implication: Design privilege workflows so the target system grants and revokes rights directly, rather than relying only on session mediation.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

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

NHI Mgmt Group analysis

Zero standing privilege is an entitlement model, not a scheduling model. If the control only limits when a session starts and ends, the organization may still have standing privilege sitting behind the workflow. That creates a false sense of least privilege because the approval process looks temporary while the underlying access model remains durable. Practitioners should evaluate privilege at the resource level, not just the session layer.

JIT access can improve operations without fixing identity sprawl. A short-lived checkout process still depends on a long-lived account structure if the privileged identity persists underneath. That is acceptable for convenience, but it is not sufficient for strong NHI governance. The better standard is whether the permission can be created, scoped, and removed without leaving a reusable privileged identity behind.

Shared privileged accounts are the weak link in many JIT programs. They blur accountability, complicate revocation, and preserve a high-value identity even when no one is using it. For machine and human operators alike, the control objective should be one identity, one task, one expiration. Teams should treat shared access as a transitional pattern, not a mature state.

Zero standing privilege is becoming the more defensible benchmark for cloud access governance. As workloads, bots, and agents inherit more operational authority, time-boxed access alone will not contain blast radius. The field should move from session-centric controls to permission-centric lifecycle controls. Practitioners should plan for direct entitlement removal, not just temporary access checkout.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to The 2026 Infrastructure Identity Survey.
• Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to The 2026 Infrastructure Identity Survey.
• For a broader control model, see Ultimate Guide to NHIs , Key Challenges and Risks for the visibility and over-privilege patterns that make standing access hard to see.

What this signals

Identity blast radius: when privileges remain standing behind a JIT workflow, the real security boundary is the account design, not the access request. For reader programmes, that means prioritising entitlement removal and revocation automation over approval workflow polish. The operating model should assume that every persistent privileged identity is a future incident path.

With 19% of organisations giving AI systems dramatically more access than human employees, the broader market signal is that privilege inflation is already normalising around autonomous systems, according to The 2026 Infrastructure Identity Survey. That makes zero standing privilege a programme requirement, not an advanced optimisation. Teams should expect stronger pressure to prove that elevated rights truly disappear after use.

The governance takeaway for IAM leaders is that JIT controls should be measured by post-task residual access, not by the fact that an approval occurred. If the identity can be reused tomorrow without re-creating its privilege state, the control is not zero standing. Readers should align audit evidence, entitlement reviews, and cloud policy enforcement around that benchmark.

For practitioners

• Implement permission-level JIT, not session-only JIT Require the target system to grant and revoke the specific entitlement directly, then remove it automatically when the task ends or the TTL expires.
• Eliminate standing shared privileged accounts Replace shared admin identities with task-scoped permissions and individual accountability so audit trails and revocation are reliable.
• Map privileged identities to resource-level lifecycle controls Review cloud, SaaS, and infrastructure accounts to confirm that rights are not merely hidden behind a broker while remaining permanently assigned.
• Set expiration as a control objective, not an exception Make every elevated grant time-bound by design, then verify that expiration removes the right from the target platform rather than only ending the session.

Key takeaways

• JIT access can shorten exposure, but it does not remove standing privilege unless the entitlement itself is temporary.
• Persistent privileged accounts and shared identities are the main reason many JIT programs look stronger on paper than they are in practice.
• Zero standing privilege is the more durable control objective for cloud and NHI governance because it removes access after use, not just at checkout.

Key terms

• Zero Standing Privilege: A privilege model in which elevated access exists only for the duration of a valid task. The goal is to ensure no persistent administrative right remains available when it is not actively required, reducing the blast radius of compromise and simplifying revocation.
• Just-in-Time Access: A temporary access pattern that grants a user or system access only when it is needed. In strong implementations, the access expires automatically and is paired with scoping controls, but weaker versions can still leave durable entitlements underneath the session.
• Standing Privilege: Any permission that remains available outside the immediate need for it. In identity programmes, standing privilege is a risk because it can be reused, inherited, or abused without creating a fresh approval event, especially in cloud and NHI environments.

Deepen your knowledge

JIT access versus zero standing privilege is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a privilege lifecycle model from a similar starting point, it is worth exploring.

This post draws on content published by Britive: Zero Standing Privileges, Not All JIT Eliminates Standing Access. Read the original.