Deprecating SMS OTP in 2026: Why, When, and How

Key takeaways

• NIST SP 800-63-4 (2024) places SMS OTP outside AAL2, SIM-swap and AitM-proxy attacks defeat it in real time.
• SMS OTP remains acceptable in 2026 only as a fallback where the alternative is no MFA at all.
• The replacement order: passkeys first (AAL2 single-factor), TOTP second, push MFA with number matching third, email OTP for recovery.
• Migration is staged: enroll new factor, prove it works, retire SMS, never delete SMS without verifying replacement enrollment.
• Communication beats coercion. Two-week pre-announcement plus self-service swap converts at 60%+; surprise enforcement triggers ticket spikes.

What changed and why it matters

The deprecation isn't symbolic. Real production breaches in the 2023–2024 window cited SMS-OTP bypass as the vector, Storm-1242 and Caffeine-platform phishing campaigns harvested SMS codes against major SaaS targets in real time, and SIM-swap volumes against retail and crypto users grew through 2024.

What replaces SMS, in priority order

1. Passkeys (synced WebAuthn)

The strongest 2026 replacement. Phishing-resistant by construction (the credential is bound to the relying party origin). Synced across the user's devices through their cloud password manager. Clears AAL2 as a single factor, meaning users on passkeys often don't need a second factor at all.

The catch is enrollment friction. Users on devices without passkey support, or who haven't enrolled, need a fallback. For consumer apps with a broad userbase, passkey-first deployments still need TOTP or email-OTP as the fallback, not SMS.

2. TOTP (authenticator app)

The next strongest option for users who don't enroll passkeys. AAL2-compliant, immune to SIM swap, works offline. Phishable via AitM proxy but not at the SMS-level vulnerability.

TOTP is the natural deprecation step for security-aware userbases (B2B SaaS, developer tools, finance). For consumer apps with a wide tail of less-technical users, the enrollment friction (scan QR code, install app, transcribe codes) is real.

3. Push MFA with number matching

Vendor-specific (Microsoft Authenticator, Okta Verify, Duo). The user receives a push notification, sees a number on their phone, and types it back into the application. Number matching defeats the prompt-bombing attack class (where the attacker spams pushes hoping the user accepts).

Strong, but vendor-locked and adds operational dependency on the push provider's infrastructure.

4. Email OTP

Fallback only, bounded by the strength of the user's email account auth. AAL1 unless email has its own MFA. Acceptable for recovery and unsupported devices; not a replacement primary factor.

5. SMS OTP

Last-resort fallback only. Better than nothing for users who have no other option, but should not be the primary or sole second factor for any new deployment.

The migration playbook

The pattern that converts the install base without locking users out:

Phase 1, Announce (week 0–2)

Communicate the change. Email the affected users (those currently on SMS), explain what's changing and why, link to the self-service enrollment flow for the replacement factor. Two-week notice converts most security-aware users.

Phase 2, Self-service swap (week 2–6)

Offer the replacement factor as the suggested option at next login. Make enrollment one click, don't make users navigate three menus. For users who don't act, prompt at sensitive actions (password change, payment update).

Track enrollment rate per cohort. By week 6 most users have moved.

Phase 3, Forced step-up (week 6–10)

For the holdout long tail, require enrollment of a stronger factor at next login. Block the login flow until enrollment completes. Communicate clearly that SMS will be retired.

Phase 4, Retire (week 10+)

Disable SMS as a registration option for new accounts. For existing accounts that completed step-up, drop the SMS factor. Keep SMS available only as last-resort recovery for accounts that didn't enroll a replacement (with rate limiting and audit logging).

The critical rule: never delete SMS without verifying the replacement is operational. Users with stale TOTP enrollments (lost their phone, didn't re-enroll on new device) will be locked out if SMS is removed before the new factor is confirmed working.

The B2B SaaS variant

For B2B SaaS, the migration is per-customer-organization, not per-user. The customer's IT admin enables stronger MFA policy at the Org level, communicates internally, and retires SMS through their workforce IT cycle. The CIAM provides the policy controls and the audit trail; the customer drives the rollout.

Most B2B-mature CIAM (Auth0, WorkOS, Frontegg) ship per-Org MFA policy with enrollment tracking. Customers who enable "passkeys preferred, TOTP allowed, SMS disabled" can complete the migration in weeks.

What about the long tail of legacy phones?

Some user populations (regional consumer apps, financial services with older customers, healthcare with patient demographics that skew older) have meaningful percentages of users on phones without app-installation capability or without reliable internet access. For these segments, SMS may remain the most-accessible factor for years.

The 2026 best practice is segmented deprecation: deprecate SMS aggressively for new accounts and for security-aware segments; retain SMS as a fallback only for the long-tail demographic where the alternative is no MFA at all. Document the segments, audit the residual SMS usage, and revisit annually.

Vendor support snapshot

The CIAM with the strongest 2026 deprecation tooling (per-Org policy, per-user factor inventory, automated migration prompts):

• Auth0, Adaptive MFA tier surfaces enrollment status; Actions can drive the migration prompts.
• Descope, Flows handle the migration as a no-code orchestration; the cleanest UX in this category.
• Stytch, strong passkey orchestration plus per-user factor management.
• MojoAuth, competitive on per-Org policy plus migration prompts at lower price points.
• Corbado, passkey-specialist orchestration that can layer in front of an existing CIAM specifically for the migration phase.
• Authsignal, orchestration layer that handles the migration without replacing the primary CIAM.