What is just-in-time privileged access?
Just-in-time (JIT) privileged access is a security model where admin permissions are granted for a specific, time-bounded task and automatically revoked, replacing always-on credentials with on-demand short-lived ones.
The model is also called just-in-time PAM, ephemeral access, or zero-standing-privilege. Gartner uses “Just-in-Time Privileged Access Management” in its market guides. NIST SP 800-207 (Zero Trust Architecture) describes the same idea in principle 4: access is granted on a per-session basis.
How it differs from a password vault
A password vault stores long-lived shared credentials and releases them on checkout. The credential outlives the session — it has to be rotated after use, and a captured vault password is exploitable until rotation completes. A JIT system never issues a long-lived credential in the first place; the credential is born short-lived, bound to an identity, and cryptographically self-revoking when its TTL expires.
For SSH specifically, this is the difference between vaulting an id_rsa private key and issuing a fresh SSH certificate per session. The certificate carries the engineer’s identity (signed by an SSH CA), an explicit valid-after / valid-before window, and a principal list naming exactly which user accounts on which hosts it can authenticate as.
Vendor comparison (fair view)
The market has three shapes. We list peers because calibration matters more than marketing — different fleets fit different tools.
| Vendor | Shape | Best fit |
|---|---|---|
| Linux Identity | SSH cert CA + sudo capability tokens, SaaS | Series-A/B Linux fleets, <200 engineers |
| Teleport | SSH + DB + K8s + apps unified proxy | Mid-market and enterprise, multi-protocol |
| StrongDM | Proxy-fronted credential broker | Database-heavy teams; non-Linux protocols |
| CyberArk JIT | Module bolted onto existing PAM vault | Enterprises already running CyberArk PAS |
| HashiCorp Boundary | Open-core access broker | Self-hosted Vault shops |
Where Linux Identity fits
We issue SSO-tied short-lived SSH certificates (default 4-hour TTL, tunable 1 minute to 24 hours) and capability tokens for sudo. Both are minted from a CA whose private key lives in a managed KMS. Every sudo invocation and shell session is captured to a hash-chained append-only audit log, so the JIT grant trail and the execution trail live in the same place.
More questions
- What does JIT privileged access replace?
- JIT replaces two older models: standing administrator accounts (where engineers hold root or sudo rights continuously) and vault-checkout workflows (where shared admin credentials are checked out from a password vault and rotated after use). Both leave a long window of standing privilege between the moment access is granted and the moment it is revoked or rotated.
- How does a JIT access request work end-to-end?
- Four steps. (1) Request: the engineer asks for a named capability — e.g. sudo on a host group, or shell on a production database. (2) Approval: a policy engine evaluates context (IdP group, time, on-call status) and either auto-grants or routes to a human approver. (3) Time-bound grant: a short-lived credential — typically an SSH certificate or a capability token — is minted with a TTL measured in minutes to hours. (4) Audit: the request, approval, grant, every action performed under the grant, and the eventual expiry are all written to an append-only log.
- Who sells JIT privileged access?
- Several categories. Modern access platforms (Teleport, StrongDM, Linux Identity) issue short-lived SSH or database credentials from a central CA. Legacy PAM vendors (CyberArk, BeyondTrust, Delinea) ship JIT modules layered on top of vault products. Cloud-native PAM (HashiCorp Boundary, AWS Systems Manager Session Manager) provide JIT for specific protocols. The right fit depends on fleet size, protocol mix, and whether you already run a vault.
- What are common JIT implementation pitfalls?
- Three recur. (1) TTLs set too short: a 5-minute cert that expires mid-incident is worse than a 4-hour one. Tune for the longest legitimate task, not the shortest. (2) Audit-log gap between grant and action: if the IdP logs the approval but the host doesn’t log the sudo invocation, you have a grant trail and no execution trail. Capture both. (3) Break-glass without JIT: keeping a standing emergency root account defeats the model. Break-glass should itself be JIT, with a higher-friction approval path.
- Is JIT privileged access required for SOC 2?
- The SOC 2 Common Criteria (CC6.1, CC6.2, CC6.3) require restricted, reviewed, and revocable access — not JIT specifically. Standing admin accounts can satisfy SOC 2 if access reviews, MFA, and offboarding are tight. But JIT makes the controls cheaper to evidence: the audit log is the access review, and revocation is automatic on TTL expiry.