Just-in-time access is the idea that a permission should exist for the minutes it is being used and not for the years in between. Someone who needs admin on a system asks for it, gets it for a bounded window, does the work, and loses it again without anyone having to remember. It is the opposite of the way most access is granted, which is once, for convenience, and for good.
standing admin
|===========================================================================|
granted once still there
just-in-time admin
request approve |======| request approve |===|
"ticket 4821, granted auto-revoked "on-call, auto-revoked
four hours" at 4h this shift" at shift endHow does JIT access work?
Four steps, and the fourth is the one that matters.
1Request
A person asks for a specific permission, states why and for how long, and names the ticket or task if there is one. The request is made where the person already works, usually in chat, and the form is short enough to be filled in under a minute.
2Decide
A policy or an approver decides. Low-risk roles that fall within policy auto-approve in seconds and are logged. Privileged roles route to a resource owner or an on-call lead and are decided in minutes. The tier of risk, the approver and the default duration are all set in advance, so nobody designs each grant.
3Grant
The permission is granted, in the identity provider where the role is a group and directly in the application where it is not, and a timer starts. The timer is the part that has to live outside the application. Almost no SaaS role carries an expiry field of its own. Whatever granted the role therefore holds the end time, and a grant whose expiry lives only in a calendar reminder is standing access with a note attached to it.
4Revoke
When the window closes the same system removes the permission, whether or not the person has finished, remembered or replied. The request, the approval, the grant and the revocation are each recorded. A quarter of JIT activity therefore reads to an auditor as a log of justified, time-bounded access, rather than as a list of people who happen to be administrators.
The same idea applied to credentials rather than roles is what makes rotation stop being a project. A commenter in a thread on service accounts described the shape:
Totally, but my service accounts own the api keys. But keys are still annoying to rotate. You know what's not annoying to rotate? Short-lived tokens with very limited scope that get assigned more on demand
Why does standing access matter so much?
Because it is where the risk sits while nobody is looking. Standing access is any permission that stays granted between uses, and in a typical SaaS stack that is nearly all of it.
| Standing access | JIT access |
|---|---|
| Granted once, kept until someone removes it | Granted per window, removed by the system |
| Available to whoever holds the credential, at all times, including an attacker who has phished it | Available only during the window, to the person who requested it |
| Has to be found and justified at every access review | Justified at request time; the review sees the log |
| Accumulates faster than reviews remove it | Cannot accumulate, because nothing stands |
| Twelve workspace owners in the design tool, nine billing admins, the engineers who kept production access after the incident | Two on-call leads and a break-glass account, in writing |
Least privilege is a rate, not a state
Least privilege is usually described as a state to reach. In practice it is a rate of decay, since access accumulates faster than reviews remove it. JIT is the mechanism that stops the accumulation at the source, by never letting a privilege stand in the first place. NIST SP 800-207 states the same idea as a tenet of zero trust architecture. Access to an individual resource is granted on a per-session basis, with the least privilege needed to complete the task.
What a standing role costs at every review
Each standing grant is a row somebody has to justify again on a schedule. Fourteen holders of a payments admin role are fourteen rows a quarter and fifty-six rows a year. Every one of those rows needs a reviewer who knows what the role permits. The same access run through JIT produces a log of requests with reasons and expiries attached, which is read once rather than re-litigated four times a year. The reviewer's question also changes shape, from whether this person should be an administrator to whether the four hours in March were justified. The second question answers itself from the record.
Why the window shrinks the blast radius
A standing admin role is available to whoever holds the credential at any hour, including an attacker who phished it at two in the morning. A four-hour window used once a month exposes that role for roughly half a percent of the hours in the month. The privilege is not documented differently, it is absent for the rest of the time. A stolen session then lands on an account that cannot reach the payments console at all.
Where does JIT apply outside servers and databases?
The pattern grew up in privileged access management, where vaults broker temporary sessions to servers, and most of the published guidance still assumes that setting. An administrator described the vault version in a thread on managing shared credentials:
With Vault/OpenBAO, for many services, it can handle password rotation and can even generate accounts(with appropriate permissions) for you, so you need access to Y service, Vault will create a temporary account. When the token expires, it will delete the account automatically.
The mid-market case
The mid-market case is different from that, and larger.
| Target | Why it accumulates | JIT default |
|---|---|---|
| SaaS admin roles | Every application has one and hands it out freely | Four hours, approved by the application owner, or self-approved within policy for low-risk tools |
| Contractor accounts | Granted for a project with no end date | Access expires on the contract end date without anyone remembering |
| Finance approvals and exports | Given to whoever asked during a close | A window per close, logged |
| Customer data access | Needed for one support case | Per case, with the case number on the request |
| The identity provider's own admin console | The most privileged role in the company, held by whoever set it up | Standing for two named people; JIT for everyone else |
Why the expiry has to live outside the application
The difference from the server case is that most SaaS applications have no notion of a time-limited role, so the expiry cannot be configured inside the application. A vault brokering a database session owns both ends of that session and can tear it down on its own. A workspace admin toggle is a boolean with nothing attached to it. The expiry therefore has to be enforced by whatever granted the role. That system records the end time and takes the role back when it arrives. Two failure modes follow from that split, and both are quiet ones. A revocation job that errors on a single application leaves the role standing while the record says the window closed. The granting system therefore has to verify each removal rather than assume it. A role granted by hand outside the flow has no end time recorded anywhere. That is how a JIT program ends up holding standing access it does not know about.
How is JIT access designed for a small team?
Start with a count of what stands today, then set defaults so that nobody has to design each grant.
1Count what stands today
Count the standing admins per application and the contractors without an end date. Those two numbers are the baseline and the thing to report on. Both of them should fall and then stay flat. The count has to come from each application's own list rather than from the identity provider, since an admin toggle set inside a product never appears in the directory.
2Set a duration per tier of risk
Four hours suits a SaaS admin role, a shift suits on-call production access, and a contractor's window is the contract end date. Durations agreed in advance are what keep each request from becoming a negotiation. A duration that people routinely find too short gets raised once at the tier, rather than extended one grant at a time.
3Set an approver per tier
The application owner approves privileged roles, an on-call lead approves production access, and low-risk roles self-approve within policy and are logged. Those routing rules are also what an auditor samples against, so the tier definitions belong in the access control policy rather than in one tool's configuration.
4Write down what is allowed to stand
A small set of standing roles is justified in writing: the two on-call leads, the break-glass account and the identity provider's recovery admin. A break-glass account with no standing privilege is not break-glass, which is why the exception list is part of the design rather than evidence against it.
5Treat every other privileged grant as temporary
Everything outside that written list defaults to a window, including the grants nobody expected to be temporary. The default matters more than the policy text, because the grants that accumulate are the ones nobody thought about in advance.
Iden's self-service access runs the request in Slack. The person picks the role, the duration is set by the policy for that tier of risk, the approver is routed automatically or the grant self-approves within policy, and the role is removed when the window closes, in the application itself, over its API or admin console where the role is not a SCIM group. The request, approval, grant and revocation are the audit record. The feature behind it is Access that expires without anybody remembering.
The request, where the work already happens. Duration and IAM groups come from the template; the only thing typed is the reason.
How does JIT change with and without SCIM?
Where admin is a SCIM group
SCIM can grant and remove group membership on a schedule the identity provider controls. For applications where admin is a SCIM-synced group, a JIT window is a group change with a timer on it. RFC 7644 defines the PATCH operation that adds and removes a member of a group. Each end of the window therefore costs one protocol call. This is the clean case, and it covers the applications that were already the easiest to govern.
Where admin is a setting in the application
Most SaaS admin roles are not SCIM-synced groups. They are settings inside the application's own console, and the majority of applications gate SCIM behind an enterprise plan or never built it. For those, JIT needs a path into the application itself, over its API or through automation of the admin console. Otherwise the window closes on paper and the role stays, which is the same failure as an access review whose rejections are never enforced. The check is worth running once per application. Grant a role through the flow, wait for the window to close, then read the account list from inside the application. Reading the record of the revocation instead proves only that a revocation was attempted.