OTP fails because attackers can intercept, relay, or socially engineer the code even when the password is correct. SMS and email OTP are exposed to SIM swapping, phishing, man-in-the-middle attacks, and brute force attempts. Usability problems also create workarounds, which means the control can weaken both security and user behaviour over time.
Why This Matters for Security Teams
OTP-based login often looks strong on paper because it adds a second step, but the real-world threat model is weaker than many teams assume. Once the code can be captured, relayed, guessed, or socially engineered, the control no longer meaningfully proves the user is legitimate. NIST Cybersecurity Framework 2.0 treats identity assurance as part of a broader risk program, not as a single checkpoint, which is why OTP should be viewed as one layer rather than a boundary. NHIMG’s The State of Secrets in AppSec shows how confidence often outpaces actual control quality, a pattern that also shows up in login design.
The operational problem is that attackers do not need to defeat OTP cryptography if they can manipulate the human or the channel carrying the code. SMS forwarding, phishing kits with live proxying, inbox compromise, and help desk abuse all let an adversary complete a valid login while the organisation still believes the factor worked as intended. In practice, many security teams discover OTP weakness only after account takeover has already occurred, rather than through intentional testing.
How It Works in Practice
OTP fails in production because the control verifies possession of a code, not the trustworthiness of the session, device, or request. A code sent by SMS or email is only as strong as the delivery path. If an attacker can intercept the message, relay it in real time, or coerce the user into reading it aloud, the login still succeeds. That is why guidance from NIST and modern phishing-resistant authentication frameworks increasingly favours stronger authenticators and context-aware access decisions.
In practice, teams should separate the mechanism from the outcome. A login flow may need:
- Phishing-resistant factors for higher-risk users and privileged actions, not only OTP.
- Device and session signals, such as known device binding and impossible-travel checks.
- Step-up authentication only when risk changes, rather than every session relying on the same OTP path.
- Recovery processes that are as strong as the login flow, because attackers frequently target account recovery instead of the OTP itself.
For organisations handling secrets, tokens, or administrative access, this matters even more. Compromise of one account can expose systems that were assumed to be protected by a second factor, and once an attacker gets in, they often move laterally using existing trust. NHIMG’s Schneider Electric credentials breach underscores how credential abuse becomes a broader access problem, not just a login problem. NIST CSF 2.0 remains a useful anchor for treating authentication as one control inside a larger detect-and-respond process, while phishing-resistant approaches described in the NIST Cybersecurity Framework 2.0 help teams move beyond code-based verification. These controls tend to break down when legacy SMS OTP is still allowed for privileged accounts because the delivery channel is the weak point.
Common Variations and Edge Cases
Tighter authentication often increases friction, requiring organisations to balance login convenience against lower takeover risk. That tradeoff becomes especially visible in customer-facing systems, remote work environments, and regions where SMS delivery is inconsistent. Current guidance suggests OTP can still have a place for low-risk account recovery or low-impact consumer access, but there is no universal standard for treating it as sufficient for privileged or high-value accounts.
Edge cases usually involve the surrounding process rather than the OTP algorithm itself. Email OTP can fail when the mailbox is already compromised. SMS OTP can fail through SIM swap, number porting, or telecom interception. App-based OTP is better than SMS in many cases, but it still remains phishing-replayable unless paired with stronger phishing-resistant controls. For high-risk environments, the better question is not whether OTP works in theory, but whether it can withstand live adversaries who control the browser, the call centre, or the recovery workflow. That is why teams should compare authentication policy against the actual account value, not the generic user population.
Related resources from NHI Mgmt Group
- Why do password managers still fail to stop account takeover in real environments?
- Why do traditional MFA flows still fail in high-risk identity environments?
- Why do OTP-based login flows fail in regulated financial services?
- Why do passwords and OTP-based MFA still fail against modern identity attacks in regulated environments?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
