Skip to main content
Multi-factor authentication (MFA) requires users to complete more than one method of authentication before granting access to your application’s protected content. MFA in your application should prove ownership of multiple, distinct authentication factors, like a password (something you know) and a phone number (something you have). This section of our Docs will walk you through setting up MFA using a Consumer Stytch project. At a high level, you’ll need to complete the following steps in order to implement MFA:
  1. Prompt the user to authenticate their primary factor.
  2. Prompt the user to authenticate their secondary factor, leveraging the Stytch Session from Step 1 to create a new Session that contains both authentication factors.
  3. Enforce MFA by inspecting the authentication_factors array on the Stytch Session object in your application’s authorization logic.
For a step-by-step implementation walkthrough, check out the MFA guide for your integration type. Note that our pre-built frontend UI components do not currently support MFA.

​
MFA factor combinations

You can customize which primary and secondary authentication methods you’d like to offer your users:
ProductValid as primary factorValid as secondary factorRequirements
Crypto WalletsYesYes
Magic LinksYesYes
OAuthYesYes
OTP (Email, SMS, and WhatsApp)YesYes
PasswordsYesYesThe user’s email address must be verified before adding a secondary factor to a Stytch User with a password. Otherwise, a password reset will be required.
PasskeysYesYesThe user must already have another primary factor before registering a passkey. After a passkey is registered, it can be used as a primary or secondary factor.
TOTPNoYesCan only be used as a secondary factor.
WebAuthnYesYesThe user must already have another primary factor before creating a WebAuthn registration. After a WebAuthn registration is created, it can be used as a primary or secondary factor.
The primary and secondary factors that you choose should confirm your user’s identity in two different ways – for example, Email Magic Links and Email OTP are not a secure primary and secondary factor combination, because they both prove ownership of the same factor (an email address). Email Magic Links and TOTP are a secure combination, because they prove ownership of an email address and ownership of the TOTP authenticator app. If a user has multiple factors set up, our frontend SDKs will require a secure combination of factors to be authenticated before allowing the user to take sensitive actions, like adding or removing auth factors. For additional information about this, see here.

​
Step-up authentication vs. MFA at login

You can choose to require MFA every time a user logs into your application, or you can choose to only prompt users for MFA before they take sensitive actions, which is referred to as “step-up auth”. Step-up auth requires less user friction up front, though it does make your application’s authorization logic slightly more complex. The strategy you choose is up to you. Check out our Step-up versus multi-factor authentication blog post for additional information. Step-up authentication is straightforward to implement when using Stytch Sessions. See Step 4 in the Backend integrations or Headless frontend JavaScript SDK integrations MFA guides for implementation instructions.