When the first factor succeeds and the account still needs a second, the flow reads the supported second factors and picks in a fixed order of preference — authenticator app, texted code, backup code — then renders that step. Copy for the authenticator step is supplied explicitly at the provider level so the screen isn't a bare code box.
Also called: 2FA · MFA · authenticator app · backup code · second factor
- 1After a successful first factor, a 'needs second factor' status moves the flow to the second step.
- 2The strategy is chosen in order: authenticator app, then texted code, then backup code, then whatever is first.
- 3A texted second factor triggers a send before the input is shown.
- 4The code is verified against the chosen strategy and the session is finalised on success.
- 5If no strategy can be driven, the flow hands off to the provider's own component.
Two-factor is where a custom sign-in screen usually goes wrong, so the fallbacks are explicit. The remembered-method write happens before this step deliberately — 'The factor worked. Remember it even if MFA is still to come.' And because the custom card hides the provider's own step header, the root layout re-supplies the missing context in provider localisation: 'on the 2-factor step [hiding the header] removes the enter your code context. Re-supply clear copy… so the screen is self-explanatory instead of bare code boxes.'
- A custom sign-in screen that can't complete two-factor locks out the accounts that most need protecting.
- A bare code box with no label is indistinguishable from a bug.
- A lost phone needs a backup path.
See it on your own jobs
Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.
or keep browsing features →