Research Deep Dive · 9 minute read
Why Use SMS OTP—and When Do Hardware Tokens Make Sense?
Follow an SMS code from server to phone, examine channel and phishing risks, and compare it with independent TOTP and HOTP devices.
SMS one-time passwords succeed because they do not require a user to install an application or enroll a specialized device. Register the phone number once, and a short code arrives during sign-in. That simplicity matters for services with broad audiences, but it does not make the channel the strongest security option.
How does the code reach the phone?
When sign-in begins, the service creates a short-lived code and sends it to an SMS gateway. The gateway interacts with the telecommunications network, routes the message to the carrier, and the carrier delivers it to the SIM and phone.
After the user enters the code, the server checks its value, expiration, and the number of previous attempts.
The journey shows that SMS is not a direct private channel between server and device. It involves a gateway, carrier, phone number, SIM, and recovery process—each with its own risks.
Where do the risks appear?
SIM swapping
An attacker may persuade a carrier to transfer the victim’s number to a SIM under the attacker’s control. Future codes then arrive at the wrong device.
Telecommunications weaknesses
SMS relies on infrastructure that was not originally designed as a phishing-resistant authentication channel. Under some threat models, weaknesses or privileged network access can enable message interception.
Phishing and adversary-in-the-middle attacks
The most immediate user-facing risk is a fake page that asks for both password and code, then relays them to the real service. A typed code is not cryptographically bound to the origin in the user’s browser.
Improving the SMS experience
- Use a short code lifetime and limit verification and resend attempts.
- Name the service and sign-in context clearly in the message.
- Support domain-bound one-time-code autofill where the platform provides it.
- Avoid shortened links in the code message.
- Alert the user to unexpected sign-in attempts.
- Encourage a separate carrier-account PIN.
These controls reduce risk, but they do not make SMS phishing resistant.
Hardware OTP devices
A hardware OTP token generates the code inside a device that is independent of the mobile network. During provisioning, the device identity is associated with the account. A shared secret then enables local code generation.
Two common models are:
- TOTP: a time-based code that typically changes every 30 or 60 seconds under RFC 6238.
- HOTP: a counter-based code that advances with each event under RFC 4226.
Because generation does not depend on the phone number, these devices are not exposed to SIM swapping or SMS interception.
Is hardware OTP phishing resistant?
Not necessarily. If a user types the code into a fake page, the attacker can relay it before it expires. Hardware OTP protects the generation channel, but it does not bind authentication to the legitimate website the way FIDO2/WebAuthn security keys do.
There are also physical and operational costs: device loss, purchasing, distribution, tracking, and replacement. Some tokens act as possession-only factors; others require a PIN or local verification before revealing a code.
When should each option be used?
SMS OTP can be appropriate when reach and ease of enrollment are priorities, or when the realistic alternative is password-only authentication. Hardware OTP fits environments that need generation independent of the phone network and can support device logistics.
When phishing is central to the threat model, FIDO2/WebAuthn security keys or passkeys provide stronger protection by binding authentication to the correct origin.
Takeaway
No method fits every context. SMS is easy but depends on the phone network and remains phishable. Hardware OTP isolates code generation but does not prevent relay and adds operational burden. A sound choice begins with the expected attacker, user capability, and deployment cost—then selects the strongest factor people can use correctly.