MFA that actually resists phishing

MFA is the highest-value control most organisations can deploy. It is also routinely defeated, because “we have MFA” says nothing about which kind, and the gap between the weakest and strongest methods in common use is enormous.

The methods, ranked

Strongest: phishing-resistant

FIDO2 security keys and passkeys. The credential is cryptographically bound to the real site’s domain. Presented with examplebank-secure.com instead of the real domain, the key does not produce a wrong answer. It produces no answer. There is no code to read out, no prompt to approve, and nothing a convincing phone call can extract. This is the only category that genuinely resists phishing.

Passkeys are the same underlying standard, synced through a platform account or password manager rather than living on a physical key. Slightly weaker against account-recovery attacks, dramatically easier to roll out, and that trade usually favours passkeys for staff, hardware keys for administrators.

Certificate-based authentication. Common in government and large enterprise, equally phishing-resistant, considerably more to operate.

Middling: better than nothing, but defeated by a determined attacker

Authenticator apps with number matching. The user matches a number shown by the site against their app. Meaningfully better than a plain approve prompt, and it does defeat MFA fatigue, but a real-time relay attack still works, because the attacker’s proxy shows the victim the correct number.

TOTP codes (six digits from an app). No push prompt to spam, but the code is a secret a human can be persuaded to read aloud, type into a lookalike site, or relay to a caller. Phishing kits automate this by default.

Weakest: in common use, routinely bypassed

Push approval with no number matching. Vulnerable to MFA fatigue: send approval requests at 3am until someone taps accept to make it stop. This has been the entry point for several very large breaches.

SMS one-time codes. Interceptable by SIM swap, a social-engineering attack on the telco, entirely outside your control, and phishable like any other code. Better than a password alone, and it should not be the thing guarding an admin account.

Email one-time codes. Reduce to the security of the email account, which is usually the account you were trying to protect.

Security questions. Not a factor. Your mother’s maiden name is public information.

The attack MFA does not stop

Session cookie theft. Once you have authenticated, the site issues a session token. Infostealer malware takes that token from the browser, and the attacker replays it. They are now logged in as you, having never touched the login page, so MFA is never invoked, no matter how strong it is.

This is now a dominant route into corporate email. What helps:

• Shorter session lifetimes for high-value applications, and forced reauthentication for sensitive actions
• Token binding / device-bound sessions where your identity provider supports it
• Conditional access on device compliance, so an unmanaged machine cannot replay a token at all
• Revoke all sessions on password reset. Most platforms do not do this by default, and a reset without revocation changes nothing for an attacker already inside

Real-time relay phishing. A proxy site sits between the victim and the real login page, passing credentials and codes through in real time and capturing the resulting session. This defeats every code-based method. It does not defeat FIDO2, because the domain check fails at the key.

Where to deploy first

Not everywhere at once. In this order:

1. Email, especially anyone in finance or executive support. Email is the password reset channel for everything else, which makes it the master key.
2. Remote access: VPN, and any externally reachable RDP or management interface.
3. Administrative accounts, for every system. Hardware keys here, not SMS. ASD’s Essential Eight expects privileged access to be protected by phishing-resistant methods at higher maturity levels.
4. Financial systems and payment approvals: pair with the callback rule in business email compromise.
5. Anything holding personal information, since the consequence of failure may be a notifiable data breach.
6. Everything else.

Making it stick

• Register two factors per user. A single lost phone becoming a helpdesk emergency is how organisations end up with weak bypass processes.
• Fix account recovery. It is the most commonly attacked path, because it is designed to work when the user has lost everything. If your helpdesk can reset MFA on the strength of a phone call and a date of birth, your MFA is as strong as that phone call. Require video verification or in-person identification for privileged accounts.
• Retire the legacy protocols that bypass MFA entirely: IMAP, POP, SMTP AUTH and other basic-auth endpoints. MFA on the web login is irrelevant if the old protocol is still listening.
• Watch for “temporarily disabled” exceptions. They are never temporary. Give every exception an expiry date and review it.
• Do not let MFA justify a weak password policy. They are independent layers, and one will occasionally fail.

The short version

If you do one thing: put phishing-resistant MFA on email, VPN and every administrative account, and shorten session lifetimes so a stolen cookie expires before it is useful. That combination closes the two routes behind most of the incidents on this site.