Who is accountable when SMS toll fraud is enabled by authentication design?

Why This Matters for Security Teams

SMS toll fraud is not just a telecom cost issue. It is an authentication design failure that creates direct financial loss, weakens trust in the verification journey, and exposes a gap between security ownership and commercial impact. When a login, reset, or enrolment flow can trigger high-cost messaging without rate limits, risk scoring, or budget controls, fraudsters treat the process itself as an attack surface.

That matters because accountability follows control of the journey, not just ownership of a system. A team that owns identity proofing but does not own message delivery can miss abuse at the point where spend is created. Likewise, a communications team may see message volume spikes without understanding the identity trigger that caused them. NIST’s NIST Cybersecurity Framework 2.0 reinforces that governance and risk ownership must be explicit, while the Ultimate Guide to NHIs shows how identity-related control gaps persist when ownership is fragmented. In practice, many security teams encounter SMS toll fraud only after the bill arrives, rather than through intentional control testing.

How It Works in Practice

The practical question is who can change the verification flow, who can approve spend, and who can stop abuse when it starts. In mature environments, accountability sits with the product or platform owner for the journey, the identity team for verification logic, and the fraud or abuse team for thresholds, anomaly detection, and escalation. Commercial teams often need visibility too, because message delivery can create immediate budget exposure even when no account takeover succeeds.

Current guidance suggests treating SMS as a risk-bearing channel, not a neutral delivery mechanism. Controls usually include per-number and per-device rate limits, step-up challenges, spend caps, country or carrier blocking, disposable-number detection, and runtime policy checks before messages are sent. The goal is to reduce unauthorised trigger events, not merely to log them after the fact. The Ultimate Guide to NHIs is relevant here because the same governance problem appears whenever an identity workflow can invoke an external service without a clearly owned control plane.

Operationally, the best pattern is to define one accountable owner for the end-to-end verification journey, then require shared controls across identity, fraud, and finance. That owner should be able to answer three questions: what triggers an SMS, how much abuse can be tolerated, and who is paged when thresholds are crossed. NIST’s NIST Cybersecurity Framework 2.0 is useful because it ties governance, detect, and respond activities to measurable business impact. These controls tend to break down in federated organisations where the app team, telecom provider, and fraud team each see only part of the workflow.

Common Variations and Edge Cases

Tighter controls often increase friction for legitimate users, so organisations have to balance fraud reduction against conversion, accessibility, and support burden. That tradeoff is real, especially when SMS is still used as a fallback channel for users without stronger authenticators.

There is no universal standard for this yet, but current guidance suggests that higher-risk journeys should move away from SMS-only verification where possible, especially for password resets, number changes, and high-value account actions. In those cases, accountability may shift toward the team that owns the risk decision, not just the team that sends the message. Where SMS remains necessary, the owner should require exception handling, abuse review, and commercial escalation as part of the control design.

Edge cases appear when an organisation outsources messaging or authentication to separate vendors. That can blur responsibility unless contracts define who monitors abuse, who can suspend sending, and who bears the cost of fraudulent traffic. The broader NHI lesson from the Ultimate Guide to NHIs is that distributed control without distributed accountability leaves gaps that attackers quickly find. In practice, weak ownership shows up when fraud teams see spend anomalies after abuse has already scaled, rather than during design review.

Related resources from NHI Mgmt Group

• Who is accountable when a pre-authentication RCE affects an AI service?
• Who is accountable when fraud starts on social media or SMS and ends in a payment?
• Who is accountable when weak authentication leads to payment fraud?
• Who is accountable when age assurance decisions are challenged by regulators?