Why do SMS OTP and voice checks fail more often against AI-driven fraud?

Why This Matters for Security Teams

SMS OTP and voice checks were designed for a threat model where a human could notice a suspicious request, refuse to comply, or at least slow the attacker down. AI-driven fraud removes that human advantage. A cloned voice, a live chat prompt, or a real-time relay can keep the interaction moving until the code is handed over. That means the control often fails not because it is absent, but because it is being used as if it were a strong authenticator when it is really a weak, user-dependent one.

That gap matters most in high-pressure workflows such as account recovery, payment approval, and help desk resets. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls treats authentication controls as part of a broader trust model, not a standalone guarantee. NHIMG research on the DeepSeek breach and the Schneider Electric credentials breach shows the same pattern: once an attacker can manipulate the credential path, the “second factor” becomes just another relay point. In practice, many security teams discover this only after a fraud case has already passed the verification step, rather than through a planned control test.

How It Works in Practice

AI-driven fraud succeeds because it compresses the time between persuasion and misuse. Voice cloning can make a callback seem legitimate, while a chatbot or call-centre script can keep the victim engaged long enough to capture an OTP before it expires. The secret is still short-lived, but it is no longer private. In other words, the failure is not cryptographic weakness alone; it is the combination of social engineering, real-time interception, and a control that assumes the user can reliably distinguish truth from deception under pressure.

Security teams usually reduce exposure by changing the transaction model rather than relying on a single code:

• Use phishing-resistant authentication for sensitive actions, especially account recovery and payout changes.
• Prefer number matching, device-bound approval, or cryptographic challenge-response over SMS OTP for high-risk flows.
• Step up verification when the context changes, such as a new device, unusual location, or impossible travel pattern.
• Bind the approval to the transaction details so the user is confirming a specific action, not just entering a code.
• Treat voice checks as a weak signal, not a final control, because audio can be cloned and replayed.

This is consistent with broader identity guidance in the The State of Secrets in AppSec research, which highlights how often secret handling fails under operational pressure. For authentication design, the practical lesson is that one-time secrets must be paired with context, device binding, and fraud detection. These controls tend to break down in outsourced support environments and high-volume contact centres because attacker scripts exploit speed, repetition, and inconsistent human judgment.

Common Variations and Edge Cases

Tighter verification often increases customer friction and support cost, requiring organisations to balance fraud reduction against conversion, accessibility, and call handling time. That tradeoff becomes sharper in regulated or customer-facing environments where denial of service is also a risk. Current guidance suggests there is no universal standard for this yet, but SMS OTP and voice checks should be reserved for low-risk recovery paths, not privileged or irreversible actions.

There are a few important edge cases. Some organisations still use SMS as a fallback when the primary factor is unavailable, but that fallback should be clearly marked as lower assurance and paired with step-up review. Voice checks can help a help desk confirm identity, but only as one input among several, such as device history, recent behaviour, and transaction scope. For teams mapping controls to mature identity programs, NIST guidance and NHIMG research both point toward reducing dependence on secrets that humans must relay under stress. The practical posture is to assume the attacker may be able to hear, see, or synthesize the verification path in real time.

That is why many programmes are moving toward stronger factors, fraud analytics, and policy decisions that consider the full request context rather than a single passcode. In mixed environments, SMS OTP can still work as a convenience layer, but it should not be the control that stands between an attacker and account takeover when the verification step itself can be machine-assisted.

Related resources from NHI Mgmt Group

• How should security teams replace SMS OTP in AI-heavy fraud environments?
• Why do voice-based identity checks fail against AI-generated impersonation?
• Why do AI-driven fraud attacks create problems for static identity checks?
• Why do static CAPTCHA and keyword blocks fail against SMS toll fraud?