Why SMS OTP Delivery Fails at Scale (and How to Fix It Before It Costs You Signups)

The cost of failed codes

OTP authentication is the thinnest part of your funnel and the one you monitor least. A code that doesn't arrive stops a signup and turns a paying customer into a support ticket, all inside about ninety seconds. The user knows the code isn't there.

What happens next is predictable. They tap resend, twice. They try a different number, or they leave. Each resend costs you a message fee, and each abandoned session costs the acquisition spend that brought them to the form.

The Baymard Institute found that 17% of online shoppers abandoned an order in the previous quarter solely because the checkout was too long or complicated. An OTP authentication step that stalls is exactly that kind of friction, except it also locks people out of accounts they already own.

Choose the OTP authentication path

SMS is the default because enrolment costs nothing. Someone gives you a mobile number and one-time password authentication is done in one step with no app to install. That's why SMS authentication still carries most consumer verification traffic in the UK, and why replacing it wholesale is rarely realistic.

The tradeoff is that you've made your login dependent on infrastructure you don't control. Time-based one-time passwords generated by an authenticator app work offline and never touch a carrier, but the user has to enrol a device first for one-time password authentication, and enrolment is where you lose people. Voice delivery sits in between because it uses the same telephone network with different failure characteristics, which makes it a useful second attempt rather than a separate strategy.

Security matters here too. NIST classifies SMS and voice delivery over the public switched telephone network as a restricted authenticator, and Cifas recorded a 1,055% surge in unauthorised SIM swaps in 2024, with almost 3,000 cases filed to the National Fraud Database. So the honest position is this: keep one-time password authentication over SMS for low-friction consumer enrolment, and offer app-based otp authentication codes for accounts where the value at risk justifies the enrolment cost.

Diagnose OTP authentication failures

"The code didn't arrive" is four different problems under one umbrella. Before you change providers or add retries, separate them. The order below matters because each stage rules out the one before it.

1. Bad number data, where the number never had a chance of routing correctly

2. Unsuitable line type or an inactive number, where the format is fine but nothing is listening

3. Carrier or handset filtering, where the message was accepted upstream and stopped downstream

4. Fallback design, where delivery genuinely failed, and your flow had nowhere to go

Most teams start at step three because that's where the provider dashboard points them.

SMS authentication input errors

A UK mobile number entered as 0XXXXXXXXXX with no country context is ambiguous the moment it leaves the form. The ITU-T E.164 numbering plan caps international numbers at fifteen digits and structures them around a country code, and the leading zero is a national trunk prefix that gets dropped when the number goes international. Routing will fail if the number keeps both.

Fix this at input rather than in the delivery layer. Use a country selector that defaults sensibly and store the E.164 string rather than whatever the user typed. Ofcom advises against the mixed +44(0) presentation for the same reason, because it confuses the reader and the parser alike.

It is also worth checking how the form pastes values with spaces and brackets. Strip them before validation runs.

VoIP and recycled numbers

A structurally perfect number tells you the digits are plausible. It tells you nothing about whether a SIM is attached to it today. UK networks reclaim inactive pay-as-you-go numbers and reissue them, and Which? surveyed more than 15,000 members and found 11% had changed their mobile number in the past decade while only half updated it with every organisation holding it.

The code goes to a stranger, which is a delivery failure and an identity confidence failure at once. VoIP and software-based numbers add a second issue, because possession of a virtual line doesn't prove possession of a device, which is the whole premise of an out-of-band code.

The distinction to hold onto is between format checks and status checks. A format check runs against numbering rules. A Home Location Register (HLR query) goes to the network's subscriber database and returns whether the number is active or absent and which network currently holds it.

Carrier and device blocking

Some failures happen after your provider reports success. Ofcom finalised new rules in July 2026 requiring mobile operators and aggregators to block scam messages in transit on their networks, and operators were already stopping an estimated 600 million messages a year before that. Aggressive filtering will sometimes catch legitimate traffic, and Ofcom built in a right to challenge a blocking decision for exactly that reason.

Then there's the handset. Do Not Disturb and a phone sitting in a rural not-spot produce the same silence. Ofcom's Connected Nations 2025 data puts indoor 4G premises coverage from all operators at 78 to 84% in rural areas, so a share of your users are genuinely unreachable at the moment they hit send.

Repeating the same SMS down the same route repeats the conditions that failed and bills you for the privilege.

Missing fallback paths

An SMS-only otp authentication flow has one exit. When the message doesn't land, the legitimate customer has nowhere to go except a support queue, and the queue is expensive in a way the failed message wasn't.

Define the fallback ladder before you need it:

• Offer voice delivery of the same code after the first failed sms authentication attempt, because it uses a different delivery path on the same network

• Accept a code from an enrolled authenticator app when the account has one bound

• Accept a stored backup code when no working authenticator is available

• Route to full account recovery when nothing else applies

The trigger point matters more than the list. Surface the alternative after the first failure, not the third, because by the third the person has already decided your product is broken.

Validate numbers before sending

Validation for otp authentication belongs upstream of the OTP request. The places that earn it are signup and password reset. Those are the moments where a bad number enters your database, or an outdated one gets used for something consequential.

Acudo sits in front of your existing OTP provider rather than replacing it. The sequence is user input, then a number intelligence check against 220+ network operators that covers line type and current status. Your application decides from that response whether to proceed with the send.

Numbers that were never going to deliver stop consuming message spend and stop producing mystery failures in your dashboard. A number that returns as VoIP or absent gives your fraud logic a signal at signup rather than after an account takeover.

Build TOTP enrolment correctly

Time-based one-time password (TOTP) enrolment starts with a shared secret delivered as a Base32 string inside a QR code, which the authenticator app stores and the server keeps alongside the account. From that point, both sides compute the same code independently. No message is sent, which is precisely why the carrier problems above disappear.

RFC 6238 sets the time step at 30 seconds and recommends allowing at most one additional step for network delay, so a validation window of plus or minus one step. Widen it beyond that, and you extend the attack window on a six-digit code. Keep it too narrow and you reject correct codes from phones whose clocks have drifted, which produces the worst kind of support ticket: the customer is doing everything right, and your system says no.

Handle drift with an explicit re-synchronisation path rather than a permanently loose window. Log rejected-but-close codes separately from wrong codes, because the first pattern tells you about clock skew and the second tells you about something else entirely.

Design account recovery

Every otp authentication factor you add is a factor someone can lose. Phones get replaced and stolen, and the account behind them still needs an owner. NIST's guidance on saved recovery codes specifies at least 64 bits from an approved random bit generator, issued at enrolment, with a notification sent whenever a replacement is requested.

Issue backup codes at the moment of TOTP enrolment, not later, and make the user acknowledge storing them before the flow completes. For re-enrolment on a new device, require a real authentication event rather than a knowledge question, because knowledge questions are the softest surface on the account.

The rule to hold: recovery must never be cheaper for an attacker than the front door. If someone can bypass a bound authenticator by claiming device loss and answering a security question, the authenticator was decoration. Notify the account holder on every recovery event through a channel other than the one being recovered.

Build the failure response

When delivery still fails during otp authentication, the response has to be designed rather than improvised. Rate-limit resends with a visible countdown and a hard cap per session, both to control cost and to close the endpoint that SMS pumping attacks feed on. Tell people what's happening in specific terms, because "code sent" is useless when nothing arrived.

Monitor delivery by carrier and line type rather than in aggregate, since an aggregate success rate hides the segment that's failing. Automatic channel fallback to voice after the first failed sms authentication attempt, and a route into authenticator enrolment for anyone who fails twice, turns a dead end into a working path. Watch your rejected-valid-code rate as a separate signal, because that's a clock problem.

Prioritise the upstream work. Validating the number before the send removes failures that no retry logic can recover from, and graceful fallback handles what's left.

Conclusion

Failed codes are a data quality problem dressed up as a telecoms problem. Fix the number before the send and give people a second route when the first one goes quiet.

Acudo brings HLR lookup and E.164 formatting into one platform, which checks whether a number is real and active before your budget and your customer's patience are spent on it. Talk to our team about placing number validation in front of your one-time password authentication flow.