OTP alone breaks when attackers can proxy the legitimate login session and harvest the code as the user enters it. In that case, the code proves the user saw a prompt, but it does not prove the request was initiated on the real site. Organisations then lose the assurance they expect from step-up authentication and remain exposed to unauthorized account access and transactions.
Why OTP Fails as a Phishing Defence
OTP codes are still useful as a second factor, but they stop being a reliable phishing defence when the attacker can relay the login flow in real time. The code then verifies only that the user responded to a prompt, not that the session was initiated on the genuine site. That is why OTP can be bypassed without breaking the underlying authentication challenge.
What breaks first is the trust assumption behind the control. Organisations often treat OTP as proof that the user is physically present and interacting with the correct service, but a proxy or adversary-in-the-middle setup preserves the code exchange while substituting the attacker’s session.
This is also why the weakness shows up in NIST SP 800-63 Digital Identity Guidelines style terms: the authenticator may still be valid, but the authentication event is not phishing-resistant. The control authenticates a response, not the origin of the request.
Where the Control Boundary Breaks
The practical failure is not “OTP is useless”, it is that OTP does not bind the login to the legitimate origin, device context, or user intent in a way that survives interception. Once the code is harvested and replayed during the live session, the attacker inherits the authenticated state and can proceed as if they were the user.
That makes the downstream impact broader than login bypass. Email, SaaS, finance, support portals, and admin consoles all inherit the same weakness if their step-up flow still accepts a relay-able code. If the application treats OTP as the main trust gate, the organisation is effectively betting its assurance model on a secret that can be proxied.
For defenders, the deeper issue is session integrity. The attacker does not need to crack the factor, only to capture it before it expires and complete the login fast enough to reuse the same transaction path. MITRE D3FEND is useful here because it helps map this kind of adversary-in-the-middle behaviour to defensive countermeasures rather than to the factor itself: MITRE D3FEND.
What Practitioners Should Trust Instead
The more reliable response is to move from code-based proof to phishing-resistant authentication and to verify that the authentication method is actually bound to the real service session. That usually means prioritising authenticators that resist relay attacks, then tightening session controls so a successful prompt does not automatically become broad account authority.
- Use phishing-resistant sign-in methods for high-value accounts and transaction approval, rather than treating OTP as the end state.
- Reduce the blast radius of any authenticated session by limiting what a newly established session can do immediately.
- Require additional verification for sensitive actions, not just for initial login, when the transaction risk is materially higher.
CIS Controls v8 supports this shift by emphasising account management, access control, and auditability around authentication paths and privileged activity. For implementation detail on resistant login patterns, OWASP Cheat Sheet Series is a useful companion for authentication and session handling guidance.
Practitioner Guidance: If OTP is the only thing standing between a phished user and a valid session, treat the control as an exposure reducer, not a phishing solution. The decision point is whether the organisation can detect and block real-time relay, because if it cannot, the assurance provided by the second factor is materially weaker than most teams assume.
Risk and Threat Considerations
When OTP is the main defence, the main risk is false assurance: the organisation believes it has strong step-up authentication while the attacker can still complete a live relay and inherit the user’s session. That creates a direct path from phishing to account takeover and unauthorised transaction execution.
Failure mechanism: The attacker proxies the login or MFA flow, captures the one-time code as it is entered, and reuses it before expiry to establish an authenticated session on the attacker-controlled side.
Impact: The organisation loses the protection it expected from step-up authentication, and sensitive accounts can be accessed or abused even though the user technically entered a valid OTP.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-63, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | AAL — Authenticator Assurance Levels | OTP relay weakness is about assurance strength, not just factor presence. |
| Recommendation — Use phishing-resistant authenticators for high-value access instead of relying on OTP alone. | ||
| CIS Controls v8 | 6 — Access Control Management | Addresses account and access controls that reduce takeover impact after phishing. |
| Recommendation — Tighten access control and privileged session limits for accounts reachable through phishing. | ||
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication and Access Control | The issue is an authentication control that fails to distinguish real-origin sessions. |
| Recommendation — Strengthen authentication controls so successful sign-in does not overstate trust. | ||
| MITRE ATT&CK | T1556 — Modify Authentication Process | Real-time proxying of OTP fits authentication interception and abuse patterns. |
| Recommendation — Detect and hunt for adversary-in-the-middle activity around authentication workflows. | ||
| OWASP Non-Human Identity Top 10 | NHI-03 — Authentication and Token Security | OTP does not stop token or session abuse when the login is relayed live. |
| Recommendation — Limit session/token reuse paths and prefer stronger authentication binding for sensitive access. | ||
Practitioner Guidance
What to verify: Confirm whether the login method is phishing-resistant or merely OTP-based, and test whether a real-time proxy can still complete the flow. If it can, the control should not be treated as sufficient for high-risk access.
Common mistake: Teams often over-weight “something you have” language and under-weight the fact that many OTP deployments still allow live relay. The important question is not whether the factor exists, but whether it is bound to the genuine origin of the request and the intended session.
Practitioner takeaway: OTP is a speed bump against opportunistic abuse, but it is not a reliable defence when the adversary can sit in the middle of the conversation. The real control objective is to make the authentication event resistant to relay, not merely to make it harder to guess.
Related resources from NHI Mgmt Group
- What breaks when organisations rely on patching as the main defence against AI-driven attacks?
- What breaks when organisations rely on DMARC alone against AI-driven phishing?
- What breaks when organisations rely on phishing awareness alone against DPRK-linked attacks?
- What breaks when organisations rely on user approval as the main control against account takeover?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
