Passkeys outperform traditional MFA against live phishing attacks

At a glance

What this is: This is an analysis of the UK NCSC’s comparison of passkeys and traditional MFA, finding that passkeys resist phishing and relay attacks that still defeat SMS OTP, TOTP, push, and email-based factors.

Why it matters: It matters because IAM teams still relying on traditional MFA are protecting against the wrong attack model, while passkeys change both authentication assurance and recovery design across human identity programmes.

By the numbers:

• Password brute-force and credential stuffing together account for 97% of attacks.
• 0.24%.
• 0.003%.

👉 Read Authsignal's analysis of why passkeys outperform traditional MFA

Context

Passkeys matter because the dominant attack path in consumer and workforce authentication is still credential abuse, not cryptographic failure. The UK NCSC’s comparison matters precisely because it evaluates passkeys against real attack classes rather than theoretical preference, which is the right lens for human identity and access management.

Traditional MFA closes off password-only compromise, but it does not eliminate relay-based phishing, prompt bombing, or token theft. For practitioners, the real question is whether the authentication method is phishing-resistant at the point of login and resilient during account recovery, sync, and fallback handling.

Key questions

Q: How should organisations implement passkeys without breaking account recovery?

A: Start with a phased migration that keeps recovery usable but controlled. Enrol passkeys for trusted users first, retain a tightly governed fallback for exceptional cases, and verify that help-desk reset, device loss, and credential revocation paths are phish-resistant or at least strongly authenticated. Recovery design is where many deployments fail.

Q: Why do traditional MFA methods still fail against phishing?

A: Because they still rely on user-entered secrets or approvals that can be relayed in real time. An attacker proxying the session can collect the code, approval, or token and reuse the authenticated result. The weakness is structural, not just operational, so adding more prompts rarely changes the outcome.

Q: What do security teams get wrong about passkey migration?

A: They focus on the login factor and ignore fallback, sync, and revocation. If passwords remain available, if synced credential stores are weak, or if registered passkeys cannot be reviewed and removed easily, the attack surface simply moves. Migration only reduces risk when the whole credential lifecycle is governed.

Q: Who is accountable when a phishable MFA flow is still allowed?

A: The identity and application owners share accountability, because the decision to keep a phishable fallback is a governance choice, not a technical accident. Access design, recovery policy, and risk acceptance should be documented together so that business owners understand what exposure they are preserving.

Technical breakdown

Why traditional MFA remains phishable

SMS one-time passwords, authenticator codes, push prompts, and email codes all depend on a user entering or approving a shared secret in response to a live challenge. In an adversary-in-the-middle attack, the attacker proxies the session, relays the user’s input in real time, and captures the resulting session cookie. The method is not broken by weakness in the code itself. It is broken by a design that accepts user-presented strings as proof of origin.

Practical implication: Treat any MFA flow that can be relayed in real time as insufficient against phishing and session hijack risk.

How passkeys change the authentication trust model

Passkeys use FIDO2 credentials bound to the TLS-authenticated domain and signed by a local authenticator. The private key never leaves the device, and the browser or app provides the domain context the authenticator verifies before returning a signature. A fake site cannot elicit a valid credential for the wrong origin, which removes the relay surface that traditional MFA leaves open.

Practical implication: Prioritise phishing-resistant authentication for accounts where credential theft or takeover would have material impact.

Why sync and fallback paths matter during migration

Passkey adoption is not only a credential-format change. The security outcome depends on the sync fabric, recovery process, and whether weaker fallback methods remain available. If a password, SMS OTP, or phishable recovery path still exists, attackers can force downgrade behaviour or regain access after a compromise. Governance must therefore track the whole authentication journey, not just the primary factor.

Practical implication: Review sync accounts, recovery flows, and fallback methods before claiming a passkey rollout has reduced attack surface.

Threat narrative

Attacker objective: The attacker wants durable account access that survives the initial login event and bypasses factor-based defences.

1. Entry occurs when an attacker runs an adversary-in-the-middle phishing flow or prompt-bombing campaign against a target account.
2. Credential access follows when the victim enters a password or approves a traditional MFA challenge, allowing the attacker to relay the session and capture the authenticated cookie.
3. Impact occurs when the attacker reuses the session to access the account, and in transition states may register a new passkey to persist access.

Breaches seen in the wild

• MITRE ATT&CK Enterprise Matrix — MITRE ATT&CK Enterprise — adversary tactics and techniques, threat detection, attack chain mapping, credential access, lateral movement, privilege escalation.
• Gladinet Hard-Coded Keys RCE Exploitation — Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Traditional MFA is now a relay-friendly control, not a phishing-resistant one. SMS OTP, TOTP, push prompts, and email codes all fail the same way when an attacker can proxy the live session. The NCSC’s conclusion aligns with OWASP-NHI thinking for human identity because the control problem is not whether a second factor exists, but whether that factor resists origin spoofing and relay. Practitioners should treat phishability as the relevant design criterion, not factor count.

Passkeys expose a wider identity governance issue than login security alone. Authentication controls cannot be judged in isolation from recovery, sync, and fallback paths. If password reset, device enrolment, or synced credential stores remain weak, the programme still inherits the same attack surface through a different door. IAM teams should assess the complete authentication lifecycle, not just the happy path.

Identity assurance fails when the control assumes users will always approve the right prompt. That assumption was designed for human-paced interaction with a stable approval moment. It fails when attackers can manipulate the prompt in real time or coerce repetitive approvals, because the approval itself becomes part of the exploit. The implication is that assurance models need to measure resistance to relay and coercion, not just possession and usability.

Synced credential ecosystems create shared trust debt across passwords, passkeys, and TOTP seeds. The article’s sync discussion shows that organisations already rely on underlying account security for multiple credential types, often without recognising the common dependency. That means the governance discussion is not passkeys versus sync, but whether the sync account is itself protected with phishing-resistant authentication. Teams should map that trust chain explicitly.

Passkey adoption will reweight the authentication market toward lifecycle governance. Once login becomes harder to phish, the differentiator shifts to credential visibility, revocation, recovery, and downgrade control. That is a human IAM problem with direct overlap into PAM-style control over high-risk accounts. Practitioners should prepare for more scrutiny of how credentials are registered, surfaced, and revoked.

From our research:

• 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, including 38% with no or low visibility and 47% with only partial visibility.
• Passkey migration should be paired with control visibility work, and Top 10 NHI Issues is a useful companion for understanding how identity blind spots accumulate across programmes.

What this signals

Passkey adoption will expose the weakest parts of the authentication stack faster than MFA ever did. Once phishing-resistant login becomes common, organisations will discover that recovery, sync, help-desk reset, and fallback policy are the real control points. Teams should expect a sharper audit focus on who can re-enrol credentials and under what assurance level, especially for privileged users.

Credential lifecycle control is now part of human identity resilience. Even in a passkey-first model, identity programmes will fail if credential registration, revocation, and fallback management are not observable. The programme signal to watch is whether a user can add, remove, or lose a credential without a corresponding governance event.

Passkeys do not remove identity risk, they reallocate it. The risk moves away from factor interception and toward lifecycle governance, sync trust, and account recovery. That makes human IAM teams, IGA teams, and PAM teams accountable for the same credential journey from enrolment to revocation.

For practitioners

• Prioritise phishing-resistant authentication for high-value accounts Move critical users and privileged administrators to passkeys first, then remove or tightly constrain password, SMS OTP, and push-based fallback paths for those accounts. Use the highest-risk roles to prove the migration model before broad rollout.
• Review the entire authentication lifecycle, not just the primary factor Map enrolment, sync, recovery, credential revocation, and help-desk reset flows as part of the control surface. A passkey deployment that leaves weak recovery intact still permits takeover through the back door.
• Harden sync accounts and credential managers Require phishing-resistant authentication on the account that protects synced passwords, passkeys, and TOTP seeds. Where third-party managers do not enforce strong authentication on the sync account, treat that as a governance gap.
• Eliminate downgrade paths where passkeys are available Track when applications silently fall back to phishable methods and remove those options where business risk justifies it. If a weaker path must remain, make it explicit, monitored, and limited to defined recovery cases.

Key takeaways

• Passkeys change the attack model by removing the relay surface that lets phishers reuse traditional MFA in real time.
• The evidence points to a clear gap in legacy MFA, with the overwhelming majority of attacks still driven by credential abuse while phishing-resistant methods close the door.
• The practical issue is lifecycle control, because migration only works when recovery, sync, downgrade paths, and revocation are governed end to end.

Key terms

• Passkey: A passkey is a phishing-resistant credential that uses public key cryptography to prove identity without sending a shared secret to the server. In practice, the private key stays on the user’s device or in a secure sync fabric, and the authenticator signs only for the intended domain.
• Adversary-in-the-middle Phishing: Adversary-in-the-middle phishing is a live relay attack where the attacker sits between the user and the genuine service. The attacker forwards logins in real time, capturing credentials, codes, or cookies while the victim believes they are signing into the real site.
• Downgrade Attack: A downgrade attack forces a system to use a weaker authentication method than the one it can support. In identity programmes, this often means pushing users from passkeys to passwords, SMS codes, or other phishable flows that preserve a larger attack surface.
• Credential Sync Fabric: A credential sync fabric is the account and storage layer that synchronises passwords, passkeys, and authentication seeds across devices. It is not automatically insecure, but it becomes a shared trust point that must itself be protected with strong authentication and tight governance.

What's in the full article

Authsignal's full article covers the implementation detail this post intentionally leaves for the source:

• Passkey rollout guidance that shows how Authsignal handles parallel MFA and passkey flows during migration
• Operational detail on risk-based prompting, including when a trusted device should trigger passkey enrolment
• Dashboard and management API examples for reviewing and revoking registered passkeys at user level
• Implementation notes for keeping stronger authentication in place while phishable fallback methods are phased out

👉 The full Authsignal post covers migration handling, sync-account considerations, and credential revocation detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or programme maturity, it is worth exploring.