Step-up authentication: asking again only when it matters

Most people sign in once in the morning and work all day. That is good for productivity and bad for risk, because a session that was proven eight hours ago says little about who is at the keyboard now.

Step-up authentication is the compromise: stay signed in for ordinary work, but when someone attempts something sensitive, ask for fresh proof first.

The glossary has the short definition. The rest of this article is about doing it well.

What problem it solves

Several threats share one shape: an attacker or an unintended person is operating inside a valid session.

• A laptop left unlocked in a meeting room.
• A stolen session cookie or token.
• Malware acting in the user's browser.
• A well-meaning colleague "helping" at someone's desk.

Strong sign-in does not help here, because the sign-in already happened. Step-up puts a second checkpoint in front of the actions where a mistake or abuse would hurt most.

Which actions deserve a re-prompt

Be selective. If everything asks again, people learn to click through. A useful test: would you want to be able to say later "we confirmed this was really that person at that moment"?

Typical candidates:

• Changing authentication settings: adding or removing a passkey, resetting MFA, changing a recovery email or phone number.
• Granting or removing administrator roles.
• Creating or revoking API keys and signing keys.
• Changing single sign-on configuration, such as certificates, redirect URLs and connectors.
• Exporting bulk personal data, such as the full employee list or audit logs.
• Disabling or deleting accounts in bulk.
• Changing log retention or log-streaming destinations. An attacker who wants to hide will go here.
• Finance and HR actions such as changing payout bank details.

And typical non-candidates: reading a dashboard, opening an ordinary application, updating a profile photo.

How fresh is fresh enough

Step-up needs a freshness window: how recently the person must have authenticated for the action to proceed. Options:

Short windows balance well. A person making six related changes in the admin console should not face six prompts, but should face one if they step away and return after lunch.

Record in your design what the window is and where it is enforced, and make the check on the server side. A client that merely hides a button is not enforcing anything.

OpenID Connect gives vocabulary for this. A relying party can request a maximum authentication age (max_age), and the ID token carries auth_time, the moment of actual authentication.

Authentication context and method references (acr and amr, with values defined in RFC 8176) can tell the application which kind of proof was used.

Applications that implement their own step-up on top of OIDC can check these claims rather than trust a flag in their own session. See Implementing OIDC with PKCE for the surrounding flow.

Which factor to ask for

The stronger the action, the stronger and more phishing-resistant the factor should be.

• A passkey or security key is the best choice for step-up, because the user gesture is simple (touch, face or fingerprint) and a phishing page cannot relay it. See Passkeys explained.
• An authenticator-app code works but can be relayed by a real-time phishing page.
• An SMS code is the weakest of these; read Why SMS one-time codes are not enough.
• Re-entering a password alone proves little, since it is the same factor that may already have leaked.

Whatever you choose, step-up must not be satisfied by the session itself. A step-up prompt that accepts "you are already signed in" is no prompt.

Designing the experience

Done badly, step-up is the most hated part of an admin console. Some principles:

1. Explain why. "Confirm it is you before changing sign-in methods" is better than a bare login box.
2. Return the person to what they were doing. Preserve the form and the intended action; do not drop them at the home page.
3. Do not time out in the middle of a prompt. Allow a reasonable period to find the security key.
4. Offer the strongest method first and weaker ones only if policy allows.
5. Fail clearly. If the step-up fails, say that the action was not performed.
6. Keep a safe path for emergencies. Decide in advance what happens when no one with an admin role can complete a step-up, such as every key being lost. A documented, audited break-glass process is better than disabling the control.

Logging and monitoring

A step-up is only valuable if you can see it. Log, at least:

• The user, the action requested and the target object.
• Whether step-up was required, and its result (success, failure, abandoned).
• The factor used and the time of authentication.
• Source IP address and user agent.

Then use the data. Alert on repeated step-up failures for an account, step-up success followed immediately by privilege changes, and step-ups from unusual locations or at unusual hours.

Send these events to your monitoring system; Streaming identity logs to your SIEM covers how.

Where AuthMantra fits

AuthMantra applies step-up re-authentication to sensitive admin actions, and records the events in the audit log, which can be exported, followed as a live feed, or streamed to a SIEM.

It does not currently provide a general conditional-access or risk-scoring engine, so for application-level decisions you would still rely on the controls of each application.

What to do this week

1. Write your list of "sensitive actions" for each major system, no more than ten per system.
2. For each, note the current protection: nothing, a confirmation dialog, or real re-authentication.
3. Choose a freshness window and write it down.
4. Make sure at least administrators have a phishing-resistant factor registered, so step-up is not forced down to a weaker method.
5. Test the emergency path with two people, and record the result.
6. Add an alert for repeated step-up failures.