Concept
What just-in-time access is
Abbreviated JIT access, and sometimes written just in time access or just-in-time privileged access.
Granting access on demand is the easy half and the half every product demonstrates. Taking it back reliably is the half that decides whether any of it worked.
Just-in-time access grants a permission at the moment it is needed, for a bounded period, and removes it automatically when that period ends. The opposite is standing access: a permission assigned once and held indefinitely, whether or not it is in use.
The three moving parts
Every implementation, whatever it is called, is some arrangement of the same three things:
- A request — someone says what they need and, ideally, why. The justification is worth capturing not for the approver, who usually knows already, but for the person reading the record eight months later.
- A decision — a human approval, or an automatic grant with a record. Both are legitimate. Requiring a human for everything produces approval fatigue, and an approver who clicks yes without reading is a worse control than an honest auto-grant, because it looks like oversight and is not.
- An expiry — chosen when the access starts, because that is the only moment anybody knows what the task is. "We will review it later" is not an expiry; it is a plan to have a meeting.
Why revocation is the hard half
Granting is synchronous, visible and immediately validated: the person either gets in or files a ticket saying they did not. Revocation is none of those. It happens later, unattended, when nobody is watching, and its failure mode is silence — access that should have gone away simply stays, and the only person who might notice is the one who benefits from it.
That asymmetry is why a system can look healthy for months while doing half its job. It produces three specific failures worth naming.
Revocation that can be blocked
If anything can stop the removal path — a quota, a license state, an unpaid invoice, a feature flag — then every temporary grant is one bad day away from becoming permanent. A gate on the removal path is far more dangerous than a gate on the grant path, because a blocked grant produces a complaint within minutes and a blocked removal produces nothing at all.
Revocation that is slow
Access that expires on paper at 17:00 and disappears from the target system at 17:40 was standing access for forty minutes. Where the grant is carried to its destination by a directory sync or provisioning cycle rather than a direct call, that lag is the real window, and it belongs in the risk assessment rather than in a footnote.
Revocation that is not recorded
"Who had access to what, and when did it stop?" is the question an auditor actually asks, and it needs both halves of the pair. A log of grants alone cannot answer it. If removals are not recorded with the same care as grants, you can prove you were careful about giving access and nothing whatsoever about taking it away.
Grant yourself something with a five-minute window. Wait ten. Then check the target system — not the access tool's own dashboard — and see whether the permission is gone. Then look for the removal in the audit record. Plenty of systems mark a grant "expired" internally while the permission is still live in the directory, and the internal status is the one you were shown.
When just-in-time access is the wrong tool
- Access somebody needs constantly. If a person elevates to the same thing eleven times a day, the elevation is theater and the friction is real. Give them the access, scope it properly, and review it — that is a least-privilege problem, not a timing one.
- An outage at three in the morning. Elevation paths must work when the systems they depend on do not, which is exactly when they are most likely to be broken. This is what break-glass accounts are for, and why they are exempt by design rather than by oversight.
- Automated workloads. A nightly job cannot request and wait. Service identities want scoped, rotated credentials and their own review cycle.
How TemprBac approaches it
TemprBac grants access as time-bound packages: a named bundle of groups across Entra ID, Okta, GitHub, Google Workspace, AWS IAM and Active Directory, requested, approved where the package requires it, and revoked automatically when the window closes. Groups and roles are the primitive because every system worth governing expresses access that way, which is what lets one package and one expiry span systems that share no directory.
Against the three failures above: a worker checks for expiry on a ten-second cycle and calls each system's own API directly rather than waiting on a sync; removals are recorded alongside grants, so the pair is one query; and nothing may block revocation — no plan limit, no quota, no billing state stops access from expiring. That last one is an invariant rather than a feature, because a cap that could stop revocation would convert every temporary grant into a permanent one. Pricing covers what the limits do affect.