SMS one-time passcodes have an odd reputation.
Some providers present SMS OTP as a complete answer to authentication and fraud. Some security teams treat it as obsolete. Neither position is particularly helpful.
SMS OTP can add a useful possession check to a password-based journey, confirm that someone can receive messages at a phone number, and provide a familiar step-up challenge for particular actions. It works on almost every mobile phone and does not require the user to install an app.
But SMS OTP is not phishing-resistant. It can be exposed to real-time phishing, SIM-swap attacks, number-porting fraud and social engineering. It is also only useful when the message arrives while the user is still attempting to log in, register or complete a transaction.
NIST SP 800-63B-4, the U.S. federal digital identity guideline published in final form in July 2025, therefore treats authentication over SMS and voice as a restricted form of out-of-band authentication. For higher-assurance access, phishing-resistant methods such as FIDO2 credentials and passkeys should be preferred where they are available, which is also the UK National Cyber Security Centre's position on recommended types of MFA.
This creates two separate questions:
- Is SMS an appropriate verification method for this particular action?
- Can the messaging operation deliver and validate the code quickly and reliably?
Security policy should answer the first question. Messaging infrastructure and operations determine the second.
What does an SMS OTP actually prove?
A successfully entered SMS code indicates that someone had access to the destination phone number at that moment.
That is useful evidence, but it is not the same as proving the user's real-world identity. It also does not automatically prove that the user understood or intended the action being authorised.
The assurance provided by SMS OTP depends on the surrounding flow:
| Use case | Appropriate role for SMS OTP |
|---|---|
| Phone-number verification | Confirms current access to the number |
| Account registration | Adds friction against automated or disposable-account creation |
| Password plus SMS login | Adds a possession check beyond the password |
| Account recovery | Can support recovery, but the registered number and number-change process must be protected |
| Payment or payout approval | Can support step-up verification, ideally with transaction-specific context and additional risk checks |
| Privileged administration | Should not normally be the strongest available factor; phishing-resistant authentication is preferable |
For a sensitive transaction, the message should describe what is being approved. A generic “Your verification code is…” message can be copied into a phishing site without helping the customer recognise the fraudulent action.
A more useful message would identify the brand and limited transaction context:
Your ExampleApp code to approve a £250 payment to J Smith is 482913. Do not share this code.
The application should also bind the OTP request to the original user, session and action. Entering a valid code into a different transaction or a later session should not authorise anything.
Where email OTP fits
Email codes can be useful for:
- Confirming ownership of an email address
- Account activation
- Lower-risk passwordless journeys
- Selected recovery workflows
- Fallback for journeys where the resulting reduction in assurance is acceptable
Email should not automatically replace SMS in every failed high-risk flow. A fallback channel can become an attacker's preferred bypass if it is easier to compromise than the original factor.
NIST SP 800-63B-4 does not allow email as an out-of-band authenticator, while separately recognising email-confirmation and certain recovery-code use cases. The practical lesson is not “never use email codes.” It is to define exactly what an email code proves and where that level of assurance is acceptable.
Secure OTP implementation is more than generating six digits
Generating a random number and sending an SMS is easy. Operating a production verification service is not.
A secure OTP flow should include the following controls.
Short validity and one-time use
A code should expire quickly and become unusable immediately after successful verification.
NIST SP 800-63B-4 permits a maximum completion period of ten minutes for out-of-band authentication, requires the secret to be accepted only once and requires at least six decimal digits or an equivalent level of randomness. Many commercial journeys sensibly choose a shorter validity period.
Strict attempt limits
A six-digit code has only one million possible values. Rate limiting is therefore essential.
Limits should cover more than code entry. They should also apply to:
- OTP requests
- Resend requests
- Attempts per account
- Attempts per phone number
- Attempts per device or network pattern
- Sudden traffic to expensive or unusual destinations
Importantly, issuing a new code should not reset the accumulated failed-attempt count. That requirement is explicit in SP 800-63B-4.
Secure code handling
OTP values should not appear in ordinary application logs, analytics tools, customer-service screens or long-term plaintext storage.
The service should store only what is needed to validate the submitted code, apply an expiry and consume the code after successful use. The OWASP Multifactor Authentication Cheat Sheet also recommends treating authenticator changes and recovery processes as high-risk actions rather than trusting an existing session automatically.
Abuse controls
Attackers do not always try to guess the code. They may generate large volumes of OTP requests to inflate messaging costs, test phone numbers or exploit high-cost destinations.
Request velocity, destination patterns, repeated resends and requests that never lead to successful verification should all be monitored. The UK National Cyber Security Centre has specifically warned businesses about artificially inflated SMS traffic affecting OTP services.
Why SMS OTP delivery fails
Once generation and validation are implemented correctly, many user-visible failures occur further down the messaging chain.
A messaging API may accept the request even though the message is later:
- Filtered by a carrier
- Delayed on a congested route
- Sent through a poorly performing vendor path
- Rejected because of sender or template-registration requirements
- Queued behind lower-priority traffic
- Delivered after the user requested another code
- Lost during a provider or carrier incident
Performance also varies by country and mobile network. A provider that works well on one route may perform poorly on another.
This is why changing from one SMS provider to another rarely solves OTP reliability permanently. The stronger architecture is to maintain more than one route, detect deterioration at the relevant country or operator level and move traffic before the failure becomes a broad customer incident.
For a practical troubleshooting framework, see OTP delivery issues.
A production OTP flow
A mature verification flow normally contains eight stages.
1. Accept and validate the request
Normalise the phone number, establish the event being verified and associate the request with the user and session.
2. Apply policy and abuse checks
Check request velocity, account state, destination, risk signals and whether SMS is permitted for the action.
3. Generate the code securely
Generate the value using a cryptographically suitable random generator. Store only the validation material, expiry, attempt count and event context.
4. Dispatch through an OTP-specific path
Time-sensitive verification traffic should not wait behind marketing campaigns or bulk notifications.
5. Observe the delivery attempt
Record the vendor, route, country, operator where available, latency and result against one request identifier.
6. Apply controlled failover
When the primary route fails or breaches the allowed delivery window, try an approved alternative vendor.
A fallback to email or another channel should follow the policy for that use case. A low-risk signup may allow email fallback. A high-value payout may need to fail closed or move to a stronger verification method.
Channel fallback does not have to require a new application integration. Organisations that already submit OTP traffic over SMPP can use Flow2FA — a focused Flowstates product — to add WhatsApp delivery with SMS retained as the fallback path while leaving the upstream SMPP workflow intact.
7. Validate and consume the code
Confirm that the code matches the original request, has not expired, has not already been used and remains within the permitted attempt count.
8. Record the outcome
Record whether the user successfully completed verification, not merely whether the carrier returned a delivery receipt.
Delivery rate is not the business outcome
A carrier delivery receipt does not tell you whether the customer saw the message, entered the code or completed the transaction.
The measurements that matter are:
- End-to-end verification completion rate
- First-attempt verification rate
- Resend rate
- Request-to-delivery latency at the median and tail
- Completion and latency by country, operator and route
- The gap between reported delivery and successful verification
- Cost per successful verification
- OTP requests per completed verification
- Incidents involving stale or out-of-order codes
Every send and verification event should share a request identifier. Without that connection, teams are left comparing a messaging dashboard with an application dashboard and guessing where users disappeared.
For the complete measurement model, read The Metrics That Actually Predict OTP Success.
What to ask an SMS OTP provider
The right provider is not necessarily the one with the lowest unit price.
Ask:
- Does the service generate and validate codes, or only send the SMS?
- Can it route across more than one SMS vendor?
- Can routes be configured by country, operator or use case?
- What triggers a retry or failover?
- Can fallback policy differ between low-risk and high-risk journeys?
- Does every attempt have a request-level audit trail?
- Can you see which vendor was used, how long the attempt took and why it failed?
- How are OTP values stored and protected from logging?
- What controls exist for resend abuse and artificially inflated traffic?
- Who investigates carrier and vendor problems when a route deteriorates?
- Can you retain your current messaging vendors?
- Are failed retries and fallback attempts clearly reflected in pricing?
A low-cost route that regularly delivers after the customer has abandoned the page is not a low-cost route.
Where Flowstates fits
Flowstates provides a managed OTP delivery and verification layer.
The Flowstates OTP API uses one endpoint to send a code and another to verify it. It can cascade across multiple SMS vendors, apply configured email fallback, track send and verification attempts and operate with either the customer's existing vendors or the Flowstates managed network.
That role should be described precisely.
Flowstates helps operate the delivery, routing, fallback and attempt-tracking layer. The customer's application, identity platform or risk engine still determines:
- Which actions require verification
- Whether SMS provides enough assurance
- Whether email fallback is acceptable
- When a stronger factor or manual review is required
That separation makes the proposition more credible. Flowstates does not need to claim to replace passkeys, identity platforms or fraud engines. Its value is ensuring that when the application decides to use OTP, the messaging operation does not become the reason the customer fails.
For a closer look at route resilience, see multi-vendor OTP failover.
Where this leaves SMS OTP
SP 800-63B-4 restricts PSTN-based out-of-band authentication rather than banning it outright, and it is U.S. federal guidance, not global law. The practical position for most commercial services is that SMS OTP remains a widely accessible possession signal, that phishing-resistant alternatives should be offered where assurance requirements are higher, and that risk indicators around the phone number and the request pattern should be monitored continuously.
The operational half of that is measured, not assumed: whether the code arrives while the user is still in the flow, and whether verification completes. When customers cannot log in, register or transact without receiving a code, OTP delivery is part of the product's availability.