The manager is asked before the access is granted

What actually happens

The approval step in most access request workflows is not a control. It is a signature collected from someone who has no way to evaluate what they are signing.

An access request arrives asking for elevated permissions on a production system. It routes to the requester line manager, who is the accountable person on paper.

The manager sees a role name, a justification field containing a sentence, and two buttons. They do not see whether this person has held this role before, what it grants, who else holds it, what the requester has done with elevated access previously, or what would be reachable if the credential were compromised.

Faced with that, the manager approves, because refusing would block a colleague from doing work they have described as necessary, and there is no evidence available to justify refusing.

The approval is recorded and satisfies the audit requirement. It has done almost nothing to reduce risk, because the person who signed it had no basis on which to decline.

Over time the pattern becomes explicit rather than implicit. Approvers learn that requests are routine, approval becomes reflexive, and the control degrades into a logging mechanism.

The manager approved because there was no evidence available on which to refuse. That is not a governance failure by the manager. It is a design failure in the request.

The same request, two ways

This clock is short in both columns. The comparison is about what the approver actually knew when they pressed the button.

There is no MTTR argument here at all, and it would be dishonest to construct one. The value is entirely in decision quality, and the honest measure of decision quality is how often an approver chooses something other than the default.

That is a metric you can track in your own estate today, and it is uncomfortable. Count the proportion of privilege requests approved unchanged. If it is close to all of them, the approval step is not functioning as a control regardless of what the audit record says.

The mechanism is attaching blast radius and history to the request rather than improving the workflow. A manager shown that a role reaches three sensitive systems the requester has never touched, alongside a narrower role that covers the stated justification, has something to decide.

The time limit is the quietly valuable part. Most elevated access is needed for a task rather than indefinitely, and a default expiry converts a permanent grant into a temporary one without anyone having to remember to revoke it.

Who decides to press go

This use case is entirely about the gate, so the gate is the product rather than a constraint on it.

Assembling the requester history, computing blast radius, identifying narrower alternative roles and proposing a time limit all run under policy. None of them grant anything.

Nothing is granted without the accountable manager approving a specific role and a specific duration, both recorded against the original justification.

Automatic removal at expiry is the one action taken without a fresh approval, because it was authorised by the approval that set the expiry in the first place.

Access request raised for elevated permissions outside the requester normal pattern. Routed to the accountable line manager.

Requester access history, prior use of this role, current holders, granted scope and recent related change records correlated. Blast radius computed.

Manager contacted with history, blast radius, a proposed time limit and a narrower alternative role. Nothing granted until a specific role and duration are approved.

Access removed automatically at expiry. Usage during the window recorded against the justification. Narrower role promoted as the default for comparable future requests.

This is a platform capability, not a published customer deployment. The mechanism, which is correlated investigation followed by out-of-band contact and governed action with approval gating, is running in production today; see governed day-2 operations across 2,000+ nodes and closed-loop network automation. The voice scenario above applies that same mechanism to an identity and access context. The timings shown are modelled, not measured.