The UK’s NCSC made the strongest official case for passkeys

The UK's National Cyber Security Centre published a paper this month comparing passkeys and traditional MFA attack by attack, across every stage of a credential's life. The NCSC doesn't move fast and doesn't overstate. So when their conclusion is that passkeys outperform every form of traditional MFA against every attack currently seen in the wild, it lands differently than a vendor whitepaper saying the same thing.

Here's what they found, and what it means for teams building authentication today.

The attacks that actually happen

The paper draws on Microsoft's 2025 Digital Defense Report to rank credential attacks by prevalence:

"Password brute-force and credential stuffing together account for 97% of attacks. Adversary-in-the-middle phishing sits at 0.24%. MFA fatigue attacks at 0.003%."

Weak or reused passwords get tested against breach databases at scale, automated and constant. Any second factor stops that. The 97% is a solved problem for any product requiring MFA.

The 0.24% is a different story. AitM phishing toolkits are actively replacing older credential harvesting approaches because they work against MFA-protected accounts. Low volume, high success rate, and growing. That's where traditional MFA runs out of road.

The problem with every form of traditional MFA

"All traditional MFA is inherently phishable."

SMS OTP, TOTP apps, push notifications, email codes. An attacker who proxies a login session in real time can relay whatever the user types, codes included, before they expire, and walk away with the session cookie. The second factor changes nothing here because both the password and the code are strings the user hands over to whatever site they're looking at.

Fatigue attacks work on the same principle. An attacker with a valid password spams push notification prompts until the user approves one. The NCSC paper cites documented cases. This isn't theoretical.

There's no configuration that fixes this. The vulnerability is in how these credentials work.

Why FIDO2 doesn't have this problem

"FIDO2 authentication is tightly bound to the TLS-authenticated domain. A FIDO2 authentication includes automatic, cryptographically-backed binding by the FIDO authenticator and the user's trusted browser or app."

When a user authenticates with a passkey, the private key never leaves the device. The authenticator signs a challenge bound to the exact domain the browser reports. Point a user at a fake site and the authenticator finds no credential registered for that domain. Nothing gets returned, nothing gets relayed.

The NCSC comparison table marks every form of traditional MFA as "always vulnerable" to AitM phishing, and every FIDO2 credential type as "never vulnerable." The distinction isn't about how hard the attack is to execute. The attack has no surface to work against.

The sync fabric criticism

"Credential managers typically use a sync fabric that will synchronise passwords, passkeys, and TOTP seeds that they store. Codes sent by email are effectively synchronised as the user typically logs into their email account on multiple devices."

The common objection to passkeys is that syncing them via iCloud Keychain or a Google account introduces a new attack surface. Phish the sync account, get the passkeys.

Password managers already sync credentials over those same fabrics, TOTP seeds included. Often the same Apple ID or Google account underpins both. The attack surface exists for traditional MFA too, most people just haven't thought about it in those terms.

The question that actually matters is whether the sync account is protected with phishing-resistant authentication. All three major first-party sync fabrics reviewed by the NCSC in 2025, Apple, Google, and Microsoft, required two-factor authentication and supported passkeys on the account itself. Several third-party credential managers don't enforce MFA on the sync account at all, which is a real gap, but one that applies equally to synced TOTP seeds.

The transition period

"As users adopt passkeys as their default option when accessing accounts, attackers are expected to increasingly conduct downgrade attacks, using an AitM proxy to force the relying party to use a registered non-FIDO2 authentication mechanism that is not phishing-resistant."

Passkeys and passwords coexisting in the same account is the near-term problem. An AitM proxy can push a relying party toward whichever authentication method is weaker. If a password fallback exists, the passkey offers no protection. Removing that fallback is the fix, but it requires confidence in the passkey implementation, working recovery flows, and handled edge cases. Getting there takes time.

The paper also flags an emerging pattern on the other end of a compromise:

"One technique expected to become more common is the registering of passkeys or other FIDO2 credentials by attackers in order to persist access to a victim's account following compromise."

Attackers who get in through a phishable method are starting to register their own passkeys to hold that access. Users need to be able to see what credentials are registered on their accounts and revoke individual ones. Most products don't make this easy today.

Migrating without breaking things

The NCSC's recommendations for relying parties cover supporting FIDO2, deploying Content Security Policy against XSS, and giving users control over registered credentials. The harder part is getting from an existing SMS OTP or TOTP setup to passkeys without locking users out mid-migration.

Authsignal handles this by letting you run both in parallel and using risk signals to decide which flow a user sees. A trusted user on a known device gets prompted to register a passkey. A new device or flagged session gets a stronger challenge. Passkey adoption grows incrementally while the phishable fallback shrinks, rather than flipping a switch and hoping nothing breaks.

Registered passkeys are surfaced per user in the Authsignal dashboard, with revocation available through the management API, which covers the credential visibility gap the NCSC flags.

The full NCSC paper is the place to start if you're making decisions about authentication architecture. If you're looking at what a passkey integration actually involves, head to our docs that covers the implementation side.

‍