Just-in-time privilege: the approval that takes four seconds and grants four hours
Zero standing privilege was the right architectural move. It replaced permanent entitlements with time-boxed grants, and it relocated the control to an approval step that approves almost everything in under five seconds.
What does a four-second approval actually authorise?
Four hours of unrestricted privilege, usually. Just-in-time elevation presents an approver with a request and a reason, and they approve in seconds because the reason is plausible and the requester is a colleague. The grant that follows covers the entire role, not the stated purpose.
- JIT approval is optimised for speed because slow approvals block work. Notifications render minimal context, and approval rates near 100% make the control decorative.
- Approval rate alone is a weak signal — most requests are legitimate. Pair it with latency and context sufficiency.
- Render binding keeps the speed engineers need while making the approval a signed act over what was actually granted.
Part of Access governance and certification
The base rate that makes this hard to reason about
Start with the honest complication. The overwhelming majority of privilege elevation requests are legitimate. An engineer needs production access to diagnose an incident; that is the job.
So a high approval rate is expected and is not, on its own, evidence of a problem. This is where naive metrics go wrong: an organisation with a 99% approval rate may have excellent judgement applied to a population that is 99% legitimate.
What distinguishes the two cases is not the rate. It is whether the approver had enough information to distinguish, and whether the record shows what they had.
Three metrics, used together
| Metric | What it measures | What it cannot show alone |
|---|---|---|
| Approval rate | Share of requests approved | Whether approval was considered |
| Approval latency | Median seconds from request to decision | Whether the decision needed longer |
| Context sufficiency | Whether the approver was shown scope, duration and justification | Whether they read it |
Together they are informative. An approval rate of 99%, a median latency of 3 seconds, and a notification rendering only a role name is a control that is not operating. The same rate with a 40-second median and full context is a control operating on a legitimate population.
What a push notification actually renders
Typical JIT approval notification content, on a phone lock screen:
[Platform]
Access request: prod-db-admin
Requested by: j.okoro
[Approve] [Deny]Absent: what prod-db-admin permits, how long the grant lasts, what the justification says, whether this requester has held it before, and what else they currently hold.
An approver acting on that notification is not making an uninformed decision through carelessness. They are making the only decision the interface permits.
What render binding adds
Put the material facts in the signed statement, and therefore in the notification.
{
"type": "manav-stmt/1",
"action": "privilege_elevation_approval",
"render": [
"Requester: [name, team]",
"Role: [name] — [what it permits, business language]",
"Systems: [in scope]",
"Duration: [hours] Expires: [time]",
"Justification: [text as written]",
"Prior grants (30d): [count]"
],
"approver": "[credential assertion]"
}The prior-grants line is the cheapest high-value addition. An approver seeing that this is the requester's eleventh elevation this month makes a different decision than one seeing no history, and the data already exists.
The latency budget
There is a real tension and it should not be papered over. Slow approvals during an incident cost real minutes at the worst possible time.
The resolution is to separate incident and routine paths. Incident elevation runs under a pre-authorised standing delegation with a short expiry and automatic notification to the approver — approval after the fact, recorded. Routine elevation goes through the approval path with full context.
That way the control never stands between an engineer and a production outage, and the routine path — which is the bulk of volume — gets the attention it should have.
What to measure first
- Median approval latency, by approver. Approvers with sub-two-second medians are responding reflexively, and that is a workload signal rather than a character judgement.
- Approval rate by requester, looking for requesters whose elevation frequency is an outlier for their role.
- Context rendered: audit what your notification actually displays. Most teams have never looked at it on a phone.
- Share of elevations used. A grant approved and never exercised is a request that did not need approving, and it is pure noise in the approver's queue.
That last metric is frequently the biggest win available. Reducing unnecessary requests improves approval quality more than any interface change, because it restores the approver's attention budget.
A quality framework for elevation approvals
| Dimension | Poor | Good |
|---|---|---|
| Information | Name and free-text reason | Operations the role permits, recent use, peer baseline |
| Specificity | Whole role | The operations the stated purpose needs |
| Duration | Default window | The shortest window that works |
| Evidence | A workflow record | A signature over what was granted |
Objections and honest limits
“Approvers know their teams.” Which is why they approve quickly, and why the control adds little. Familiarity is what makes the approval fast and what makes it uninformative.
“Narrowing the role is a large project.” It is. The cheaper intermediate step is to gate the small number of destructive operations inside the role, which leaves the role as it is and removes most of the exposure.
Improving elevation approvals
- Show the approver what the role permits. Not the role name.
- Show recent elevation history for the requester. Frequency is context.
- Default to the shortest workable duration. Not the maximum.
- Gate destructive operations inside the window. Which removes most exposure without redesigning roles.
Terms used here
- Just-in-time elevation
- Granting privilege temporarily on request rather than holding it permanently.
- Standing privilege
- Permanently held elevated access — the problem JIT was designed to remove.
- Purpose binding
- Tying a grant to the stated reason, which no common implementation does.
Frequently asked questions
Is a high approval rate a problem? Not on its own. Most requests are legitimate. It becomes a signal when paired with very low latency and minimal rendered context.
Will this slow down incident response? Not if incident elevation runs under a pre-authorised standing delegation with after-the-fact notification. The approval path applies to routine requests.
Does this replace PAM? No. It changes what the approval step produces — a signed act over rendered scope rather than a tap on a role name.
What is the single cheapest improvement? Add prior-grant count to the notification. The data exists, it changes decisions, and it requires no new infrastructure.
Why do approvers approve so fast? Because the requester is a known colleague and the reason is plausible. Familiarity makes the approval quick and uninformative.
What should the approver be shown? What the role actually permits, the requester's recent elevation history, and a peer baseline — not a role name.
What is the cheap intermediate step? Gating the handful of destructive operations inside the window, rather than redesigning roles.
Where this fits in Manav
Manav turns an access or elevation decision into an artefact: what the approver was shown, who they were, what authority they held, signed and verifiable without your systems.
Sources and further reading
- FTC — business guidance on marketplaces and consumer protection
- Published research on approval and multi-factor fatigue in security workflows.
- Incident analyses involving misuse of legitimately elevated privileges.
- Zero standing privilege architectural guidance.
- AWS — temporary security credentials
- NIST SP 800-53 Rev. 5 — access enforcement