SMS pumping exposes the trust gap in phone verification flows

At a glance

What this is: This is an analysis of SMS pumping, a fraud pattern that abuses SMS OTP flows to generate unwanted traffic and telecom revenue.

Why it matters: It matters because consumer IAM teams, identity architects, and fraud leads need to treat OTP delivery as a costed attack surface, not just an authentication step.

By the numbers:

• Juniper Research put global enterprise losses to artificial inflated traffic at a peak of $2.1 billion in 2023.
• X said in 2023 that it was losing about $60 million a year to fake 2FA traffic routed through roughly 390 telecom operators.

👉 Read Authsignal's analysis of how to mitigate SMS pumping without breaking signup

Context

SMS pumping is a fraud pattern against verification flows, not an account takeover technique. The attacker does not need to steal a password or intercept a code. They only need the application to send an SMS, which turns the OTP step into a billable event.

That creates a governance problem for consumer IAM and authentication teams. If the programme measures requests sent rather than successful verifications, it can mistake abuse for growth. The result is wasted spend, distorted funnel metrics, and a verification design that treats every phone number submission as a message worth paying for.

Key questions

Q: How should security teams reduce SMS pumping without hurting signup conversion?

A: Start by moving channel selection into runtime rules so SMS is only used when risk and coverage justify it. Use passkeys for returning users, route higher-risk destinations to non-SMS channels, and keep SMS as a fallback for first-time verification and recovery. That reduces exposure while preserving completion rates for legitimate users.

Q: Why do SMS OTP flows attract fraud even when accounts are not under attack?

A: Because the delivery event itself creates value. Fraudsters do not need the code or the account, only the application’s willingness to send a message that produces termination fees. If security teams measure only sends, they can miss the real signal, which is low verification success against rising message volume.

Q: What breaks when teams rely on SMS as the default authentication channel?

A: The model breaks when every phone-number submission becomes an expensive, abuseable event. Default SMS use creates predictable routing, exposes termination-fee incentives, and makes it harder to distinguish genuine growth from pumping. Once that happens, both cost control and fraud detection become reactive instead of preventative.

Q: Who should own SMS pumping risk in an organisation?

A: Ownership should sit across identity engineering, fraud operations, and the business team paying the telecom bill. IAM controls decide whether SMS is sent, fraud teams watch for abusive patterns, and finance needs the spend caps and alerting that expose abnormal traffic before the cost becomes material.

Technical breakdown

How SMS OTP abuse turns verification into revenue fraud

SMS pumping, also called SMS toll fraud or artificially inflated traffic, exploits the moment an application sends an OTP before it knows whether the request is legitimate. Bots can trigger real messages to real numbers, often arranged to route through operators or networks that share termination fees. The code is irrelevant because the fraud pays on delivery, not on completion. This is why the send event itself becomes the attack objective, and why simple number validity checks do not stop the abuse.

Practical implication: treat SMS send authorization as a fraud decision, not a background delivery step.

Why bot detection and carrier checks miss pumping patterns

The abuse is hard to spot because the numbers can be real, the traffic can appear to come from markets you actually serve, and the requests can be spread over time to avoid burst-based thresholds. A carrier lookup may confirm the number exists, but it does not tell you whether the route is being exploited for revenue share. The more reliable signal is the mismatch between codes sent and codes successfully verified, especially when that gap widens by prefix, country, or device pattern.

Practical implication: monitor verification conversion by prefix, country, and device, not just message volume.

Why runtime channel selection is the real control plane

Static SMS policies age badly because pumping risk changes by destination, carrier, and user state. A better design chooses the channel at runtime. High-risk markets can move to WhatsApp or email, returning users can use passkeys, and supported mobile numbers can be verified through silent network authentication so no SMS is sent at all. That shifts the control point from delivery to decision, which is where fraud pressure actually lives.

Practical implication: move verification choice into configurable authentication rules so risky requests can be rerouted before any SMS is sent.

NHI Mgmt Group analysis

SMS pumping is a verification governance failure, not a messaging problem. The article shows that OTP flows become profitable targets the moment the application sends before it knows whether the requester is legitimate. That is exactly where consumer IAM programmes over-trust delivery mechanics and under-govern send authorisation. Practitioners should treat the send step as a policy decision, not a utility call.

Identity blast radius in SMS flows is measured in spend and signal quality. A pumping campaign does not need access to accounts to cause damage. It can still distort conversion metrics, exhaust budget, and mask genuine signup behaviour inside what looks like organic growth. This is why lifecycle governance for authentication channels belongs in IAM, fraud, and finance conversations together.

Channel selection at runtime is now a governance requirement. Static SMS-by-default designs assume risk is stable across country, carrier, device, and user state. In practice, pumping shifts across those variables faster than hard-coded flows can adapt. Teams that cannot change the channel before the send are already operating with a weak control boundary.

Passkeys and silent authentication reduce exposure by removing the billable event. The article’s strongest point is not that SMS should disappear overnight. It is that the best defence is to stop creating avoidable OTP sends for returning users and supported markets. That changes the control objective from fraud detection after dispatch to preventing the dispatch in the first place.

Runtime verification policy should be owned as part of identity architecture, not just anti-fraud tuning. Prefix controls, geo-permissions, and provider spend caps work best when they are integrated into authentication orchestration. The field should stop treating SMS as a neutral fallback and start treating it as a managed risk channel with explicit governance boundaries.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• The same governance pattern appears here: when controls depend on human review after exposure, the abuse path often finishes before the response cycle begins, as discussed in LLMjacking: How Attackers Hijack AI Using Compromised NHIs.

What this signals

SMS pumping should be managed as a channel-governance issue inside identity architecture. Teams that leave SMS as the default fallback will keep paying for abusive traffic, because the attacker only needs a send opportunity, not a login. The practical shift is to make verification channel choice conditional, observable, and reversible at runtime.

With 43% of security professionals already concerned about AI systems learning and reproducing sensitive information patterns from codebases, per The State of Secrets in AppSec, identity programmes are clearly moving toward more dynamic risk decisions, and SMS is no exception. The more static the fallback, the easier it is for fraud to convert routine authentication into cost.

Identity blast radius now includes telecom spend. When a verification flow can be monetised without account compromise, the control boundary has moved upstream into policy, routing, and provider governance. IAM teams should expect more scrutiny on channel selection, fraud thresholds, and the evidence used to justify SMS as a default option.

For practitioners

• Move SMS send decisions into orchestration rules Make the channel choice depend on country code, user state, device reputation, and enrolled authenticators before any SMS is sent. Keep the rules editable so fraud response does not require code changes.
• Track verification conversion by prefix and country Measure the gap between codes sent and successful verifications by phone prefix, destination country, and device pattern. A widening gap is often the earliest operational sign of pumping.
• Add hard limits on repeated sends Cap sends per phone number, prefix, IP, and device, then lower thresholds for markets with low legitimate volume or known abusive routing. Pair those caps with alerting so the limit is visible when it is hit.
• Use non-SMS channels for higher-risk routes Route supported users to passkeys, WhatsApp OTP, or email where those channels reduce telecom exposure and still preserve signup completion. Reserve SMS for first-time verification and recovery cases where alternatives are not available.
• Require provider-side fraud controls and spend caps Ask the SMS provider for pumping detection, geo-permission controls, volume alerts, and daily or monthly spend limits. Treat the provider as a backstop, not the primary defence, because the application still owns the send decision.

Key takeaways

• SMS pumping weaponises the OTP send itself, so the control problem starts before verification completes.
• Volume alone is a weak signal because the most damaging fraud pattern looks like normal signup growth until conversion data is compared.
• The most effective defence is runtime channel choice, backed by passkeys, non-SMS routing, and provider spend controls.

Key terms

• Sms pumping: SMS pumping is fraud that abuses verification flows to generate billable text messages. The attacker does not need the OTP or the account. The business impact is telecom spend, distorted funnel data, and a verification channel that can be monetised by outsiders.
• Termination fees: Termination fees are the charges paid when an SMS is delivered across a telecom route. In pumping schemes, those fees create the payout, which is why the attacker cares about message delivery rather than authentication success.
• Runtime channel selection: Runtime channel selection is the practice of choosing an authentication method at the moment of request based on current risk signals. In this context, it lets teams route some users to passkeys, WhatsApp, email, or silent authentication instead of sending SMS by default.
• Silent network authentication: Silent network authentication verifies a phone number through the mobile network without sending an OTP message. It reduces exposure to pumping because there is no text message for a fraudster to trigger, though coverage depends on carrier and market support.

What's in the full article

Authsignal's full blog post covers the operational detail this post intentionally leaves for the source:

• Exact routing logic for sending high-risk countries to WhatsApp OTP or email instead of SMS
• Examples of prefix-level, country-level, and device-level rate limiting rules used to blunt pumping
• Implementation guidance for silent network authentication and passkey fallback paths
• Provider-side control checklist covering fraud detection, geo-permissions, and spend caps

👉 Authsignal's full post covers the routing logic, rate limits, and provider controls in more implementation detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.