MFA rollout: do's and don'ts
Updated 2026-05-06
MFA is the single highest-leverage CIAM control. Microsoft's published data (Microsoft Security Intelligence, 2023), 99.9% of compromised accounts lacked MFA, is the most-cited statistic in the field for a reason: nothing else available in 2026 provides a comparable order-of-magnitude reduction in account compromise. The challenge is not whether to deploy MFA but how to roll it out without breaking adoption, support load, or recovery flows.
The do's and don'ts below distill the patterns separating MFA rollouts that achieve 70%+ adoption from those that plateau at 20%. See the MFA pillar guide for context, the passkeys guide for factor selection, and the account takeover defense guide for how MFA composes with other ATO controls.
Do
Default new accounts to MFA-enrolled at registration
Friction is lowest at signup. Users are already in security-decision mode and have not yet attached emotional weight to the account, so enrolling at registration captures the majority of adoption.
Microsoft data shows 99.9% of compromised accounts lacked MFA. Retroactive email-driven enrollment campaigns plateau at single-digit conversion; signup-time enrollment converts above 70% in well-designed flows.
Use adaptive decisioning to challenge only on risky signal
Always-on MFA at every login is a tax users pay every session and drives complaint volume to support. Adaptive MFA evaluates device, geo, velocity, and time signals; challenges only when the score warrants it.
Auth0, Descope, and Beyond Identity all publish customer data showing 3–5x higher MFA acceptance when paired with adaptive decisioning vs always-on prompts.
Enroll multiple recovery factors at signup
The most common ATO bypass class observed in production is recovery flows that quietly skip MFA. If only one recovery factor is enrolled and the user loses it, the support process becomes the bypass.
Best practice in NIST SP 800-63-4 and OWASP Authentication Cheat Sheet: enroll at least two recovery factors (alternate verified email plus TOTP, or alternate email plus printed backup codes) and require at least one for recovery.
Step up MFA at sensitive actions, not only at login
Login is one moment; account changes (email, recovery factors, payment methods, transfers) are another. Step-up at sensitive actions catches stolen-session attacks that pass login MFA.
OWASP recommends step-up authentication for any operation that materially changes account security or financial state. Production deployments at fintech show meaningful ATO reduction from step-up at transfer-and-change-of-recovery operations.
Don't
Don't rely on SMS OTP as the primary second factor
SIM-swap and adversary-in-the-middle proxy attacks defeat SMS OTP in real time. NIST SP 800-63-4 considers SMS OTP inadequate for AAL2.
Documented production AitM-proxy phishing campaigns (Storm-1242, Caffeine) bypass SMS and TOTP at scale. SMS remains acceptable only as a fallback where the alternative is no MFA at all.
Don't reset MFA without re-verifying it during recovery
The classic bypass class. User clicks forgot password, verifies email (often the only factor shown), sets new password, logs in fully authenticated, bypassing MFA entirely.
Recovery flow audits at multiple production CIAM deployments find this pattern routinely. Fix: recovery requires presenting at least one enrolled recovery factor and sets up new factors, never bypasses.
Don't allow support reps to disable MFA without policy
An unmonitored support-bypass path is a bypass attackers will reach for via social engineering. Document the policy, rate limit the path, audit every event, notify the user out-of-band when MFA is reset.
Multiple high-profile ATO incidents in 2023–2024 traced to social-engineered support resets. Major CIAM vendors now publish customer guidance specifying support-reset rate limits and audit requirements.
Don't force MFA enrollment retroactively without communication
Surprise enforcement triggers high support volume and user-trust damage even when the security gain is real. Communicate two weeks in advance, offer self-service enrollment first, then enforce.
Customer experience research from major CIAM customers consistently shows two weeks of pre-announcement plus self-service period reduces support tickets by 60%+ vs surprise enforcement.