I IntelliAuth Docs

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

  • 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.

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

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

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

When MFA is required, the user's first sign-in after the policy turns on:

  1. Email + password (normal sign-in).

  2. "You need to set up multi-factor authentication" page.

  3. They pick a factor from the available list.

  4. They enrol — scan a QR for TOTP, register a passkey for WebAuthn, verify a phone number for SMS.

  5. They generate backup codes (one-time copy).

  6. They're in.

After enrolment, every subsequent sign-in:

  1. Email + password.

  2. MFA challenge — their already-enrolled factor.

  3. They're in.

The MFA challenge varies per factor — TOTP types a code; WebAuthn taps a sensor; SMS receives + types.

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.

Audit

Every MFA-related event lands in audit:

  • mfa.factor_enrolled / mfa.factor_removed

  • mfa.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).

See also