Re-authenticate for a sensitive action
Holding the right capability is not always enough. Twenty-four of the engine’s routes want a fresh proof that you are still at the keyboard before they will act, so a browser left signed in on an unattended machine cannot repoint your archives or sign everyone out. This is step-up re-authentication, ASVS V7.5.1 and V7.5.3.
You will meet it as a prompt to re-verify part-way through an action you have already started. That is the gate working, not a session that has expired.
What is gated
Where your data goes. Set, add, edit or remove an archive destination, and change which is the default.
Where your telemetry goes. Set or remove the SIEM push destination, send a test event to it, set or remove the OTLP metrics push.
Who can sign in. Add, remove, enable or disable an identity-provider connection; delete a passkey credential; register a new one.
Sessions. Terminate one user’s sessions, terminate everyone else’s, terminate all.
Keys and recovery. Install a key, add an operational key, regenerate recovery codes, email a custody share.
Restores and attestations. Approve a restore, create an attested verification session.
Posture. Record a posture acceptance.
The list is derived from the console’s own gated request wrapper, so it is the set that actually runs the ceremony rather than a policy statement about it.
Which sign-in methods are exempt, and why
A bare break-glass token is exempt. That token is all-or-nothing by design: anyone holding it already has every power the engine has, so demanding a second proof from it would add nothing while removing the one credential that works when everything else is broken.
Cloudflare Access is exempt. Access runs its own session lifetime and its own MFA, so the engine defers to it rather than layering a second, unrelated freshness rule on top and asking a user to satisfy both.
A first-party cookie session is not exempt, and that is the common case. The engine asks its scheduler whether that session was authenticated recently enough, or whether you have presented a valid single-use step-up token, which it then consumes so the same proof cannot be replayed.
What a 401 means here
On a gated route a 401 carrying stepUpRequired is the opening move, not a failure. The console catches it, runs the re-verification, and retries the original request. Nothing has gone wrong and you have not been signed out; a 401 on these routes is how the conversation starts.
That is worth knowing because it changes how you read your own audit and diagnostic records: a step-up 401 is not an authentication failure to investigate.
The gate fails closed, and what that looks like
If the engine cannot reach the component that answers the freshness question, the action is denied. Failing closed is the right choice for a control whose whole job is to stop an unattended session acting, but it produces a failure mode worth recognising.
If that component is up but broken, every gated action is refused with the same 401 stepUpRequired that a legitimate ceremony opens with. The symptom is “it keeps asking for my passkey and never accepts it”, on every sensitive action, for every user at once.
So the way to tell the two apart is the blast radius. One user, one action, and the prompt clears on a retry: that is the gate working. Every user, every gated action, and the prompt never clears: that is not your device or your passkey, and re-enrolling will not fix it. It is an engine-side fault, the engine records it as a distinct signal rather than as a run of authentication failures, and it belongs in a support bundle.
Where this fits
- Session management covers session lifetime, which is what step-up measures freshness against.
- Roles and capabilities covers the capability check, which runs independently: step-up never grants a permission you do not hold, it only asks you to prove you are present.
Last updated .