Just-in-time access requests are the mechanism everyone agrees with in the abstract and quietly defeats in practice. The pitch is simple: nobody holds standing privilege, access is granted for a narrow window against a specific need, and it evaporates automatically when the window closes. The failure mode is also simple: if requesting access is slower or more annoying than the alternative, people will find the alternative. Shared credentials, a standing admin account someone forgot to revoke, a service token with permissions far broader than any single job requires. None of this is malice. It is friction routing around a policy that was never built to survive contact with an actual on-call shift.
The thing that makes an approval flow durable is not its strictness, it's whether it is still faster than the workaround at 2am. Picture a team that requires a manager's sign-off for every production database access request, with no exception for severity. During an incident, the engineer who needs read access to debug a live outage is stuck waiting on a Slack message to someone asleep. The policy is correct on paper and gets bypassed within a week, because someone will quietly keep a long-lived credential around specifically for this scenario. A just-in-time system that doesn't account for the incident path isn't a security control, it's a reason to build a shadow one.
The structure that tends to hold is a request that names the resource and the reason, an approval step scoped to the risk level rather than applied uniformly, a session that is time-boxed from the start rather than revoked after the fact, and automatic expiry that doesn't depend on anyone remembering to clean up. Low-risk, routine requests can be auto-approved or approved by policy rather than a human in the loop; the human approval budget should be spent on the requests that are actually unusual, not burned on every read-only query against a staging table. Treating every request as equally sensitive is how approval fatigue sets in, and approval fatigue is how people start rubber-stamping everything, which is functionally the same outcome as no approval at all.
This is also where the choice between a managed and an on-premise deployment matters less than people expect, and the design of the approval policy matters more. PAFTAK's PAM practice offers both managed Idira cloud deployments and on-premise implementation, but neither choice does the work of deciding which requests deserve friction and which don't — that's a policy decision, not an infrastructure one. The hard part is building the incident-path exception into the flow on day one, instead of discovering the gap during an actual outage.
A common failure mode worth naming directly: teams design the request and approval flow carefully, then leave the revocation side implicit, assuming the time-box will just work. Automatic expiry has to be the default behavior of the session itself, not a cleanup job that runs later and sometimes doesn't. A grant that technically expired but whose session token still works for another six hours is not time-boxed access, it's standing access with a reporting delay. The whole value of just-in-time is that the system, not a person's memory, is the thing enforcing the window.
None of this is really about access requests. It's about recognizing that every one of these flows is answering the same question in different language: who is this request really coming from, what do they actually need right now, and does the system notice when that need has passed. Whether the requester is a person, a service account, or increasingly an AI agent acting on someone's behalf, the discipline is identical. Access control was never a separate problem from building the software in the first place, it's the same problem wearing a different hat.