What is the difference between JIT access and ZSP?

Why This Matters for Security Teams

JIT access and ZSP are closely related, but they solve different problems. JIT is an operational control that issues permissions only when a task needs them. ZSP is the policy stance that standing privilege should not exist by default. That distinction matters because teams often think they have “least privilege” simply by using RBAC, when the real gap is persistent access that no one can justify at the moment of use.

This is where NHI governance becomes practical. The Ultimate Guide to NHIs shows how broadly these identities are overprivileged, and the OWASP Non-Human Identity Top 10 reinforces that standing credentials are a recurring attack path. In a mature program, ZSP should guide policy design while JIT handles execution for elevated access, service accounts, and admin workflows. The difference is especially important for secrets, API keys, and machine users that tend to linger long after their original use case has changed. In practice, many security teams encounter persistent privilege only after an incident has already exposed it, rather than through intentional access design.

How It Works in Practice

In practice, ZSP starts with the assumption that no NHI should carry permanent elevation. Access is granted only when an authenticated workload, agent, or operator has a specific task, approved context, and a time limit. JIT is the control layer that makes that possible by issuing ephemeral credentials, short-lived tokens, or temporary role bindings, then revoking them automatically when the task completes. That is why JIT is often implemented alongside PAM, policy-as-code, and centralized secrets management rather than as a standalone feature.

For NHIs, the right pattern is usually: authenticate the workload, verify the requested action, issue the minimum permission set, and expire it quickly. The Ultimate Guide to NHIs — Key Challenges and Risks notes that excessive privilege is widespread, which is why JIT is valuable for reducing blast radius. Current guidance from the OWASP Non-Human Identity Top 10 supports short-lived access, rotation, and better secret hygiene because long-lived credentials are difficult to govern safely.

• ZSP answers “should this identity hold access at rest?” The answer should usually be no.
• JIT answers “how does this identity get access when it needs to act?”
• Ephemeral secrets reduce exposure if tokens are stolen or copied.
• Time bounds and explicit approval make audit trails easier to defend.

For implementation, teams should pair JIT with workload identity, so the system proves what the workload is before any privilege is issued. These controls tend to break down in highly distributed environments with unmanaged scripts, ad hoc automation, or legacy service accounts because there is no reliable place to enforce runtime approval and revocation.

Common Variations and Edge Cases

Tighter JIT controls often increase operational overhead, so organisations must balance reduced standing privilege against approval latency and support burden. That tradeoff is real, especially when production systems need near-continuous automation or when incident responders need emergency elevation without waiting for manual review.

There is no universal standard for every environment yet. Some teams treat ZSP as a hard rule and allow exceptions only for break-glass accounts. Others apply it selectively to privileged actions while leaving low-risk machine-to-machine access on short-lived credentials. Best practice is evolving, but the direction is consistent: avoid persistent secrets, shorten token lifetimes, and make every privilege grant explainable at request time. The 52 NHI Breaches Analysis is a useful reminder that long-lived access and weak governance are common failure patterns, not edge cases.

One subtle edge case is automated remediation. If a bot needs repeated access throughout the day, the design should still favour repeated JIT issuance rather than one broad standing grant. Another is shared service accounts, which often hide behind RBAC and make ZSP hard to enforce because no single owner can attest to the access need. The Ultimate Guide to NHIs — What are Non-Human Identities is helpful for separating those identities from human access models. If the environment cannot issue and revoke access reliably at runtime, the ZSP model remains aspirational rather than operational.

Related resources from NHI Mgmt Group

• What is the difference between JIT access and Zero Trust for NHIs?
• How should security teams decide whether JIT access is safe for non-human identities?
• What is the difference between privilege reduction and secret rotation?
• What is the difference between a rules-based secret scanner and a hybrid scanner?