TOTP vs SMS OTP: And Why One Is Being Deprecated

Key takeaways

• TOTP generates codes locally on the user's device from a shared secret. SMS OTP delivers codes via a carrier-controlled SMS channel.
• SMS OTP is vulnerable to SIM-swap and SS7 interception; TOTP requires the attacker to extract the seed from the user's device.
• NIST SP 800-63B-4 (2024) removed SMS OTP from the AAL2-acceptable authenticator set. TOTP remains AAL2-acceptable.
• The migration target in 2026 is passkeys; TOTP is the AAL2-compatible fallback when passkeys aren't available; SMS OTP is the legacy mechanism being phased out.

Same UX, different security

How each actually works:

TOTP (RFC 6238) — at enrollment, the server generates a shared secret and shows it to the user as a QR code. The user's authenticator app (Google Authenticator, Authy, 1Password, Bitwarden) scans the QR code and stores the secret. At authentication, the app computes a six-digit code by HMAC-SHA1 of the secret and the current 30-second time window. The server computes the same code with its copy of the secret and compares. No network communication during authentication; the device and server stay in sync via the clock.

SMS OTP — at authentication, the server generates a random six-digit code, looks up the user's phone number, and sends the code via SMS through the carrier network. The user reads the code from their phone and types it into the login form. The server compares against the code it sent. The security depends on the SMS being delivered to the user's device and only the user's device.

The architectural difference: TOTP keeps the secret on the user's device; SMS OTP relies on the telephony network as a trusted channel. Telephony network trust is the broken assumption.

The attacks that drove the SMS deprecation

SIM-swap. The attacker calls the victim's mobile carrier, impersonates the victim, and convinces customer service to port the phone number to a SIM the attacker controls. From that point, all SMS to the victim's number goes to the attacker — including OTP codes. The attack has been demonstrated repeatedly against high-value accounts (cryptocurrency exchanges, executive social media accounts, journalists). Carrier countermeasures (PIN locks, port-out delays) exist but are inconsistently enforced.

SS7 interception. Signaling System 7 is the global protocol carriers use to route SMS and voice between networks. Documented vulnerabilities allow attackers with SS7 access (which is more widespread than carriers acknowledge) to redirect or intercept SMS without any visible effect on the victim's phone. The victim sees no incoming SMS; the attacker reads it on a parallel network.

SIM cloning and physical interception. Less common but possible. A SIM card can be cloned with physical access; SMS can be intercepted by IMSI-catchers operating in proximity to the victim.

The TOTP attack surface is materially narrower. The attacker needs to compromise the user's device to extract the seed (requires malware, typically), shoulder-surf the QR code at enrollment (rare), or phish the current code at use time (defeated by domain-bound credentials like passkeys). None of these scale the way SIM-swap and SS7 attacks scale.

NIST SP 800-63B-4 and the AAL implications

The 2024 NIST update made the security difference explicit in the regulatory baseline. AAL2 authenticators must demonstrate resistance to specific attack classes; SMS OTP no longer meets the bar.

The implications cascade:

• HIPAA: OCR enforcement increasingly cites missing MFA as a contributing factor; AAL2 is the practical bar for clinical access. SMS OTP-based 2FA is technically present but doesn't satisfy the assurance level expected.
• PCI DSS 4.0: requires MFA for CDE access; SMS is technically a factor but the standard's MFA guidance leans toward phishing-resistant. PCI DSS 4.1 (expected 2026-2027) is widely anticipated to require phishing-resistant authentication for high-risk access.
• SOC 2: principle-based, no specific factor mandate, but customer security questionnaires increasingly ask about phishing-resistant MFA. "We use SMS OTP" is a soft no in B2B procurement.
• CMMC, FedRAMP, NIST-aligned compliance: explicitly track AAL classifications. SMS-OTP-based 2FA does not satisfy AAL2 in these regimes after the 2024 update.

The implication for production CIAM: the SMS OTP migration is not optional, it is on a clock driven by accumulating compliance and customer pressure.

The migration path

The 2026 sequence:

Step 1: enable passkeys. Add WebAuthn support, prompt users to enroll, default new sign-ups to passkey primary. Passkeys are the long-term target; every user who enrolls is a user who doesn't need OTP migration later.

Step 2: offer TOTP as the AAL2 fallback for users without passkey support. Authenticator app enrollment via QR code; standard backup-codes-on-enrollment to handle device loss. Most users with smartphones (most users in 2026) can do TOTP.

Step 3: make SMS OTP opt-in fallback only. Remove SMS from the default factor selection in the MFA enrollment flow; allow users to add it as a last-resort fallback. Communicate the deprecation timeline.

Step 4: phase out SMS OTP entirely (12-24 months). Notify enrolled-SMS-only users to migrate to TOTP or passkeys; provide assisted migration; eventually retire the SMS channel for primary authentication. Keep SMS as a verification mechanism for high-friction recovery flows (account recovery requires identity proofing that may include SMS), not as a primary factor.

The Auth0, Okta, WorkOS, Microsoft Entra, and most major CIAM platforms now ship this migration pattern as a managed flow. Self-hosted CIAM (Keycloak, Authentik) requires the operator to design the prompts and timing; the building blocks exist.

Where SMS OTP still legitimately fits

Honest accounting of the remaining roles:

• Account recovery as one factor among several — verify the user can receive a code at their registered phone number, alongside other identity-proofing checks. Not as the sole recovery factor.
• Markets without smartphone ubiquity — SMS works on any cellular device, including feature phones, which still dominate in some emerging markets.
• Customer-facing flows where the alternative is no MFA — better than nothing, but the right answer is to improve the alternative (drive passkey enrollment).
• High-friction step-up where additional channel proof matters — a financial transaction confirmation flow may want both a TOTP from the authenticator app and an SMS to the registered number, treating two independent channels as defense-in-depth.

In none of these does SMS OTP serve as the primary MFA factor in a high-assurance deployment. The role is residual.

Implementation guidance

1. Default to passkeys as primary MFA. Single-factor passkey authentication is AAL2 by itself.
2. TOTP as the AAL2-acceptable fallback for users without passkey support. Standard authenticator-app enrollment with backup codes.
3. SMS OTP is opt-in fallback only, never the default offered. Communicate the deprecation timeline.
4. Migrate enrolled-SMS-only users over 12-24 months. Notify, assist, eventually retire.
5. Use number-matching for push notifications if push is part of your MFA stack — the 2022 MFA-fatigue attacks (Uber, Cisco) made number-matching the production default for push.
6. For compliance-sensitive deployments (HIPAA, PCI, SOC 2): SMS OTP for primary access is a finding waiting to happen. Migrate ahead of the audit.
7. Audit MFA factor distribution — track passkey share, TOTP share, SMS share over time. The passkey share is the leading metric for migration success.