Just-in-time (JIT) access means a person, service or AI agent receives a permission only when they need it, for a defined task and a limited time, and the permission is removed automatically afterwards. It is the opposite of a standing privilege, which is access that is granted once and stays in place whether or not anyone is using it. The practical difference is how long an attacker (or a mistake) can use the access: with standing privileges the window is open all the time, and with JIT it is open only for the duration of the grant.
This post explains the idea, compares JIT with standing privileges, describes what a request looks like end to end, and then shows how a small team can start with the identity provider it already has, without buying a privileged access management (PAM) suite. One disambiguation first: JIT access is not the same as just-in-time provisioning, which creates a user account at first login. Here the subject is how long a permission lasts, not when an account is created.
What is just-in-time access?
JIT access grants a specific permission for a specific purpose and period. An engineer who needs to read a production database to fix an incident asks for that access, gets it for an hour, and loses it when the hour ends, instead of holding database permissions every day of the year.
The idea follows from the least-privilege principle, which NIST describes in control AC-6 of SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations: give each user only the access needed for their task. JIT adds time to that principle, so access is limited by when as well as by what.
What is the difference between standing privileged access and JIT access?
Standing privileged access is always on. The administrator account, the production database role or the cloud owner permission exists permanently and is usable by anyone who holds the credentials, including an attacker who steals them. JIT access exists only inside a grant window, so a stolen credential outside that window cannot use the privilege directly, although an attacker could try to request it, which is why approval and step-up MFA on the request matter.
| Standing privileges | Just-in-time access | |
|---|---|---|
| When the access exists | Always | Only during an approved window |
| Exposure if a credential leaks | The whole time the account lives | Smaller: the privilege is only usable during a grant, and requesting one needs approval |
| Evidence of why access was used | Often none | A request with a reason and an approver |
| Cleanup | Manual, usually at a periodic review | Automatic at expiry |
| Main risk | Forgotten, overbroad access | Friction and approval fatigue |
What types of JIT access are there?
- Temporary elevation. A user keeps their normal account and receives an extra role for a limited time.
- Ephemeral accounts. A short-lived account or credential is created for the task and deleted afterwards.
- Brokered or approval-based access. A request goes to an approver or is checked against a policy, and a broker issues the temporary grant.
What does a JIT request look like?
Most JIT systems follow the same loop: someone makes a request with a reason, a person or a policy approves it, the system issues a time-bound grant, the grant expires on its own, and everything is written to an audit log. The reason and the log are what turn it into evidence for a customer security review or an auditor, and they connect to user access reviews, which are the periodic check that no grants slipped through.
Why does JIT matter for AI agents and service accounts?
Software that acts on someone’s behalf has traditionally used long-lived keys, which are standing privileges with no session expiry. The same direction applies on any platform: short-lived, task-scoped tokens in place of permanent secrets. Our post on non-human identity and AI agents with Keycloak goes into the details.
What is zero standing privilege?
Zero standing privilege is the goal of having no permanent elevated access at all, so every powerful permission exists only during an approved grant. JIT access is the main technique for reaching it, and in practice most teams get close rather than exactly to zero, because break-glass accounts have to stay available.
Where does JIT fit between PAM, IAM and IGA?
Privileged access management (PAM) is the category that traditionally delivers JIT for administrator accounts, together with credential vaulting and session recording. Identity and access management (IAM) is the layer that signs people in and decides what they can do, and identity governance and administration (IGA) records who should have access and proves it was removed. JIT cuts across all three. Our posts on IAM vs PAM and IAM vs IGA show where the lines fall.
How do you start without a PAM suite?
For a team of 20 to 200 people, four habits are a practical start:
- Short token lifetimes. Keep access tokens short-lived and rely on refresh for convenience, so a stolen token is useful only briefly. The OAuth working group’s security guidance in RFC 9700, Best Current Practice for OAuth 2.0 Security (January 2025), which recommends sender-constraining and audience-restricting access tokens and protecting refresh tokens, is the reference for token handling.
- Step-up authentication for admin actions. Ask for a stronger factor just before a sensitive action, instead of trusting the session from the morning. See our step-up authentication guide and the explainer on conditional access.
- Temporary group or role membership with an expiry. Make admin roles something people are added to for a period, not a permanent label.
- Access reviews. Run a regular access review to catch grants that should have expired, and see automated access request and approval workflows for the approval side.
How do you do this with Keycloak?
Keycloak, the open-source identity server behind Skycloak, covers most of the pieces above, with the approval step as the exception noted below. Access token lifespan is configurable per realm and per client, step-up authentication works through ACR values and conditional flows, and admin events, once enabled, record who changed what. For time-bound roles, the workflows feature, fully supported from Keycloak 26.6, can grant a role or group and remove it again after a delay, as our post on Keycloak workflows describes.
There is one caveat to plan for. Scheduled workflow steps are run by a background task that checks for due steps at an interval (12 hours by default, per the workflows engine docs), so a grant may outlive its nominal expiry until the next check. Shorten the step-runner interval if you rely on this for tight windows. Until the revoke step runs, refreshed tokens still carry the role, and a short access token lifetime only limits how long an already-issued token keeps the role after the revoke. Workflows also have no approval step, so the request and approval part needs something on the Admin REST API, as in our guide to access request and approval workflows, which includes a time-bound access section. Keycloak is also not a PAM vault: it does not store shared passwords or record sessions, so if you need those, you need a separate tool. You can see how it fits into workforce IAM, with role-based access control and audit logs as the building blocks.
What are the common JIT mistakes?
- Grants that never expire. A “temporary” role with no expiry behaves exactly like a standing privilege, so every grant needs an end time.
- Approval fatigue. If approvers click through every request, the approval adds delay without adding safety. Pre-approve low-risk requests by policy and reserve human approval for the sensitive ones.
- Break-glass accounts treated like normal admin accounts. Emergency accounts are meant to be permanent, so protect them separately, as in what a break-glass account is, and monitor every use.
- No audit trail. Without a recorded reason and approver, you cannot show a reviewer why access was granted, which removes most of the audit value.
FAQ
What does JIT access stand for?
JIT stands for just-in-time. In this context it means access is granted at the time of need and removed afterwards, which is separate from just-in-time account provisioning at first login.
Is just-in-time access the same as zero standing privilege?
They are closely related. Zero standing privilege is the goal, meaning no one holds permanent elevated access, and JIT is the main technique used to reach it.
Do I need a PAM product to use JIT access?
No. A PAM product is the most complete option, especially when you need credential vaulting and session recording, but short tokens, step-up authentication, expiring role membership and regular reviews on your identity provider give a small team a useful first version.
Can JIT access slow people down?
It can if every request needs a human approver. Automating approval for low-risk access and making requests quick (a chat command or a short form) keeps the delay small.
How long should a JIT grant last?
It should last as long as the task needs and then end. For an incident fix that might be an hour or two, and the right default is whatever your team can justify in the request reason.
What to do next
Pick the three most powerful permissions in your environment (production data, cloud owner, identity administrator) and ask who holds each one today and why. Convert the first one to a time-bound grant with a recorded reason, watch how it works for a month, and then repeat for the next.