They fail because the attacker can bypass the method rather than break it. Passwords, OTPs and similar controls often authenticate the user without strong binding to the device, app origin or platform context, so phishing and real-time relay can reuse valid credentials inside an adversary-controlled flow.
Why phishing wins against many “strong” sign-in methods
Phishing succeeds when the method proves something the attacker can reuse, not something the defender can bind tightly enough to the real sign-in context. OTPs, SMS codes, push approvals and some legacy MFA flows may confirm that a user responded, but they do not always prove that the response came from the intended device, site, app or trusted browser session.
That gap matters because modern phishing kits do not need to “break” the control. They can proxy the login, capture the user’s interaction in real time, and forward it to the legitimate service before the code or challenge expires. The user experiences a normal sign-in, while the attacker receives a valid authentication result inside their own flow.
When the control is not phishing-resistant, the security decision is based too heavily on a shared secret or a one-time event. For practical comparison of method strength, rollout trade-offs and bypass patterns, see MFA Guide and Passwordless and Passkeys Guide.
What relay attacks exploit that ordinary OTPs do not stop
Relay attacks work by sitting between the victim and the real identity provider, then relaying the challenge and response in near real time. The attacker does not have to predict the OTP or crack the authenticator. They only need the user to complete the step while the session, token exchange or approval is still live.
This is why methods that depend on a transferable code, a push approval or a browser session with weak binding fail under active man-in-the-middle conditions. The attacker can keep the authentication ceremony intact while substituting their own endpoints, which makes the result look legitimate to the service.
Binding matters more than ceremony. A method becomes much harder to relay when the proof is tied to the authenticating device, the origin, and the transaction context, not just to a password plus second factor. That is the practical reason passkeys and other phishing-resistant authenticators are treated differently from generic MFA in modern guidance.
For the underlying assurance model, authenticator properties, and phishing-resistant requirements, consult NIST SP 800-63 Digital Identity Guidelines.
What actually works better in practice
The controls that outperform phishing and relay attacks are the ones that remove credential replay and strengthen origin binding. In practice, that means phishing-resistant MFA, passkeys, hardware-backed authenticators, and sign-in flows that verify the relying party rather than just a code entered by the user. Session hardening and reauthentication rules also matter when an attacker may pivot from login to token theft.
It is also important to treat recovery paths as part of the authentication system. Help desk resets, fallback factors, enrollment rebinds and legacy SSO exceptions often become the easiest path around a strong primary factor. If those paths are weaker than the primary sign-in, the attacker targets the exception instead of the control.
Real incident patterns show the same lesson: the weakest part is often the reusable credential, the relay-able approval, or the recovery process. Examples such as Twilio 0ktapus breach 2022 and CitrixBleed exploitation 2023 show how phishers and attackers prefer flows that let them reuse or steal a valid result rather than defeat the factor cryptographically.
Risk and Threat Considerations
Phishing and relay attacks turn authentication into a trust-boundary problem. If the factor can be forwarded, replayed or approved in the wrong context, the attacker can obtain a valid session without needing to defeat the user’s password policy or brute-force the authenticator itself.
Failure mechanism: The attacker captures or intermediates the authentication ceremony, then reuses the live response, token or session cookie before the service can distinguish the real origin from the attacker-controlled one.
Impact: Account takeover, session hijack, unauthorized access to internal tools and downstream abuse of trusted access paths can follow, especially where the compromised session inherits broad privileges or durable tokens.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST SP 800-53 Rev 5, OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Defines phishing-resistant authentication and authenticator assurance for this login weakness. |
| Recommendation — Adopt phishing-resistant authenticators and bind sign-in to the correct relying party. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Covers lifecycle weaknesses of reusable OTPs, tokens and fallback authenticators. |
| Recommendation — Rotate, revoke and tightly govern authenticators and recovery credentials. | ||
| OWASP ASVS | V6 — Authentication | Directly addresses authentication strength, MFA flows and resistance to replay. |
| Recommendation — Verify that authentication flows resist phishing, replay and proxying. | ||
| CIS Controls v8 | 5 — Account Management | Covers account recovery, provisioning and access paths attackers abuse after phish. |
| Recommendation — Harden account recovery and remove weak legacy access paths. | ||
Practitioner Guidance
What to prioritise: Prioritise controls that bind authentication to the authentic device and origin, then remove or downgrade methods that can be relayed with a live proxy. If a method can be captured by a phishing kit and replayed within the login window, treat it as vulnerable by design rather than “secure but occasionally abused”.
What to verify: Verify that your strongest authentication path is also your strongest recovery path. Check whether help desk resets, step-up exceptions, legacy protocols and enrollment workflows still allow a weaker relay-able factor to re-enter the account lifecycle.
Practitioner takeaway: The real test is not whether a user entered a second factor, it is whether that factor is cryptographically and contextually bound tightly enough that an attacker cannot reuse it in their own session.