step_up_required
Why an account action asks you to confirm it is you again, which methods can answer, and what to do when none is offered.
On this page
Symptom#
An action in your account does not go through, and you see Confirm it is you to continue. or a prompt titled Confirm it is you that says This needs a fresh confirmation. with Use a passkey and Authenticator app code. A request to the account API returns status 401 with the code step_up_required.
Related answers are insufficient_assurance (Confirm it is you with a stronger sign-in method to continue.), and device_too_new (This browser is new to your account. You can make this change from it 24 hours after you confirm it by signing in with a link or code emailed to you, or from a browser you already use.).
Why it happens#
A session is a bearer credential: whoever holds it can act as you while it lives. Actions that would turn a short theft into lasting access ask you to prove you are there right now, with a second factor.
These actions need a fresh confirmation:
- Adding, renaming or removing a passkey.
- Setting or changing a password.
- Turning on or removing an authenticator app, and creating new recovery codes.
- Changing your primary email address.
- Requesting or downloading a data export.
- Closing your account.
- Creating or revoking a personal access token.
- Marking a device as trusted.
- Linking or unlinking an external provider.
The rule is the same for all of them: your session must be at assurance level 2 or above, and the passkey, authenticator code or provider sign-in that justifies it must be no more than 30 minutes old (the platform can shorten that limit with its authn.reauth_max_age_s setting, never lengthen it). A password alone is level 1. A password with an authenticator code, or a passkey, is level 2. See Assurance and method values.
Viewing sessions, activity and connected apps does not need it.
Which methods can answer#
The answer lists the methods you can use. It offers only what your account and your session can actually do.
| Method | Offered when |
|---|---|
| Passkey | The account has at least one passkey. |
| Authenticator code | An authenticator app is set up and the session began with a password. |
| External provider | You linked a provider that the platform trusts for multi-factor sign-in. |
| Account password | The account has a password and the session began with a passkey or a provider sign-in that used multi-factor. It appears under Other ways to confirm as Account password. It is never offered on a session that began with a password, an emailed link or a recovery code. |
A recovery code is not enough on its own to regenerate recovery codes or to remove the authenticator app; a live authenticator code is needed.
Likely causes#
- The confirmation is older than 30 minutes. Confirm again.
- You signed in with a password only and have no second factor. The session is level 1, and there is nothing to step up with.
- You signed in with "Continue with my password only (limited session)" and the account has a passkey or an authenticator app. The session is level 1; answering the prompt with the passkey or the app lifts the limit and makes the browser known.
- You signed in with an emailed link or an external provider and want to use an authenticator code. The authenticator code is offered only on a session that began with a password. Sign in with the password, or use a passkey.
- Your passkey was not accepted. The page says The passkey was not accepted. Try again or use another method.
- You tried too many times. The prompt then says Too many attempts. Try again in a wait such as 45 seconds, 57 minutes or 2 hours.
- A new browser.
device_too_newis not a step-up: it is a wait. Do the change from a browser the account already knows, or sign in here once with an emailed link or code and wait 24 hours (the platform can lengthen that wait, never shorten it). A password alone does not make a browser known. An account that holds a passkey or an authenticator app is not made to wait: it is asked to confirm it is you instead. - Your session is tied to your organization's single sign-on connection. A session pinned to a connection needs a local confirmation (a passkey, or an authenticator code) before these actions, even if the sign-in through the organization was recent. Where the organization requires single sign-on, an application may also get
insufficient_user_authenticationfrom the token endpoint instead (see invalid_grant). Both apply only where the platform has turned ontenant_connectionsorsso_enforcement(both default OFF). - A managed account. An account an organization manages has no passkeys, password or authenticator of its own, so credential changes and personal access tokens answer 403
managed_account: this account is managed by an organization: its credentials, tokens and lifecycle belong to that organization, shown on the page as Your organization manages this account, so this is not available here. Ask your organization’s administrator. A step-up that a managed account has nothing to answer (an account that only signs in through its organization) gets the same 403 instead of a prompt it could never satisfy. - The emailed code that replaced a lost passkey. That session has used no second factor, so every step-up asks for a passkey or an authenticator code; the code does not count.
What to check#
- Read the methods the prompt offers.
- Check the Security area: does the account have a passkey or an authenticator app?
- Check how you signed in. See the Sign-in method column on Devices.
- Check that your device clock is right if an authenticator code fails. See Clock skew.
Fix#
- In the prompt, choose Use a passkey and approve it on your device, or type the Authenticator app code, or (where offered) open Other ways to confirm, type the Account password and select Confirm with password. Then continue the action.
- With no second factor, add one first from Security. Where that is not possible from this session, recover the account, which has no hold when nothing is set up: see If a sign-in needs a second factor you do not have.
- If you lost the authenticator app, sign in with Use a recovery code where your organization allows it, then set the app up again.
- For an application using the account API with a token: the 401 carries a challenge naming the level and the freshness asked for. Step the session up, or send the person back through sign-in with
acr_valuesset toaal2and amax_age, then repeat the request. A browser caller can answer themethodslisted in the response with the step-up routes of the Account API at a glance.