How do I add multi-factor authentication to a consumer app?

Adding multi-factor authentication (MFA) to a consumer app is mostly about balancing security, usability, and recovery. A good MFA setup usually starts with a simple baseline and then expands to support more methods and risk-based prompts.

1) Decide when MFA is required

Common patterns:

• Optional at signup: let users enable it after creating an account.
• Required after login on sensitive actions: money movement, changing email/password, exporting data.
• Forced enrollment for high-risk accounts: admins, large balances, or suspicious activity.
• Step-up authentication: prompt for MFA only when risk is higher.

For consumer apps, step-up MFA is often the best UX.

2) Choose MFA factors

Prefer factors in this order:

Better options

• Passkeys / WebAuthn: strongest and most user-friendly if supported.
• Authenticator apps (TOTP like Google Authenticator, 1Password, Authy): common and offline.
• Push notifications: easy UX, but needs anti-push-fatigue protections.

Weaker options

• SMS codes: better than nothing, but vulnerable to SIM swap and interception. Use only as fallback.
• Email codes: convenient, but usually weaker because email is often the recovery target.

A common consumer app strategy:

• Primary: password + passkey or authenticator app
• Backup: recovery codes
• Optional fallback: SMS/email only for account recovery, not as the main MFA method

3) Design the login flow

A typical flow:

1. User enters username/password.
2. If MFA is enabled, issue a short-lived “MFA pending” session.
3. Prompt for the second factor.
4. Verify the second factor.
5. Create the authenticated session only after success.

Important:

• Don’t issue full session tokens until MFA is complete.
• Make MFA challenges short-lived.
• Rate-limit attempts.

4) Support enrollment and recovery

You need good recovery, or users will get locked out.

During enrollment

• Show a QR code for TOTP.
• Ask the user to confirm by entering a code.
• Provide recovery codes to download/store securely.
• Encourage adding a second factor if possible.

Recovery options

• Backup/recovery codes
• Verified email or phone re-enrollment flow
• Support-assisted recovery with strong identity checks for high-value accounts

Be careful: recovery is often the weakest link. Don’t make it easier than the login itself.

5) Implement securely

Key security practices:

• Store only what you need.
  • For TOTP, store the shared secret encrypted at rest.
  • For WebAuthn/passkeys, store public keys and credential metadata.
• Use constant-time comparisons for codes where applicable.
• Allow only a small number of attempts.
• Enforce short expiration for codes/challenges.
• Log suspicious MFA events.
• Protect against replay attacks.

6) Handle usability

Good MFA UX matters a lot in consumer apps:

• Remember trusted devices for a limited time, if risk-appropriate.
• Make the prompt clear and fast.
• Offer backup methods if the preferred factor fails.
• Avoid asking for MFA repeatedly in the same session unless risk changes.
• Give users visible account security settings.

7) Prefer passkeys if you can

If you’re building a modern consumer app, consider supporting passkeys:

• Users authenticate with device biometrics or device PIN.
• No password to phish.
• Great UX on mobile and desktop.
• Can coexist with password login during migration.

A strong design is:

• Passkey as primary sign-in
• Password as fallback
• MFA for recovery or step-up actions

8) Choose an implementation approach

You can:

• Use an identity provider/auth platform: Auth0, Cognito, Clerk, Firebase Auth, Okta, etc.
• Build it yourself if you need full control.

Using a provider is usually faster and safer unless you have special requirements.

9) Minimum recommended setup

If you want a practical default for a consumer app:

• Password login
• TOTP authenticator app support
• Recovery codes
• Optional SMS only for recovery
• Step-up MFA for sensitive actions
• Passkeys as a future upgrade path

10) Test edge cases

Make sure you test:

• Lost phone / new device
• Expired codes
• Time drift for TOTP
• Re-enrollment after recovery
• Multiple devices
• Stolen session after MFA
• Account takeover attempts
• Users without smartphones

If you want, I can also give you:

1. a recommended MFA architecture,
2. a step-by-step implementation checklist, or
3. sample flows for web + mobile apps.