They fail when attackers can control the entire login flow and capture both the primary credential and the second factor in sequence. A code proves that the user entered a code, not that the session was genuine. Phishing-resistant authentication reduces this gap by binding the authentication event to the real origin and device.
Why This Matters for Security Teams
Duo OTPs and similar one-time codes still matter, but they are not phishing-resistant because the code can be replayed inside an attacker-controlled session. The control proves possession of a second factor at a moment in time, not that the browser, origin, or device is genuine. NIST now treats phishing-resistant MFA as a distinct requirement, and the NIST Cybersecurity Framework 2.0 reinforces stronger identity assurance as part of modern risk reduction.
This distinction becomes more urgent in environments where credentials are reused across SaaS, cloud, and admin portals. Once an attacker lands the primary password, the OTP often becomes just another prompt in the same fake workflow. NHI Management Group research on the DeepSeek breach shows how quickly exposed secrets and credentials can be operationalized, which is the same basic pattern behind phishing chains: capture, relay, and abuse before defenders can react. In practice, many security teams discover OTP weakness only after a real login session has already been hijacked, rather than through intentional testing.
How It Works in Practice
Phishing succeeds against OTPs when the attacker proxies the login in real time. The user enters the password and the one-time code into a convincing fake page, and the attacker immediately forwards both to the legitimate service. If the session is accepted, the attacker receives a valid authenticated session cookie or token, which is far more valuable than the code itself.
That is why current guidance increasingly favors phishing-resistant methods such as FIDO2/WebAuthn, device-bound cryptographic assertions, or other authenticators that bind the response to the real origin. The authentication event is no longer just “did the user type the right code,” but “did this device prove possession of the right key for this exact site.” For that reason, programs should align identity controls with session risk, not just step-up prompts. NHI Management Group’s research on the Schneider Electric credentials breach illustrates how credential exposure can cascade when attackers can move from one captured secret to another.
- Prefer phishing-resistant MFA for privileged accounts, admins, and high-risk SaaS access.
- Use conditional access to evaluate device trust, origin, and session context at login time.
- Reduce reliance on OTP for recovery paths, because recovery flows are common attack targets.
- Shorten token lifetime and require reauthentication for sensitive actions.
These controls tend to break down in legacy applications that only support shared secrets or push-based MFA without origin binding, because the application cannot verify what the user is actually authenticating to.
Common Variations and Edge Cases
Tighter authentication often increases friction, so organisations have to balance phishing resistance against user support load and application compatibility. There is no universal standard for every legacy stack yet, which means some environments still use OTP as a transitional control rather than a final answer.
One common edge case is push fatigue or OTP relay through an adversary-in-the-middle kit: the second factor works exactly as designed, but it is being used inside a malicious transaction. Another is help desk recovery, where weaker identity proofing can undo strong primary authentication. Best practice is evolving toward layered controls that combine phishing-resistant MFA, device posture, and transaction verification for sensitive actions, especially in admin and finance workflows. The challenge is not that OTP is useless, but that it is insufficient once an attacker can control the whole login journey.
Where environments rely on shared terminals, outsourced support, or older SSO integrations, the risk rises further because session theft and account takeover become easier to operationalize before detection or revocation can occur.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Phishing-proof identity depends on how the NHI is authenticated and bound to origin. |
| NIST CSF 2.0 | PR.AC-7 | Strong authentication and least privilege reduce the impact of session hijacking. |
| NIST AI RMF | GOVERN | Identity assurance for automated and digital workflows needs governance and accountability. |
Define authentication risk ownership and review identity controls as part of AI and system governance.
