Notifications
Clear all
Topic starter
10/07/2026 9:22 pm
TL;DR: The UK NCSC compared passkeys with traditional MFA attack by attack and concluded that passkeys outperform every form of traditional MFA against the attacks currently seen in the wild, especially adversary-in-the-middle phishing and session theft, according to Authsignal's summary of the paper. The practical shift is that authentication design now needs phishing-resistant controls, not just an added factor.
NHIMG editorial — based on content published by Authsignal: The UK’s NCSC made the strongest official case for passkeys
By the numbers:
- 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%.
Questions worth separating out
Q: How should organisations implement passkeys without breaking account recovery?
A: Start with a phased migration that keeps recovery usable but controlled.
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.
Q: What do security teams get wrong about passkey migration?
A: They focus on the login factor and ignore fallback, sync, and revocation.
Practitioner guidance
- 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.
- 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.
- Harden sync accounts and credential managers Require phishing-resistant authentication on the account that protects synced passwords, passkeys, and TOTP seeds.
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
👉 Read Authsignal's analysis of why passkeys outperform traditional MFA →
Passkeys vs traditional MFA: are your authentication controls keeping up?
Explore further
10/07/2026 9:44 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Passkeys outperform traditional MFA against live phishing attacks
