Intermediary attacks defeat ordinary MFA because they exploit the live exchange between the user and the service. Phishing-resistant methods reduce that relay risk by binding authentication to the real origin or device. For sensitive financial accounts, that matters more than the number of factors, because the attacker’s goal is session theft, not password cracking.
How intermediary attacks change the authentication problem
Intermediary attacks such as adversary-in-the-middle phishing and token relay do not try to guess a password or defeat a one-time code by brute force. They sit between the person and the real service during a live sign-in, capture the proof the user just produced, and reuse it before it expires. That means the weakness is the authentication ceremony itself, not simply the factor list.
Once that relay exists, conventional MFA can still be presented to the legitimate service as if nothing went wrong. The decisive question is whether the authenticator is bound to the actual origin, channel, or device in a way that a proxy cannot replay. Passwordless and Passkeys Guide explains why passkeys and security keys change the trust model by tying the proof to the real relying party.
For financial and other high-value accounts, the attacker’s objective is usually session theft and account control, not password cracking. That is why “stronger MFA” is not the same thing as phishing-resistant authentication. A method can still require multiple steps and remain relayable if it does not cryptographically bind the authenticator to the correct origin or device.
What makes phishing-resistant methods different
Phishing-resistant authentication changes the outcome because the credential proof cannot be usefully forwarded to a fake intermediary. In practice, that usually means origin-bound or device-bound authenticators such as passkeys, FIDO2 security keys, or other methods that verify the real service before releasing a usable assertion.
This is also why recovery and fallback paths matter as much as the primary sign-in method. A deployment can be undermined if help desk resets, SMS fallback, or legacy protocols remain available. NHIMG’s MFA Guide compares those weaker paths with phishing-resistant options and shows where attackers still get around otherwise good controls.
The practical test is simple: if an attacker can insert a proxy and the user still completes sign-in successfully, the method is not phishing-resistant enough for the threat you are trying to stop. That is especially important for accounts that can move money, approve transactions, or reach sensitive internal systems.
Why attackers prefer intermediary techniques over password theft
Intermediary attacks are attractive because they exploit the user’s trust in a familiar login page and the service’s trust in a freshly issued session. They often succeed without needing to crack a password, steal a hardware token, or persist long enough to trip basic lockout controls. The real prize is the session cookie, token, or authenticated browser context.
That is why phishing-resistant methods are most valuable where the session itself is the asset. NIST SP 800-63 Digital Identity Guidelines treats phishing resistance as a property of the authenticator and its binding to the verifier, not as a count of factors. For the same reason, NIST’s guidance is more useful than generic “use MFA” advice when the threat is relay or token theft.
In real incidents, the pattern repeats: the attacker either relays the login live, steals a session token, or abuses a fallback path after the initial sign-in. If the control only protects the password step, it misses the part of the attack that actually leads to compromise.
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 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Phishing resistance and authenticator binding are central to this sign-in question. |
| Recommendation — Use phishing-resistant authenticators that bind the proof to the real verifier and device. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | The question concerns how users authenticate under relay and session-theft attack paths. |
| IA-5 — Authenticator Management | Fallbacks, resets, and token handling determine whether the phishing-resistant control holds. | |
| Recommendation — Require stronger authentication for user access where intermediary attacks are likely. Manage authenticators so recovery, rotation, and revocation do not reintroduce relay risk. | ||
| OWASP ASVS | V6 — Authentication | Phishing-resistant login design and session binding are authentication-verification concerns. |
| V7 — Session Management | The attack goal is often session theft after authentication succeeds. | |
| Recommendation — Verify login flows resist relay, replay, and weak fallback authentication paths. Bind sessions tightly and invalidate them quickly when authentication context changes. | ||
Practitioner Guidance
What to prioritise: Treat phishing resistance as a control for session theft and live relaying, not as a branding upgrade for MFA. If the account can trigger payments, approve transfers, or administer high-impact systems, prioritise methods that are bound to the real origin or device and remove weaker fallback paths.
What to verify: Confirm that the sign-in method remains resistant when the user is sent through a fake page, a reverse proxy, or a token relay flow. Also verify that recovery, help desk resets, and legacy authentication do not recreate the same bypass you just removed.
Common mistake: Teams often count factors and stop there. A relayable second factor can still fail against intermediary attacks, so the control decision should be based on replay resistance and binding, not on factor quantity alone.
Practitioner takeaway: If an attacker can interpose themselves during authentication, the control you need is not more prompts, it is an authenticator that cannot be meaningfully replayed through the middle.
Related resources from NHI Mgmt Group
- Why do AI-driven phishing attacks make passwordless authentication more important?
- Why do phishing-resistant authentication methods still fail in real attacks?
- Why does DORA make phishing-resistant authentication a resilience issue?
- What is phishing-resistant authentication and how does it relate to NHI security?