SMS OTP is the default second factor across Indian apps — you enter your password, a six-digit code lands by text, you type it in. It's familiar, it works on every phone, and it's also the weakest mainstream form of two-factor authentication still in wide use. The codes travel over a network you don't control, to a SIM that can be hijacked, and an attacker who intercepts one is in.

The regulators have noticed. NIST now classifies SMS as a "restricted" authenticator, and the RBI's 2025 authentication rules — effective April 2026 — require at least one dynamic factor for digital payments and explicitly nudge providers off SMS-only setups. This isn't a ban on SMS OTP, but it is the end of treating it as good enough on its own. Here's how TOTP differs, why it's stronger, what the rules actually say, and how to choose.

How SMS OTP works — and where it breaks

An SMS OTP is generated on a server and sent to the user's phone number over the mobile network. That delivery path is the weakness, and it fails in several well-documented ways:

SIM swap. An attacker social-engineers the telecom into porting the victim's number to a new SIM. Every OTP now lands on the attacker's phone. This is the dominant SMS-OTP attack in India.
Network interception. The SS7 signaling protocol underlying SMS has known weaknesses that allow message interception without touching the phone.
Real-time phishing. A fake login page relays the victim's credentials and the OTP to the real site in real time. SMS doesn't protect against this — the user reads the code aloud, effectively.
OTP-bot social engineering. Automated calls impersonate the bank and trick the user into reading out the code.
Cost and deliverability. SMS OTPs cost money per send, can be delayed or undelivered, and become an expensive, abusable surface under flood attacks.

The common thread: the secret leaves the user's device and travels across infrastructure neither you nor they control.

How TOTP works

TOTP — Time-based One-Time Password, defined in RFC 6238 — never sends a code anywhere. At enrollment, the server and the user's authenticator app (Google Authenticator, Authy, a password manager) agree on a shared secret, usually via a QR code. From then on, both sides compute the same six-digit code independently from that secret plus the current time, rotating every 30 seconds:

code = HOTP( shared_secret, floor(current_time / 30) )   // truncated to 6 digits

The user reads the code off their own device and types it in. Nothing transits the network at authentication time. There's no SMS to intercept, no SIM to swap, no delivery cost, and it works offline on a plane.

Why TOTP beats SMS

	SMS OTP	TOTP
Code travels over a network	Yes (interceptable)	No — computed on-device
Survives a SIM swap	No	Yes (no phone-number dependency)
Per-use cost	Yes (per SMS)	None
Works offline	No	Yes
Resists real-time phishing	No	No — see below

TOTP closes the SMS-specific holes: SIM swap and network interception simply don't apply when the code never leaves the device. What it does not fix is real-time phishing — a user can still be tricked into typing a valid TOTP code into a fake site that relays it. TOTP is a large step up from SMS, but it's not the end state. The phishing-resistant answer is passkeys, which bind the credential to the origin so a relayed code is useless. Think of it as a ladder: SMS → TOTP → passkeys, each rung closing failures the last one left open.

What NIST says

The 2025 revision of NIST's digital identity guidelines (SP 800-63B-4) places SMS and other public-network OTP delivery in the "restricted authenticator" category — still permitted, but discouraged, with extra obligations to warn users and offer alternatives. The direction of travel is explicit: out-of-band codes sent over the phone network are a fallback, not a foundation.

What RBI's 2025 Directions actually require

For Indian builders this is the load-bearing part, so it's worth stating precisely — not as the "RBI bans SMS OTP" headline you may have seen.

The RBI (Authentication Mechanisms for Digital Payment Transactions) Directions, 2025, issued 25 September 2025 and effective 1 April 2026, require two-factor authentication for digital payment transactions, and crucially: for transactions other than card-present ones, at least one factor must be dynamic — a unique proof of possession generated per transaction. SMS OTP remains an acceptable factor. But the RBI explicitly asks regulated entities to "encourage adoption of newer authentication methods" — device-bound tokens, biometrics, QR-code approvals — and frames authentication as risk-based rather than one-size-fits-all. (KPMG summary, RBI notification)

So the accurate reading: SMS OTP isn't outlawed, but building on it as your only factor now runs against both the letter (you need a dynamic factor) and the spirit (the RBI wants you moving to stronger methods) of the rules.

What this means for builders

You don't need to rip out SMS overnight, but you do need to stop treating it as sufficient:

Offer TOTP and passkeys as first-class factors, not buried options. Both satisfy "at least one dynamic factor" with a device-bound proof of possession.
Keep SMS as a fallback, not the default — for users who can't set up an authenticator — and warn that it's the weaker option (which NIST now effectively asks you to do anyway).
Make the strong factor the easy path. Adoption follows the default; if the secure option is two extra taps, most users won't take it.

NamoID ships TOTP MFA and passkeys (WebAuthn) as built-in factors, so meeting "at least one dynamic factor" is a configuration choice, not an integration project — and you can offer the device-bound options the RBI is steering toward without wiring up a separate vendor.

FAQ

Did the RBI ban SMS OTP? No. The 2025 Directions keep SMS OTP as an acceptable factor but require at least one dynamic factor for digital payments and encourage moving to stronger methods. SMS-only is what's effectively on the way out.

Is TOTP phishing-proof? No. TOTP stops SIM-swap and interception, but a real-time phishing page can still relay a code. Passkeys are the phishing-resistant step beyond it.

Is TOTP hard for users? It's one QR scan at setup, then a code from an app they already have. Easier than waiting on a delayed SMS, and it works offline.

What about WhatsApp OTP? It avoids some SMS cost and deliverability issues but is still an out-of-band code that can be phished or relayed — closer to SMS than to TOTP on the security ladder. We compared the channels here.

Give users a factor that can't be SIM-swapped

SMS OTP was a reasonable default a decade ago. In 2026, with SIM-swap fraud common, NIST restricting it, and the RBI requiring a dynamic factor, it's the floor — not the ceiling. TOTP removes the network and SIM weaknesses for almost no user friction, and passkeys finish the job on phishing.

NamoID gives you TOTP, passkeys, and OTP as configurable factors behind one identity layer, so you can offer the strong, RBI-aligned options by default and keep SMS only as a fallback. If you're choosing how to authenticate Indian users, start one rung up from SMS.