What is the difference between JIT access and legacy PAM vaulting?

JIT access creates privilege only for the current task and removes it when the task ends. Legacy PAM vaulting may protect the secret value, but the target system can still carry persistent authorization, so the identity remains overprivileged after release.

What JIT access changes that vaulting does not

JIT access changes the authorization state itself. The user, admin, or workload gets privilege only for the approved task window, then the entitlement is removed or expires automatically. That means the control is aimed at the access path, not just at hiding the secret behind the access path.

Legacy PAM vaulting is different because it is mainly a secret-handling control. It can store, broker, or inject the password or key, but the underlying account may still exist with standing privilege after checkout. The secret is protected, yet the target system can remain permanently over-entitled.

That distinction matters because a vaulted secret and a truly time-bound entitlement do not create the same blast radius. If the account stays privileged after release, the environment still depends on later rotation, session controls, or manual cleanup to remove access. A JIT model bakes the removal into the workflow.

Why vaulting often feels safer than it is

Vaulting reduces exposure of the credential value, which is useful, but it can create a false sense of control if teams equate “secret checked out from a vault” with “privilege removed.” In practice, the access token, password, or injected session may be temporary while the account itself remains eligible to do far more than the task requires.

The main failure mode is that organisations optimise around secret custody instead of privilege lifecycle. That leaves standing authorization, dormant admin rights, shared accounts, or broad role memberships in place even when the vault successfully rotates or hides the secret. JIT closes that gap by tying approval to activation and expiry.

For a practical comparison of the two patterns, NHIMG’s PAM Buyer’s Guide and Just-in-Time Access and Zero Standing Privilege Guide separate vault-centred and JIT-centred operating models clearly.

What practitioners should check before calling either model “least privilege”

The question is not whether a vault exists, it is whether the protected actor can still act with standing privilege after the task ends. If the answer is yes, the control is incomplete for least-privilege purposes. If the account is re-approved and re-created per task, or its rights expire automatically, you are closer to JIT than to classic vaulting.

In mature environments, teams should verify three things: who gets the entitlement, how long it lives, and what remains on the target system after release. That includes checking whether an admin account, service account, or API credential can still authenticate, inherit roles, or reuse the same session outside the task window.

NHIMG’s Privileged Access Management Guide, Cloud PAM and CIEM Guide, and Service Account Security Guide are useful when you need to assess standing privilege across human and non-human access paths.

Risk and Threat Considerations

Vaulting without time-bounded authorization can leave a privileged identity available for misuse even when the secret is rotated or hidden. That creates a wider attack surface for privilege escalation, lateral movement, and account abuse, because an attacker who reaches the account or its session may still inherit durable rights after the supposed checkout window ends.

Failure mechanism: the control protects the secret value but does not fully remove the account’s effective permissions, so access can persist after the task is complete.

Impact: compromise or misuse can persist longer than expected, increasing the chance of unauthorized actions, delayed detection, and broader blast radius across systems that trust the same standing privilege.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	JIT and vaulting both affect whether users retain excess privilege after task completion.
	IA-5 — Authenticator Management	Vaulting and JIT both rely on secret lifecycle handling and controlled credential release.
	AC-2 — Account Management	The difference between temporary access and standing authorization is an account-management problem.
Recommendation — Enforce least privilege so privileged access exists only for the approved task window. Manage authenticator lifecycle so secrets are issued, rotated, and revoked on a controlled schedule. Provision, activate, and disable accounts so standing privilege is removed when no longer needed.
ISO/IEC 27001:2022	A.5.15 — Access control	JIT versus vaulting is fundamentally about how access is granted and removed.
	A.8.2 — Privileged access rights	The question hinges on whether privileged rights remain standing after secret checkout.
Recommendation — Define access rules that make privilege time-bound and task-specific. Review and restrict privileged rights so they do not persist beyond approved use.
CIS Controls v8	CIS-5 — Account Management	The topic is about controlling privileged accounts and reducing standing access.
Recommendation — Inventory and manage privileged accounts so excessive standing access is removed.
NIST CSF 2.0	PR.AA-05 — Managed Access and Privilege	JIT access is a direct example of managing privilege so it does not remain standing.
Recommendation — Implement managed access so elevated rights expire when the task ends.

Practitioner Guidance

What to verify: confirm whether checkout, approval, and session start are all tied to a real entitlement expiry, not just to password custody. If the vault can release a secret without removing the underlying privilege, treat the design as vaulting with temporary secret handling, not true JIT.

Common mistake: teams measure success by successful secret rotation or vault adoption and stop there. That is insufficient when the real risk is durable authorization on the target system, especially for admins, service accounts, and cross-environment roles.

Practitioner takeaway: the decisive control question is whether access disappears when the task ends, because hiding the secret is not the same as removing the power to use it.