Step-up authentication during a session

A session that was good enough to browse is not always good enough to change a password, add a passkey, or approve a risky action. Signing the user out just to raise assurance is worse: you lose in-progress work and teach people to skip the sensitive path. Sensitive actions can now require a fresh, elevated authentication check during an existing session.

This is the longer note behind the July 18 changelog entry.

How it works

Step-up is an elevation challenge. The user is already signed in. Authdog re-verifies identity with a supported method, then continues the same session instead of tearing it down and starting over.

Session readiness checks keep elevation state consistent across requests. A client that asks "is this session ready for the sensitive action?" sees the same answer the hosted flow just wrote, rather than a stale cookie that still looks signed-in but never completed the challenge.

Elevation works across the authentication methods the environment already supports, so a user who signed in with one method can still complete step-up with a method that environment has enabled. Hosted Account Portal screens present MFA and step-up challenges when a user or policy requires them.

This is not console Elevate (just-in-time role grants for team members). Elevate lives under its own module and emits ELEVATE_ACCESS_* events. Step-up here is about the end-user session's assurance, not a temporary environment role.

Custom JWT mappings still apply on MFA elevation and token refresh, the same as on sign-in.

Set it up

1. Enable the authentication and MFA methods you want available for re-verification in that environment.
2. Use the hosted Account Portal (or your existing hosted challenge screens) so pending elevation state stays in Authdog-managed cookies.
3. Gate the sensitive action on session readiness after the challenge succeeds — not on "a session cookie exists."
4. Confirm the same path on each method you offer (password, OTP, TOTP, passkey) in a non-production environment.

Do not call hosted MFA verify routes as a public API. They depend on Authdog-managed pending state.

Trust boundaries

A completed step-up proves a fresh challenge succeeded for this session. It does not extend token lifetime by itself, and it does not replace backend session validation. Continue verifying the Authdog session on every protected request.

Elevation state is environment-scoped. A missing, expired, or wrong-environment pending state sends the user back to a full sign-in rather than silently succeeding.

Do not treat "user has a cookie" as "user just re-authenticated." Check readiness for the sensitive action. Step-up is also not phishing-resistant unless the method you required is (for example a passkey). TOTP can be relayed.

Try it

Sign in on a development Account Portal, trigger a sensitive action that requires step-up, and confirm the session continues after the challenge. MFA background is in MFA. The original release note is in the changelog.