Join our Newsletter — 33% off our NHI Course

SMS one-time password

A SMS one-time password is a short, temporary code sent by text message to prove a user’s identity during login or a sensitive action. It is a form of time-limited authentication factor delivered over the mobile network, often used in IAM, but vulnerable to interception, SIM swapping, and message forwarding.

What SMS one-time passwords are and how they work

SMS one-time passwords are temporary codes delivered over the mobile network to confirm a login or sensitive action. They are simple to deploy because they ride on a familiar channel, but the channel itself is not a strong trust boundary.

Practically, an SMS OTP is best understood as a convenience factor, not a high-assurance authenticator. It can still improve security against password-only compromise, yet it remains exposed to weaknesses in telecom routing, handset compromise, and account recovery processes that can bypass the intended check.

Why SMS OTP is weaker than phishing-resistant authentication

The key limitation is that the code is delivered through a channel that can be intercepted, redirected, or socially engineered. If an attacker can control the phone number, the messages, or the user’s attention, the OTP no longer proves that the legitimate user is present.

That is why modern guidance increasingly treats SMS as a legacy fallback rather than a preferred second factor. MFA Guide explains how attackers bypass weaker MFA methods and why phishing-resistant options are preferred for sensitive access.

When stronger authenticators are available, the practical difference is not just usability. App-based or hardware-backed methods can bind the challenge more tightly to the device and the session, while SMS OTP often leaves room for code relay, forwarding, or SIM-related takeover.

Common failure modes and attack paths

SMS OTP fails most often when the attacker targets the delivery path rather than the password itself. A successful attack may involve SIM swapping, port-out fraud, malicious call forwarding, or an adversary-in-the-middle flow that captures the code as the user enters it.

It also creates a weak recovery path if organisations allow SMS to reset passwords or re-enrol authenticators without stronger verification. Twilio 0ktapus breach 2022 is a useful reminder that SMS phishing can scale quickly when a code is treated as enough proof on its own.

For a broader comparison of one-time password patterns, including the trade-offs between SMS, TOTP and authenticator apps, Authenticator Apps and OTP Guide covers how OTP enrollment, seed handling and backup paths affect real-world assurance.

Where SMS OTP still appears in IAM

SMS OTP still shows up in consumer accounts, low-risk workflows, and legacy IAM estates because it is cheap, familiar, and easy to roll out at scale. It is also sometimes retained as a recovery option, even after stronger sign-in methods are introduced.

The problem is that its apparent simplicity can hide a lot of risk ownership. If the organisation relies on SMS OTP, it must also own the quality of account recovery, phone-number change controls, help-desk verification, and exception handling around users who cannot receive a text.

That makes SMS OTP less of a standalone security control and more of an IAM design choice with lifecycle consequences. The real question is not whether it works in the happy path, but whether it still holds up when the user loses the device, the number is ported, or the account is targeted by social engineering.

How to evaluate whether SMS OTP is acceptable

Use SMS OTP only after checking whether the protected action is genuinely low risk and whether a stronger factor is available. NIST SP 800-63 Digital Identity Guidelines is the clearest external reference for understanding authenticator assurance and why some methods are better suited to higher-risk transactions.

For organisations that still permit SMS OTP, the most important design question is whether it is a fallback or a primary control. If it is primary, then the organisation is implicitly accepting a weaker assurance level and should treat that decision as a risk trade-off, not a neutral implementation detail.

Where possible, move sensitive access to phishing-resistant MFA and keep SMS only as a constrained recovery route with tighter verification. If SMS remains in use, the surrounding account lifecycle controls matter as much as the code itself.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-63, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
NIST SP 800-63 Digital Identity Guidelines Defines authenticator assurance and preferred phishing-resistant methods for login verification.
Recommendation — Use NIST 800-63 to choose stronger authenticators and reserve SMS for lower-assurance fallback paths.
NIST SP 800-53 Rev 5 IA-5 — Authenticator Management Covers lifecycle control of authenticators such as OTP secrets and delivery methods.
IA-2 — Identification and Authentication (Organizational Users) Addresses user authentication mechanisms for accessing systems and sensitive functions.
Recommendation — Apply IA-5 to govern issuance, use, renewal and revocation of OTP authenticators. Use IA-2 to require stronger authentication for organizational access than SMS-only verification.
OWASP ASVS V6 — Authentication Sets verification expectations for login assurance and factor strength in applications.
V7 — Session Management Supports review of how sign-in assurance carries into authenticated sessions after OTP entry.
Recommendation — Use V6 to verify that authentication flows do not rely on weak SMS-only proof. Use V7 to ensure session issuance and renewal remain bounded after OTP-based sign-in.