Why do one-time passcodes still fail against modern phishing campaigns?

Why This Matters for Security Teams

One-time passcodes are still widely deployed because they feel familiar, cheap, and easy to add after the fact, but that convenience does not make them phishing-resistant. If an attacker can capture the code in a live session and relay it before expiry, the control fails exactly as designed. That is why modern guidance increasingly favours binding authentication to the authentic session and device, not just to a reusable secret submitted by a human. The issue is visible across broader secrets abuse patterns too, including incidents discussed in the DeepSeek breach research and in the LLMjacking analysis, where attackers move quickly once a credential is exposed. NIST’s NIST Cybersecurity Framework 2.0 reinforces that identity assurance must be matched with effective access validation. In practice, many security teams encounter OTP weakness only after a phishing kit has already replayed the code successfully rather than through intentional testing.

How It Works in Practice

The core limitation of OTPs is that they prove possession of a short-lived code, not that the user is interacting with the genuine service in a genuine context. A phishing proxy can sit between the victim and the real site, capture the code, and immediately forward it. If the service accepts the code without stronger session binding, the attacker inherits the authenticated session.

Modern phishing-resistant designs reduce this gap by tying the authentication event to the channel, device, or cryptographic challenge that generated it. Current guidance suggests several layers:

• Use phishing-resistant authenticators where possible, especially cryptographic sign-in methods that validate the origin of the request.
• Bind the login event to the user’s device or secure hardware so a copied code is not enough on its own.
• Enforce step-up checks for risky actions, not just for initial sign-in.
• Shorten token lifetime and revoke sessions quickly when anomalies appear, because OTP success can still be followed by session hijack.
• Monitor for impossible travel, proxy indicators, and repeated OTP prompts that suggest relay or fatigue attacks.

This is why authentication strategy has to be aligned with access policy and detection, not treated as a one-field login problem. Controls and identity assurance should be reviewed alongside the State of Secrets in AppSec findings, because exposed secrets and weak authentication often reinforce each other in the same attack path. NIST guidance in NIST Cybersecurity Framework 2.0 supports this layered approach, where access decisions are continuously validated rather than assumed from a single factor. These controls tend to break down in remote access environments that rely on legacy VPN flows, because the OTP is validated before the session is truly trusted.

Common Variations and Edge Cases

Tighter authentication often increases user friction and rollout cost, so organisations have to balance phishing resistance against help desk load, device readiness, and business urgency. That tradeoff is real, especially when a workforce includes contractors, BYOD users, and shared operational endpoints.

There is no universal standard for this yet across every environment, but current guidance is clear on one point: OTPs are weakest when used as the only barrier to high-risk access. A few common edge cases matter:

• SMS and email OTPs are especially vulnerable to interception, malware, and adversary-in-the-middle proxies.
• App-based OTPs are stronger than SMS, but they still do not guarantee the authenticity of the requesting session.
• High-value admin workflows need stronger assurance than employee self-service portals.
• Emergency access and break-glass accounts often bypass normal controls, so they need separate monitoring and tighter expiry rules.

For organisations mapping to NIST, the practical next step is to treat OTP as a transitional control, not a destination. Pair it with stronger identity proofing, conditional access, and session protection, then phase toward phishing-resistant methods where the threat model justifies it. That approach is consistent with the risk-based logic in NIST Cybersecurity Framework 2.0 and the observed speed of credential abuse in the DeepSeek breach research. OTP-heavy controls become brittle when adversaries can automate relay, harvest sessions, and pivot before detection has time to respond.

Related resources from NHI Mgmt Group

• Why do Duo OTPs and similar one-time codes still fail against phishing?
• Why do phishing-resistant methods still fail against man-in-the-middle attacks?
• Why do phishing-resistant MFA controls still fail against social engineering?
• Why do static anti-bot controls fail against modern scraping campaigns?