Just-in-Time Access Explained: How to Eliminate Standing Privileges in Your Enterprise
Most enterprise security incidents that involve privileged access share a common root cause: the compromised account had access it did not need, to systems it had not touched in weeks, with credentials that had been valid for months. The attacker did not escalate privileges — the privileges were already there, standing, waiting. This is the standing privilege problem, and it is the specific gap that just-in-time access is designed to close.
What Just-in-Time Access Is — and How It Differs from Traditional PAM
Traditional PAM operates on a vault-and-checkout model. Privileged credentials are stored in a vault. When a sysadmin needs access, they check out credentials, connect to the target system, and check the credentials back in when done. This is better than shared spreadsheets and sticky notes, but it still has a fundamental structural problem: the privileged account itself exists permanently on the target system. The Administrator account on the Windows server, the root account on the Linux host, the sa account on the database — these accounts are always present, always enabled, always a target.
Just-in-time (JIT) access takes a different approach: eliminate the standing account entirely, or at minimum ensure the account is disabled and credentials are rotated immediately before and after each use. Access is provisioned on demand for a specific user, a specific target, and a specific time window. When the window expires, access is automatically revoked — not checked back in, but removed.
The zero standing privileges (ZSP) principle extends this further: no privileged account should have persistent access to any production system. Every privileged session is a temporary grant with a defined start, a defined end, and a complete audit trail. When no session is active, no privileged access exists.
The practical difference between traditional PAM and JIT/ZSP:
- Traditional PAM: The
Domain Adminsgroup has 15 members. Credentials are vaulted. Members check out credentials when needed. The accounts exist 24/7 on every domain-joined server. - JIT PAM: No standing
Domain Adminsmembership. When a sysadmin needs elevated access, they submit a request scoped to a specific server and a specific duration. The system provisions the access, creates the session, records it, and revokes it at the end of the time window.
The attack surface in the traditional model is every moment the account exists, against every system it can reach. The attack surface in the JIT model is the duration of the approved session, against the specific approved target.
Before JIT vs After JIT — A Concrete Scenario
Before JIT: A senior sysadmin at a 500-person company has been on the team for four years. They are a permanent member of the Domain Admins group and have standing RDP admin access to approximately 200 servers — development, staging, and production. They use this access actively for maybe 20 servers on a regular basis. The other 180 are infrastructure they set up during migrations and have not touched since. Their credentials are in the corporate SSO, their account has never been reviewed for scope reduction, and their access has not changed since they joined.
When their laptop is phished in a targeted attack, the attacker has immediate, persistent, unchallenged access to all 200 servers. The blast radius is the entire infrastructure.
After JIT: The same sysadmin has no standing privileged access. When they need to perform maintenance on a specific production server, they submit a request: "I need RDP admin access to prod-db-03 for 4 hours to apply the quarterly patch." The request is reviewed by their manager and a security team member via a Slack approval workflow. Once approved, the system provisions a time-bounded credential scoped to that specific server. The session is automatically recorded from start to finish. At the end of 4 hours, access is revoked and the credential is rotated.
When their laptop is phished, the attacker has access to whatever active sessions exist at that moment. If no session is currently approved and active, the attacker has no privileged access to any production system. The blast radius is bounded by what was approved and active at the moment of compromise — not the entire infrastructure footprint of the sysadmin's career.
JIT Access and Compliance — How ZSP Maps to NIS2, SOC 2, and ISO 27001
JIT access and zero standing privileges are not just good security practice — they are increasingly explicit requirements in the compliance frameworks that CEE and European enterprises must satisfy.
NIS2 Article 21 — Least Privilege: NIS2 requires that essential entities implement access control based on least privilege principles. "Least privilege" in the NIS2 context means access should be granted only to the extent necessary to perform a specific task. Standing admin access to 200 servers fails this test by definition — the sysadmin who uses 20 of those servers regularly has standing access to 180 they do not need. JIT access enforces least privilege structurally: access is always scoped to the specific system and time window of the actual need.
SOC 2 CC6.3 — Access Revocation: The SOC 2 Trust Services Criteria require that access is removed promptly when it is no longer required. CC6.3 specifically covers access revocation for terminated employees, role changes, and project endings. JIT access satisfies CC6.3 automatically: access expires at the end of the approved time window without any manual revocation step. The auditor's question — "how do you ensure access is removed when it is no longer needed?" — has a deterministic answer: "It expires automatically; here is the audit log of every session expiry."
ISO 27001 Annex A.9.2 — Access Provisioning: ISO 27001 A.9.2.2 requires a formal access provisioning process, and A.9.2.3 requires that privileged access rights be allocated on a need-to-use basis. "Need-to-use" is the ISO 27001 language for least privilege, and it maps directly to JIT: access should exist when needed and not exist when not needed. A.9.2.5 requires periodic review of user access rights — with JIT access, the review is continuous rather than periodic, because access is re-granted from zero for each session.
The compliance argument for JIT is straightforward: standing privileges are structurally non-compliant with the least-privilege principle that NIS2, SOC 2 CC6.3, and ISO 27001 A.9.2 all require. JIT is the implementation pattern that makes least privilege operationally viable at scale.
How VaultPAM Implements JIT Access
VaultPAM implements JIT access through four integrated mechanisms:
Approval workflows: When a user requests privileged access to a target system, VaultPAM routes the request to the appropriate approver — manager, security team, or both, depending on the access level and system sensitivity. Approvals can be completed via the VaultPAM web interface or integrated notification channels. The request includes the target system, requested duration, and justification, giving the approver the context to make an informed decision.
Time-bounded sessions: Every approved access grant includes a hard expiry time. The session window is set at approval time — 1 hour, 4 hours, 8 hours, or a custom duration up to the policy maximum. When the session window expires, VaultPAM revokes access automatically. There is no manual step, no reminder email, no dependency on the user logging out. The access simply stops existing.
Auto-expiry and credential rotation: For RDP and SSH sessions, VaultPAM provisions a session-specific credential at the start of the approved window and rotates it at expiry. The credential that existed for the approved session no longer works after expiry. An attacker who captures the credential mid-session cannot reuse it after the window closes.
Audit trail: Every JIT request — submission, approval or denial, session start, session duration, session recording, and expiry — is recorded in VaultPAM's immutable audit log. The audit trail includes the approver identity, the approval timestamp, the justification text, and a complete recording of the session activity. This is the evidence package that satisfies NIS2 audit requests, SOC 2 auditor sampling, and ISO 27001 spot-check reviews.
See VaultPAM JIT access in action — eliminate standing privileges in your environment