Multi-factor authentication is widely treated as a solved problem: enable it, tick the compliance box, move on. Then an account with MFA enabled gets taken over anyway, and the incident review discovers that every control worked exactly as designed. The user received a genuine prompt, approved it, and handed their session to somebody else.
The uncomfortable truth is that most deployed MFA defends against one specific attack — an adversary who has the password but not the second factor — and offers very little against an adversary who is talking to the user in real time.
Why the second factor stopped being enough
The original threat model was credential stuffing. An attacker held a password from an unrelated breach and replayed it. A second factor broke that cleanly, because knowing the password no longer implied access.
Attackers adapted by moving from replaying credentials to relaying them. If the victim will type a code into a page the attacker controls, or approve a push the attacker triggered, then the second factor is not an obstacle. It is simply another field to collect.
Three techniques dominate:
- Real-time relay. A reverse proxy sits between victim and legitimate site. The victim sees a genuine-looking login, enters credentials and the one-time code, and the proxy forwards each in real time. Critically, what the attacker keeps is the resulting session cookie, which means the authentication has already succeeded and the second factor never needs to be presented again.
- Push fatigue. The attacker holds valid credentials and repeatedly triggers approval prompts, often at night, until the user approves one to stop the noise. It is unsophisticated and it works.
- SIM swap and interception. SMS codes depend on the telephone network, where an attacker who convinces a carrier to port a number receives every code thereafter.
What unites all three is that the factor is portable. Any secret the user can read and repeat can be repeated to the wrong party.
What makes a factor phishing-resistant
A factor is phishing-resistant when it is cryptographically bound to the site requesting it, so it cannot be replayed anywhere else — and when the user has no ability to relay it even if they want to.
FIDO2 and WebAuthn achieve this with public-key cryptography and origin binding. During registration the authenticator generates a key pair for that specific site, keeping the private key on the device and giving the site the public key. At sign-in, the site sends a random challenge; the authenticator signs it and returns the signature.
The essential detail is that the browser includes the origin in the signed data, and the authenticator will only produce a signature for the origin the credential was registered to. A user on a lookalike domain cannot produce a valid assertion, because the authenticator refuses — not because the user noticed the domain was wrong. Human vigilance is removed from the security boundary entirely.
There is no shared secret, so there is nothing on the server worth stealing. A breach of the relying party yields public keys, which are public by definition.
Passkeys, and the trade-off nobody mentions
Passkeys are FIDO2 credentials made usable. The technology underneath is unchanged; what changed is that the credential can be synced across a user’s devices through a platform provider, rather than being locked to one piece of hardware.
This solved the adoption problem that held FIDO2 back for a decade. Device-bound credentials meant losing a phone meant losing access, so deployments needed elaborate recovery, which usually degraded to a weaker fallback that attackers targeted instead. Syncable passkeys make recovery ordinary.
The trade-off is real and worth stating plainly. A synced passkey is only as strong as the account it syncs through. If that platform account is compromised, the passkeys within it may be as well. Device-bound credentials on a hardware security key remain the stronger option for administrative and high-value access, and most serious deployments use both: syncable passkeys for the general population, hardware keys for privileged roles.
Ranking the factors honestly
Not all MFA is equivalent, and treating it as a binary hides most of the risk.
- Hardware-bound FIDO2 keys — phishing-resistant, not syncable, strongest available.
- Synced passkeys — phishing-resistant at the protocol level, with recovery risk inherited from the sync account.
- Platform authenticators using device biometrics with WebAuthn — phishing-resistant where properly implemented.
- Push with number matching — not phishing-resistant, but meaningfully better than plain push because it defeats fatigue attacks.
- Authenticator app codes — defeats credential stuffing, defeats nothing in real-time relay.
- Plain push approval — vulnerable to fatigue.
- SMS and email codes — weakest, though still far better than nothing.
The gap between positions three and four is the one that matters. Everything below it shares a single flaw: the user can be induced to hand it over.
The fallback problem
The most common way a strong deployment fails is that it kept a weak alternative. If a user can click “use another method” and receive an SMS code, the account’s effective security is that of SMS, because that is the path an attacker will choose.
The same applies to recovery. Help-desk reset procedures, backup codes, and security questions are all authentication paths, and each is attacked precisely because it is the weakest. Social engineering of a help desk has repeatedly proven more reliable than any technical attack against the primary factor.
Rolling out phishing-resistant MFA therefore means closing paths as much as opening them. Enrol users on strong factors, then remove the weak ones. Registration of a new authentication method deserves the same scrutiny as the login itself — adding a factor is how an intruder makes access durable.
Relay attacks start with a convincing lookalike domain. Inspect a suspicious link’s structure without contacting the host.
Tokens outlive passwords
Phishing-resistant MFA protects the moment of authentication. It does not protect what is issued afterwards.
Because relay attacks target the session cookie, the adversary’s prize is a token that is already authenticated. Resetting the password does not invalidate it. This is why session revocation must be an explicit step in any account-takeover response, and why token lifetime and binding matter: shorter lifetimes reduce the window, and binding a token to a device or client certificate makes a stolen one useless elsewhere.
Continuous evaluation helps further, re-checking conditions such as location and device compliance during a session rather than only at sign-in, so a token that suddenly appears from a different country stops working.
Deploying it without a revolt
Technically the work is modest. Organisationally it is a change-management exercise, and the sequencing that tends to succeed looks like this:
- Start with administrators. Highest value, smallest population, most technically capable. Hardware keys, no exceptions, no fallback.
- Instrument before enforcing. Report on which factors are actually in use. Most organisations discover a long tail of SMS they believed was retired.
- Enrol before enforcing. Give users a window to register a strong factor while the old one still works.
- Enforce by policy, not by hope. Conditional access requiring phishing-resistant authentication for sensitive applications, rather than a recommendation.
- Close the fallbacks last, once enrolment is high enough that the help desk will not be overwhelmed.
- Fix recovery. Verify identity out of band before resetting a factor. This is where the remaining risk concentrates.
The realistic expectation
Phishing-resistant MFA is one of the few controls that genuinely removes an entire attack class rather than making it marginally harder. Credential phishing — the initial access technique behind an enormous share of intrusions — simply stops working against a properly enrolled account.
It does not stop malware, insider misuse, session theft after authentication, or an attacker who compromises the device itself. It is not a complete answer. But it converts the most common way organisations are breached into a technique that no longer functions, and very little else in security offers that.
The attacks that route around the login page
Once strong authentication is enforced, adversaries stop attacking the login and start attacking the paths that issue tokens without one. Three deserve naming because they defeat phishing-resistant MFA without breaking it.
Device code phishing
The device authorisation flow exists so that input-constrained devices — televisions, CLI tools — can authenticate by asking a user to enter a short code on a second device. An attacker initiates that flow, obtains a legitimate code from the real identity provider, and sends it to the victim with a plausible pretext. The victim authenticates on the genuine provider page, with genuine passkeys, and the tokens are delivered to the attacker who started the flow.
Nothing was spoofed. The user did everything correctly. The defence is policy: restrict the device code flow to the small population that genuinely needs it, and alert on device code authentications from unexpected clients or locations.
Consent phishing
Rather than stealing credentials, the attacker registers an application and asks the user to grant it permissions. The consent screen is genuine. If the user approves, the application holds a token with the granted scopes — mail read, files read — independent of the user’s password or authentication factors. Resetting the password changes nothing, because the application’s access is separate.
Mitigation is administrative: restrict user consent to applications from verified publishers with low-impact permissions, require admin approval for anything broader, and periodically review granted consents.
Token theft from the endpoint
An adversary with code execution on the device can steal session cookies or refresh tokens directly from browser storage. No authentication is involved at all. This is why endpoint security remains foundational, and why token binding — cryptographically tying a token to the device that obtained it — matters as the next control layer.
Hardening enrolment and recovery
With the authentication event itself hardened, the weakest remaining path is how factors are added and reset. Attackers have followed that shift, and help-desk social engineering is now among the most reliably successful techniques against otherwise well-defended organisations.
Practical hardening measures:
- Treat factor registration as privileged. Require existing strong authentication to add a new method, and alert whenever one is registered, particularly soon after a password reset.
- Remove knowledge-based verification from help-desk procedures. Personal details are not secrets.
- Verify out of band for resets — a callback to a number on record, or verification through a manager, rather than trusting the caller’s claims.
- Impose a delay on high-risk changes where business tolerance allows, with notification to the account owner, so an unauthorised change has a chance of being noticed.
- Provision a second strong factor at onboarding, so losing one device does not force a fallback to something weak.
What to monitor once it is deployed
Strong authentication produces its own telemetry, and a handful of events carry disproportionate signal:
- Authentication method registered, changed or deleted.
- Successful sign-in using a weaker factor than policy expects, which usually indicates a fallback path you believed was closed.
- Sign-in from an unfamiliar location immediately after a factor change.
- Device code authentications, and consent grants to new applications.
- Sessions revoked, and sessions that survive a credential reset.
The last one is worth building a specific check around, because it is the artefact that distinguishes a contained account takeover from one that quietly continues.