Passkeys outperform traditional MFA against live phishing attacks

At a glance

What this is: This is Authsignal's summary of an NCSC paper arguing that passkeys defeat live phishing patterns that remain viable against traditional MFA, especially adversary-in-the-middle attacks and session theft.

Why it matters: For IAM teams, the finding shifts the authentication question from adding a second factor to removing phishable fallback paths and prioritising phishing-resistant controls.

By the numbers:

• Password brute-force and credential stuffing together account for 97% of attacks, according to the NCSC paper cited by Authsignal.
• Adversary-in-the-middle phishing sits at 0.24% of attacks, according to the NCSC paper cited by Authsignal.
• MFA fatigue attacks account for 0.003% of attacks, according to the NCSC paper cited by Authsignal.

Context

Passkeys are a phishing-resistant authentication method built on public-key cryptography, where the private key stays on the user's device and the authenticator binds the login to the real domain. The security question in this article is not whether MFA exists, but whether the factor can be relayed, proxied, or socially engineered in real time.

For identity programmes, the gap is between phishing-resistant authentication and traditional MFA patterns such as SMS OTP, TOTP, push approval, and email codes. The article argues that as long as a phishable fallback remains available, attackers can keep using real-time relay, downgrade, or fatigue tactics to reach the session.

The policy implication is straightforward: authentication architecture has to be judged by whether it resists live interception, not by whether it adds an extra prompt. That is why this article is better read as a control-design problem than as a product comparison.

Key questions

Q: What should teams do first when traditional MFA is still their default login control?

A: Start by identifying where the organisation still depends on phishable factors such as SMS OTP, TOTP, push approval, or email codes. Then prioritise the accounts and applications where a single compromised session would create the largest operational or financial impact. The first move is to reduce reliance on fallback paths, not to add more prompts.

Q: Why do passwordless methods reduce phishing risk more than traditional MFA?

A: Passwordless reduces phishing risk because it removes the reusable password that attackers most often steal or replay. When implemented with device-bound cryptographic credentials or hardware-backed keys, the credential is harder to capture and reuse remotely. That does not eliminate risk, but it narrows the attack path significantly.

Q: What signs show that an authentication programme is not truly phishing resistant?

A: Look for shared secrets, OTP dependence, push fatigue risks, and exceptions for privileged users. If the strongest methods are not required on the most sensitive paths, the programme is likely describing resilience it does not actually enforce.

Q: Should organisations replace traditional MFA with passkeys and adaptive controls?

A: For most programmes, yes for the primary path and no for everything else. Passkeys should become the preferred method where device support allows it, while adaptive controls decide when extra checks are needed. Traditional MFA can remain as fallback, but it should no longer be the default for every login.

Technical breakdown

Why traditional MFA remains phishable in real time

Traditional MFA improves account security against password guessing and reuse, but many implementations still rely on user-entered secrets or approval prompts that can be relayed through a proxy. In an adversary-in-the-middle attack, the attacker sits between the user and the real site, captures the password and second factor, and forwards both before they expire. Push fatigue works differently but lands in the same place: it coerces a valid approval from the user. The core weakness is that the factor is not cryptographically bound to the legitimate relying party.

Practical implication: Treat any authentication method that can be proxied or relayed as phishing-exposed, even when it satisfies MFA policy.

How FIDO2 binds authentication to the real domain

FIDO2 and passkeys use public-key cryptography so the private key never leaves the authenticator. During login, the authenticator signs a challenge that is bound to the TLS-authenticated domain reported by the browser or app, which means a fake domain cannot elicit a valid credential response. That removes the relay path that phishing kits depend on. The result is not stronger user behaviour, but a different trust model: the credential only works for the intended relying party, which is why the attack surface is structurally smaller.

Practical implication: Prefer domain-bound authenticators where the credential cannot be reused at an attacker-controlled endpoint.

Why sync and fallback design matter during passkey migration

The practical migration issue is not passkeys alone, but how they are stored, synced, and supported alongside older methods. If a password or OTP fallback remains available, an attacker can try downgrade paths and force the user onto the weaker method. Sync fabric also matters because synced credentials inherit the security of the account that stores them. That makes recovery, visibility, and revocation part of the authentication design, not afterthoughts. A passkey deployment can still fail if the surrounding account lifecycle remains phishable.

Practical implication: Map every fallback and recovery path before you treat passkeys as the primary control.

Threat narrative

Attacker objective: The attacker wants durable access to a victim account while bypassing the protections that traditional MFA was expected to provide.

1. Entry occurs through phishing or credential stuffing, with adversary-in-the-middle tooling increasingly used to defeat traditional MFA in real time.
2. The attacker relays the user's password and second factor through a fake login flow, or uses push fatigue to obtain an approval, then captures the live session.
3. Impact is account takeover with a valid session cookie, followed by persistence if the attacker registers new credentials or other recovery methods.

Breaches seen in the wild

• Microsoft Midnight Blizzard breach: Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.
• SonicWall SSL VPN account compromises 2025: Attackers used valid credentials to log in to more than 100 SonicWall SSL VPN accounts across 16 environments in October 2025.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Phishability, not factor count, is the real authentication boundary: The article reinforces a problem we see repeatedly in identity programmes, where teams confuse added friction with stronger assurance. Traditional MFA can still be relayed, proxied, or coerced, so the meaningful control question is whether the credential can be replayed against an attacker-controlled endpoint. Practitioners should treat phishable second factors as a design limitation, not an implementation detail.

Passkeys expose the false comfort of fallback authentication: A passkey deployment is only as resistant as the weakest allowed path into the account. If password fallback, OTP fallback, or weak recovery remains active, the system still contains a route that bypasses the phishing-resistant control. The governance lesson is that authentication strength is determined by the whole decision tree, not by the best option on the menu.

Credential binding is the decisive concept, not MFA branding: The article's strongest point is that FIDO2 changes the trust model by binding the credential to the real domain and the real authenticator. That is a control-property shift, not a branding upgrade. For practitioners, the category to watch is phishing resistance, because the old MFA label now hides too much risk.

Authentication migration is a lifecycle problem, not a feature rollout: The sync fabric, recovery path, and credential visibility questions in this article show that account takeover resistance depends on governance across issuance, storage, revocation, and user recovery. That makes passkey adoption part of identity lifecycle management, not a one-time enablement task. Teams that ignore lifecycle controls will preserve the same attack surface under a newer label.

From our research library:

• eBay's passkey data shows 55-60% of passkey adoption happens on mobile, against around 20% on desktop.

What this signals

Phishing resistance becomes the design target: Teams should stop measuring authentication success by the number of factors and start measuring whether a login flow can be relayed through a fake endpoint. That shift changes architecture, recovery design, and user support all at once.

Fallback paths are now the weak link: Passkeys only improve assurance when password, OTP, and push-based alternatives are constrained enough that attackers cannot simply route users into them. Governance has to cover the whole authentication decision tree, not just the preferred method.

For practitioners

• Prioritise phishing-resistant authentication Move high-risk and externally exposed applications toward passkeys or other phishing-resistant authenticators before expanding low-assurance MFA methods. Focus first on the accounts where live interception would create the largest blast radius.
• Remove phishable fallback paths Review password, SMS OTP, TOTP, push approval, and email-code fallbacks so a user cannot be silently downgraded to a weaker path after passkey adoption begins.
• Harden sync-account protections Treat the account that stores or syncs credentials as a high-value identity and require phishing-resistant authentication on that account as well.
• Surface and revoke registered credentials Expose all registered authenticators per user and make revocation of individual passkeys or other recovery methods operationally simple for support and administrators.

Key takeaways

• Traditional MFA still leaves a phishable surface when attackers can relay or coerce credentials in real time.
• Passkeys change the control model by binding authentication to the real domain and the trusted device.
• Identity teams should treat fallback and recovery paths as part of authentication assurance, not separate support mechanics.

Key terms

• Passkey: A passkey is a passwordless credential based on public key cryptography. A private key stays on the user’s device, while a public key is stored by the service. During login, the device signs a challenge after local unlock, which reduces phishing and eliminates shared secret reuse.
• Traditional MFA: A multi-factor login design that still starts with a password and adds another factor such as a code, push approval, or biometric check. It improves security compared with password-only access, but it still inherits the weakness of the first factor when the password remains in the flow.
• Adversary-in-the-middle phishing: A phishing method that places an attacker between the user and the real identity provider so the attacker can intercept or relay the authenticated session. It often preserves the user experience, which is why it can evade awareness and some detection paths while still producing usable session tokens.
• Fallback authentication: Fallback authentication is the secondary method used when the primary sign-in factor is unavailable. For passkey deployments, fallback must be tightly governed because it often becomes the attacker’s preferred route if it remains easier to abuse than the main login path.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.