Just-in-time access, with an expiry that actually fires
Standing access is the permission nobody remembers granting and nobody thinks to remove. The fix is not another quarterly review. It is access that arrives when it is asked for and leaves on its own.
The risk that never reaches the risk register
Access accumulates quietly. Somebody needed production for one incident in March, got it, and still has it. Nobody did anything wrong, and there is no event to detect: the grant was legitimate on the day it was made and simply never ended. By the time anyone counts, the number of people who can reach production is a number nobody would have approved if asked for it directly.
Quarterly access reviews are the usual answer and they mostly measure how tired the reviewer was. A list of two hundred grants gets approved wholesale, because the reviewer has no way to tell which of them are still needed.
How a request works
Ask, with a reason and a clock
The engineer picks what they need, in which mode, for how long, and says why. Duration is bounded between sixty seconds and twenty-four hours. The bound is the point: a grant measured in weeks is standing access that has learned to fill in a form.
Somebody decides, and the decision is kept
An approver holding the manage access permission accepts or refuses. The request, the reason, the decision and who made it all go into the audit log. That is the difference between a policy saying approval is required and evidence that approval happened, and it is the difference an auditor is testing for.
It ends by itself
A time-boxed grant is created, and when it runs out a background sweeper revokes it and drops any live session still running on it. This is the part that is usually missing: expiry that politely waits for the session to close is not expiry. Nobody has to remember anything, which is the only revocation mechanism that works reliably.
Doing it without making everyone miserable
Just-in-time access fails when it is applied to everything. Read access to a staging cluster should not require a form at two in the morning. The split that survives is standing access for the routine and requested access for what would appear in an incident report: production write, database read-write, anything a contractor touches.
It also wants approvers who are actually around. An approval queue with one name on it is a single point of failure that engineers will route around by asking for longer grants.
What it leaves behind
A record of every request, its reason, its decision and its expiry, next to the sessions that ran under it. That answers the access review by itself, which is usually the second reason people turn this on and eventually the first. What an auditor asks for.
Questions people ask before they try it
- What happens when a grant expires?
- A background sweeper revokes it and drops any session still running on it. Expiry that leaves an open session alive is not expiry, it is a note in a calendar.
- How long can a request be for?
- Between sixty seconds and twenty-four hours. The ceiling is deliberate: a grant measured in weeks is standing access with extra paperwork.
- Who can approve?
- Anyone holding the manage access permission. The request, the decision and the approver's identity all land in the audit log, so the approval is an artefact rather than a memory.
- Does this slow engineers down?
- It adds an approval to access somebody does not have yet. The work is in choosing what stays standing: everyday read access usually should, and production write access usually should not. Getting that split right is what makes it survive contact with an on-call rotation.
- Which edition includes it?
- Pro and above. Community has the audit log and the brokering, not the approval workflow. See the editions table.