MFA is the second proof of identity, on top of whatever the user signs in with (password, magic link, social, SAML). The MFA surface is where you configure:
- Which factors are available to users to enrol.
- Whether MFA is off / optional / required, and for whom.
- Adaptive step-up — situations where MFA is demanded mid-session.
- Custom factors — tenant-defined factors on top of the standard set.
Factors the platform ships with
Section titled “Factors the platform ships with”- WebAuthn / passkey — strongest. Phishing-resistant. Touch ID / Face ID / Windows Hello / hardware key.
- TOTP — six-digit codes from Google Authenticator, Authy, 1Password, etc.
- SMS — code sent by text. Weakest of the three; useful as fallback.
- Backup codes — pre-generated single-use codes; recovery path when the primary factor is lost.
Plus custom factors you define (see Custom factors).
You pick which factors are available to users in MFA → Settings → Allowed factors. Disable anything you don't want users enrolling.
Recommended posture
Section titled “Recommended posture”For most tenants:
- WebAuthn on. The future of MFA. Friction-free on devices with biometrics.
- TOTP on. Universal fallback; works on any device with an authenticator app.
- SMS on, as fallback only. Don't make it the recommended option. Users without compatible TOTP or WebAuthn devices.
- Backup codes on, mandatory. Generated at MFA enrolment; protects against device loss.
If your user base is technical (developers, internal staff), consider disabling SMS entirely — they all have WebAuthn-capable devices and authenticator apps.
Enforcement
Section titled “Enforcement”The off / optional / required dial is in MFA → Enforcement. See MFA enforcement for the full set of options.
Common patterns:
- Off — for prototypes / consumer apps where the friction is unacceptable.
- Optional — most users skip it; the security-conscious enrol. Common for B2C.
- Required — every user must enrol; no sign-in without MFA. Common for B2B, internal tools, anything sensitive.
Adaptive step-up
Section titled “Adaptive step-up”Even with MFA "optional" at policy level, you can demand MFA on specific events:
- User signs in from a new device or country.
- User performs a sensitive action (change email, delete account, large payout).
- The platform's risk engine scores the sign-in as suspicious.
See Adaptive step-up.
What users see
Section titled “What users see”When MFA is required, the user's first sign-in after the policy turns on:
- Email + password (normal sign-in).
- "You need to set up multi-factor authentication" page.
- They pick a factor from the available list.
- They enrol — scan a QR for TOTP, register a passkey for WebAuthn, verify a phone number for SMS.
- They generate backup codes (one-time copy).
- They're in.
After enrolment, every subsequent sign-in:
- Email + password.
- MFA challenge — their already-enrolled factor.
- They're in.
The MFA challenge varies per factor — TOTP types a code; WebAuthn taps a sensor; SMS receives + types.
The end-user factor picker
Section titled “The end-user factor picker”When a user has more than one enrolled factor, the sign-in page shows a factor picker so they can choose which to use. The picker shows a curated subset of what's technically available — not every factor type surfaces to end users:
| Factor | Shown to end users | Notes |
|---|---|---|
| Authenticator app (TOTP) | Yes | |
| Text message (SMS) | Yes | Only if the user's identity has a phone trait in the schema |
| Built-in biometrics (Touch ID / Face ID / Windows Hello) | Yes | |
| Email code | No | Email is the account-recovery channel; using it as MFA collapses to a single point of failure |
| Security key (FIDO2 hardware) | No | Admin-driven factor; end users see Built-in biometrics instead |
This list is fixed in the sign-in UI. Admins who want to restrict further — for example, allow TOTP only, no SMS — do so via MFA → Enforcement → Allowed factors.
SMS MFA and the phone-trait requirement
Section titled “SMS MFA and the phone-trait requirement”SMS as an MFA factor only appears in a user's picker if their identity has a phone number recorded. That phone number comes from the identity schema. If your schema does not include a phone trait, users cannot enrol SMS MFA, and it will not appear in the picker even if SMS is enabled globally.
To enable SMS MFA enrollment for your users, include a phone-type trait in your identity schema (add it under Users → Identity schema or when you set up SMS OTP as a primary sign-in method — the same trait serves both).
Custom factors
Section titled “Custom factors”You can define a tenant-specific factor on top of the standard set. Examples: an in-house hardware token, a SaaS integration that adds an additional step. See Custom factors.
This is an advanced surface; most tenants don't need it.
Every MFA-related event lands in audit:
mfa.factor_enrolled/mfa.factor_removedmfa.factor_admin_reset(when you force-reset a user's factors)user.mfa_succeeded/user.mfa_failed(on every challenge)mfa.backup_codes_regenerated
Audit is your MFA monitoring surface. Filter on user.mfa_failed and look for patterns (one user with many recent failures = factor lost; many users with recent failures = something's off with your tenant policy).