What is just-in-time (JIT) access?
By Identra · Updated
Just-in-time (JIT) access is a security model that grants an identity the privileges it needs only at the moment of a task, then revokes them when the task ends. It replaces standing privileges with short-lived, scoped grants, shrinking the window in which a stolen credential or compromised account can be abused.
Key numbers
- Machine identities outnumber human identities 82 to 1 in organizations (CyberArk Identity Security Landscape, 2025)
- Workload identities use less than 5% of the permissions they are granted (Microsoft State of Cloud Permissions Risks Report, 2023)
- 80% of workload identities are inactive, double the share seen in 2021 (Microsoft State of Cloud Permissions Risks Report, 2023)
How does just-in-time access work?
JIT access flips the default from always-on to off-until-needed. Instead of holding a privileged role permanently, an identity starts with little or no privilege and requests elevation when a specific task requires it. A policy engine evaluates the request against context such as who or what is asking, the target resource, the time, and the justification. If the request passes, the system issues a grant that is scoped to the task and set to expire on its own.
The defining property is that revocation is automatic. Nobody has to remember to remove the access, because the grant carries its own expiration. When the timer runs out, the identity returns to its zero-privilege baseline.
- Request: an identity asks for a specific privilege on a specific resource, often with a stated reason
- Evaluation: policy checks the requester, target, timing, and approval requirements
- Grant: the system issues a short-lived credential, token, or role assignment scoped to the task
- Expiry: access is revoked automatically when the time window or task completes
JIT access vs standing privilege
Standing privilege is access that persists whether or not anyone is using it. It is the natural end state of convenience: roles get granted for one project and never removed, service accounts keep admin rights because nobody is sure what would break, and API keys live for years. The numbers show how far this drifts from real need. Microsoft's 2023 State of Cloud Permissions Risks Report found that workload identities use less than 5% of the permissions they are granted, and that 80% of workload identities are entirely inactive.
Every unused permission is pure downside. It does no work for the business, but an attacker who compromises the identity inherits all of it. JIT access attacks this asymmetry directly by making privilege exist only while it is being used.
| Dimension | Standing privilege | JIT access |
|---|---|---|
| Duration | Persistent until someone removes it | Minutes to hours, expires automatically |
| Blast radius of a stolen credential | Everything the identity can ever touch | Only what is granted in the active window |
| Revocation | Manual, often forgotten | Automatic at expiry |
| Audit story | Who could have done what, always | Who had what, when, and why |
| Operational cost | Low upfront, high accumulated risk | Requires request and approval workflows |
JIT for humans vs non-human identities
For human users, JIT is a mature pattern. An engineer requests elevation to debug production, a manager or an automated policy approves it, and the role expires in an hour. The human tolerates a small amount of friction, and approval can route to another human when the request is unusual.
Non-human identities are a harder fit, and there are far more of them. CyberArk's 2025 Identity Security Landscape found machine identities outnumber humans 82 to 1. Service accounts, CI/CD pipelines, and workloads cannot click an approval button or explain a justification in a text box. JIT for NHIs instead means replacing static secrets with short-lived credentials issued at runtime: cloud IAM roles assumed for minutes, certificates with hours-long lifetimes, and tokens minted per job by a secrets or workload identity platform.
AI agents push this further. An agent may decide mid-task that it needs a new capability, which makes pre-approved static entitlements both too broad and too slow. Per-task, per-tool grants that expire with the task are the closest fit, but they demand policy engines fast enough to sit inside an agent's execution loop.
What JIT access does not cover
JIT is a decision made at the moment of grant. Once the grant is issued, the model has said everything it has to say. Whatever happens inside the approved window, whether it is the intended database migration or a mass export of customer records, looks identical to the JIT system, because the JIT system only saw the request.
This is the live-session gap. A one-hour grant is a real improvement over a permanent one, but one hour is an eternity for an automated attacker or a misbehaving AI agent operating at machine speed. Token theft makes the gap concrete: if an attacker steals the short-lived credential after issuance, JIT has already done its job and nothing in the model notices the session behaving strangely.
Closing that gap requires runtime controls that observe and constrain what an identity actually does after access is granted: monitoring the session, comparing behavior to the stated task, and cutting access mid-window when the two diverge. JIT narrows the door. Something else has to watch what walks through it.
How to adopt JIT access
Most organizations phase JIT in rather than flipping a switch, starting where standing privilege is most dangerous.
- Inventory standing privileges for both humans and NHIs, and measure which grants are actually used
- Start with the highest-risk tier: domain admins, cloud root and owner roles, and production database access
- Replace static NHI secrets with short-lived credentials issued by cloud IAM, workload identity, or a secrets platform
- Set expiration as the default on every new grant, so privilege decays instead of accumulating
- Pair JIT with session-level monitoring, since the grant decision cannot see what happens after issuance
How Identra thinks about it
JIT access, from where we sit, is necessary and unfinished. It shrinks the window in which privilege exists, which matters enormously when machine identities outnumber people 82 to 1 and most granted permissions sit unused. But the window it leaves open, the live session, is exactly where modern incidents unfold, and NHIs and AI agents move through that window at machine speed. That is why Identra focuses on runtime identity security: verifying and constraining what an identity actually does after the grant, so a just-in-time credential cannot quietly become a just-long-enough breach.
Go deeper: The Non-Human Majority
Frequently asked questions
What is an example of just-in-time access?
An engineer needs to debug a production database. Instead of holding standing admin rights, they request elevation for that task, a policy or manager approves it, and the system grants a scoped role that expires in one hour. When the timer runs out, access revokes itself. The same pattern applies to a CI job assuming a cloud role for minutes.
What is the difference between just-in-time access and just-in-time provisioning?
Just-in-time provisioning creates an account automatically the first time a user signs in through SSO, solving an onboarding problem. Just-in-time access grants temporary elevated privileges for a specific task and revokes them afterward, solving a standing-privilege problem. The names are similar, but one is about account creation and the other is about how long privilege exists.
Does just-in-time access replace PAM?
No, it is a capability modern privileged access management platforms deliver. Traditional PAM vaults shared admin credentials and brokers sessions; JIT changes the model so privilege does not exist between uses. Most organizations run both: a vault for break-glass and legacy accounts, and JIT elevation for day-to-day admin work, moving toward zero standing privileges over time.
What are the challenges of implementing JIT access?
Grant latency is the biggest: if elevation takes minutes, on-call engineers demand standing fast paths that undo the model. Legacy systems that only accept static credentials need brokers. Non-human identities cannot fill out request forms, so they need policy-driven issuance instead of approval workflows. And JIT stops at the grant, so session monitoring is still required afterward.