How should security teams replace SMS OTP in AI-heavy fraud environments?

Why This Matters for Security Teams

SMS OTP is still widely used because it is familiar, but in AI-heavy fraud environments it has become a weak trust signal rather than a strong factor. Phishing relay kits can capture the code in real time, and voice cloning can be used to pressure help desks or recovery flows. NIST SP 800-53 Rev 5 Security and Privacy Controls treats authentication as part of a broader control system, but the control only works when the factor resists interception and replay. In practice, the risk is no longer just credential theft; it is automated abuse at speed.

The larger issue is that SMS OTP creates a shared weakness across login, recovery, and exception handling. Once an attacker can social-engineer one code, they can often move from account takeover to fraud, especially where step-up checks are inconsistent. NHIMG research on the LLMjacking threat pattern shows how quickly exposed credentials can be abused once attackers identify a path in. For teams modernising authentication, the question is not whether SMS can be improved, but whether it should remain in high-risk journeys at all. In practice, many security teams discover OTP bypasses only after an account takeover or recovery abuse has already occurred, rather than through intentional testing.

How It Works in Practice

The replacement model should move from code entry to possession-based verification that is bound to a device, a SIM-backed identity, or a cryptographic authenticator. Current guidance suggests preferring phishing-resistant methods for high-risk flows, such as passkeys, device-bound credentials, or app-based authenticators with strong device attestation. Where fraud risk is elevated, the factor should be silent to the user, difficult to relay remotely, and short-lived enough to reduce replay value.

A practical rollout usually includes three layers. First, map which journeys are truly high-risk, such as password reset, payout changes, new device enrolment, and recovery. Second, replace SMS with a stronger primary factor, then add step-up controls only when context changes. Third, harden fallback so that human-mediated recovery is rare, logged, and approved through a separate workflow. NIST SP 800-53 Rev 5 Security and Privacy Controls can help anchor the broader control set, while CISA guidance on phishing-resistant authentication is useful for setting policy expectations. For organisations tracking NHI exposure and token abuse, NHIMG’s State of Secrets in AppSec is a useful reminder that weak trust paths and secret sprawl often fail together.

• Use possession-bound factors that cannot be forwarded by SMS relay or vishing.
• Issue short-lived credentials for the session or transaction, not reusable codes.
• Separate login auth from recovery auth so one compromise does not unlock both.
• Apply risk scoring at request time, not just at enrolment time.

Where organisations are using NIST SP 800-53 Rev 5 Security and Privacy Controls, the strongest outcome comes from treating SMS as legacy only, then explicitly removing it from any transaction where fraud loss would be material. These controls tend to break down in large consumer systems with high support volume because recovery teams keep reintroducing SMS as the easiest exception path.

Common Variations and Edge Cases

Tighter authentication often increases support cost and user friction, requiring organisations to balance fraud reduction against abandonment and recovery overhead. That tradeoff is especially visible in markets where device ownership is uneven or where roaming, shared phones, and prepaid SIMs are common. Best practice is evolving here, and there is no universal standard for when SMS should be retained, but current guidance strongly favours limiting it to low-risk, non-sensitive contexts.

Edge cases usually appear in regulated onboarding, account recovery for locked-out users, and call-centre assisted changes. In those environments, the real risk is not only interception but also policy drift, where exceptions become the default path. Teams should define explicit fallback criteria, add identity proofing for assisted recovery, and review whether a device-bound factor can be re-enrolled more safely than a code-based one. The Schneider Electric credentials breach illustrates how quickly exposed access paths can become operational incidents once controls are too easy to bypass.

For teams operating at scale, the right question is whether SMS OTP still earns a place anywhere in the journey. In fraud-heavy environments, the answer is usually yes only as a low-assurance bridge, not as a trust anchor.

Related resources from NHI Mgmt Group

• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities in cloud environments?
• How should security teams handle risks from AI browser extensions?
• How should security teams govern API keys used for generative AI access?