How should identity and fraud teams decide when to replace SMS OTP?

They should start with the journeys that create the highest loss exposure, especially login, password reset, and financial transaction approval. If those flows still depend on SMS, the control should be replaced or strengthened with mobile authentication, device intelligence, or behavioural signals. The decision should be based on risk and abuse data, not channel familiarity.

Why This Matters for Security Teams

SMS OTP has become a default control in many identity stacks, but default does not mean defensible. Fraud teams should replace it when the channel is no longer cost-effective against SIM swap, phishing relay, account takeover, or social engineering. NIST SP 800-53 Rev. 5 treats authenticator strength and lifecycle as control decisions, not channel preferences, and that framing is the right starting point for this decision.

The practical issue is that SMS OTP often fails where the user experience still looks familiar. Attackers exploit the gap between “something a user receives” and “something a user truly proves.” In parallel, identity teams often maintain SMS because it is already wired into login, reset, and step-up flows, even after abuse data shows it is absorbing loss rather than reducing it. NHIMG’s Ultimate Guide to NHIs notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is a reminder that weak proofing and poor lifecycle control routinely create downstream risk. The same pattern applies to customer authentication when the factor is easy to intercept or transfer.

In practice, many security teams discover SMS weakness only after repeated fraud losses or account recovery abuse has already become normalised.

How It Works in Practice

The replacement decision should start with a risk map of the journeys that matter most: login, password reset, device enrolment, transaction approval, and high-value profile changes. For each flow, measure the observed abuse rate, false positive rate, and the loss per successful compromise. That creates a business case for replacing SMS where it is performing as a convenience layer rather than a meaningful control.

Current guidance suggests moving to controls that bind authentication to a stronger signal than possession of an inbox or phone number. That usually means one or more of the following:

• Mobile authentication that uses device-bound cryptographic proof rather than a readable code
• Device intelligence that scores SIM change, emulator use, relay patterns, and risky network conditions
• Behavioural and contextual signals that support step-up decisions at runtime
• Fraud rules that treat SMS as a fallback only for low-risk recovery paths

This is where lifecycle and recovery design matter. If SMS remains in the stack, it should be tightly constrained, monitored, and paired with abuse-resistant recovery controls. NIST guidance on authentication control design in NIST SP 800-53 Rev 5 Security and Privacy Controls supports selecting authenticators based on assurance needs rather than habit. For identity programmes looking at broader exposure patterns, 52 NHI Breaches Analysis is a useful reminder that attackers often succeed by exploiting weak trust relationships and poor key management, not by breaking strong controls directly.

Teams should also define a migration threshold. For example, if a journey has repeated OTP relay or SIM-swap abuse, or if SMS is used in a high-loss path where possession alone is insufficient, the control should be retired or downgraded to a low-risk fallback. These controls tend to break down in countries or carrier environments with weak device telemetry, because the fraud signal needed to replace SMS is not consistently available.

Common Variations and Edge Cases

Tighter authentication often increases friction, support load, and recovery complexity, so organisations must balance fraud reduction against user abandonment and help-desk cost. There is no universal standard for when SMS should disappear entirely; current guidance suggests phasing it out by journey criticality rather than forcing a single enterprise-wide deadline.

Some environments still need SMS as a transitional option, especially where customer populations cannot reliably use mobile apps, where regulated accessibility constraints apply, or where device binding cannot yet be deployed. In those cases, the right answer is usually not to “keep SMS as-is” but to narrow its role. For example, it may remain acceptable for low-risk notifications while being removed from step-up authentication and account recovery.

Identity teams should also watch for hidden dependencies. Shared phone numbers, recycled numbers, call centre resets, and cross-border roaming can all weaken SMS assurance in ways that do not show up in simple login success metrics. The fraud programme should therefore review not just whether SMS is used, but whether it is still producing a measurable security benefit. NHIMG’s Top 10 NHI Issues reinforces a broader operational point: unmanaged trust assumptions tend to survive long after their risk profile has changed.

Related resources from NHI Mgmt Group

• How should security teams replace SMS OTP in AI-heavy fraud environments?
• How should security teams replace SMS OTP in customer onboarding?
• Why do SMS and email OTP methods fall short for high-assurance access?
• How should teams reduce friction in B2b onboarding without weakening identity checks?