What is the difference between just-in-time access and zero standing privilege?

How JIT and ZSP differ in practice

Just-in-time access is the delivery pattern, while zero standing privilege is the policy target. JIT answers the operational question of when access is granted and revoked; ZSP answers the governance question of whether access should exist outside an active task at all. A programme can use JIT badly, but ZSP only works when JIT, approval, and time limits are consistent.

That distinction matters because JIT is a mechanism for reducing exposure, not a guarantee of least privilege. Privileged Access Management Guide treats JIT and ZSP as parts of the same control model, with session control and break-glass design around them. In mature environments, ZSP is the default state and JIT is the temporary exception path.

In other words, JIT can exist without ZSP if standing privilege still remains elsewhere, such as a permanently assigned admin role, a long-lived token, or an always-on emergency account. ZSP is the stronger statement: no persistent privilege unless there is a specific, justified reason for it to be present.

What changes in access design when you move from JIT to ZSP

ZSP changes how teams design roles, approvals, and recovery paths. Instead of granting broad standing rights and using JIT only for exceptional elevation, teams work backwards from the task and ask what minimal access is needed, for how long, and with what proof of need. That usually means narrower role definitions, shorter activation windows, and clearer ownership of privileged pathways.

It also changes how you think about least privilege techniques. ZSP is the policy posture that keeps privilege from accumulating, while JIT is one of the techniques that makes that posture enforceable in day-to-day operations. Without that combination, access reviews often become static paperwork instead of a live control.

The practical difference is visible in administration workflows. A JIT-only programme may still leave users with durable roles that are merely “inactive” most of the time. A ZSP programme tries to eliminate those durable entitlements and replace them with time-bound activation, session controls, and explicit exceptions that can be audited later.

Where the difference becomes material for people, machines, and agents

The gap between JIT and ZSP becomes more important when privileged access is used by cloud admins, service accounts, automation, or AI agents. In those cases, standing privilege tends to widen blast radius because the credential or role can be reused outside the intended task window. ZSP reduces that default exposure; JIT limits the time and scope of any necessary elevation.

That is why policy language in an Access control policy template should distinguish between standing privilege, approved elevation, and exception handling. If the policy only says “use JIT” but never defines what must be removed by default, the organisation often keeps persistent access in place and calls it temporary in name only.

For engineering and platform teams, the key design question is whether the control is truly removing standing access or simply hiding it behind a checkout step. If access can be activated instantly without meaningful approval, expiry, or logging, the environment may still be operating with standing privilege in practice, even if the workflow looks dynamic.

Risk and Threat Considerations

Persistent privilege expands the attacker’s opportunity window, especially when high-value roles, service accounts, or admin sessions are left dormant but ready to use. JIT reduces that window; ZSP reduces the number of windows that exist at all. The control gap matters most when credentials, sessions, or delegated rights can be abused quickly after compromise.

Failure mechanism: An organisation treats JIT as a substitute for ZSP, leaves permanent entitlements in place, and then assumes temporary activation has eliminated exposure. In reality, the attacker only needs one mis-scoped role, one long-lived credential, or one stale exception path to regain durable access.

Impact: Privilege creep, lateral movement, and harder incident containment follow when standing access remains available behind the scenes. Recovery also gets slower because teams must distinguish between legitimately activated access and access that should never have existed in the first place.

Practitioner Guidance

What to verify: Check whether your privileged roles are actually absent by default, or merely inactive until someone clicks to enable them. If a role, token, or account can still authenticate continuously, you have not reached ZSP even if the workflow uses time-boxed activation.

Decision rule: Use JIT for the temporary delivery of access, but treat ZSP as the governance standard that defines the acceptable end state. If the business insists on permanent privilege for convenience, make that an explicit exception with owner, expiry, and review cadence rather than a hidden default.

What good looks like: The normal state is no standing admin access, no permanently enabled elevation, and no unreviewed break-glass pathways. Access exists only when a task, approval, and expiry condition are all present, and the audit trail shows when privilege was created and removed.

Practitioner takeaway: JIT is the mechanism that makes privilege temporary, but ZSP is the policy discipline that makes temporary privilege the norm instead of the exception.

Related resources from NHI Mgmt Group

• Guide: Just-in-Time Access and Zero Standing Privilege Guide
• What is the difference between zero standing privilege and just-in-time access?
• How do access reviews support zero standing privilege and just-in-time access?
• What breaks when organisations treat time-boxed access as the same thing as zero standing privilege?
• When is zero standing privilege more useful than broader access models?