What do organisations get wrong about passkeys and phishing resistance?

Why This Matters for Security Teams

Passkeys are often described as phishing resistant, and that is directionally true, but the control is narrower than many teams assume. A passkey changes how a user proves possession of an authenticator, yet it does not remove the need for strong recovery, help desk verification, session protection, or post-login monitoring. That gap matters because real attacks often target the identity lifecycle around the authenticator, not the authenticator itself.

NIST’s NIST Cybersecurity Framework 2.0 treats identity as part of a broader risk management program, which is the right mental model here. The same logic appears in NHI governance: NHI Management Group notes in the Ultimate Guide to NHIs that 79% of organisations have experienced secrets leaks, showing how often attackers succeed through surrounding control failures rather than a single broken mechanism. Passkeys help reduce replay and credential stuffing, but they do not automatically fix social engineering, recovery abuse, or session takeover.

In practice, many security teams discover these weaknesses only after a help desk reset, token theft, or account recovery event has already been used to bypass the intended protection.

How It Works in Practice

The practical error is treating phishing resistance as a property of the login factor instead of the whole authentication and session flow. A passkey is strongest when it is bound to the origin, protected by a secure device, and backed by strong platform security. But the organisation still has to decide how users recover access, how support staff verify identity, how device enrollment is approved, and how sessions are revoked when risk changes.

For that reason, passkeys should be deployed as part of a broader identity architecture, not as a standalone answer. Mature programmes usually combine passkeys with:

• strong identity proofing and recovery controls for account reset events
• device posture checks and step-up authentication for sensitive actions
• short-lived sessions with continuous revalidation for high-risk workflows
• help desk scripts and escalation rules that resist impersonation
• centralised logging to detect anomalous enrollment, recovery, or session behaviour

This is where the NHI lesson is useful. The Ultimate Guide to NHIs shows that identity risk often comes from lifecycle weaknesses, not just authentication weaknesses. That same pattern applies to humans: if recovery is weak, an attacker can bypass a strong authenticator by convincing support to rebind the account or by stealing the active session after login. A control that looks “phishing resistant” at the point of entry can still fail when the surrounding governance is thin.

Current guidance suggests treating passkeys as one layer in a Zero Trust identity program, consistent with NIST Cybersecurity Framework 2.0, rather than as proof that phishing is solved. These controls tend to break down in environments with outsourced support desks and legacy recovery processes because attackers target the weakest manual exception path.

Common Variations and Edge Cases

Tighter passkey enforcement often increases operational friction, requiring organisations to balance stronger phishing resistance against support burden and account recovery complexity.

There is no universal standard for recovery design yet, and that is where many programmes diverge. Some organisations allow backup factors for resilience, but that can reintroduce phishing exposure if those factors are weaker than the passkey itself. Others push device-bound passkeys aggressively, only to find that lost-device events become service desk bottlenecks. Best practice is evolving toward risk-based recovery with explicit approval paths, stronger verification for resets, and rapid session invalidation after suspicious changes.

Another common edge case is assuming passkeys eliminate post-login governance concerns. They do not. If a user is tricked into approving a malicious action inside a legitimate session, or if an attacker hijacks a browser session through malware or token theft, the passkey has already done its job and the failure has moved elsewhere. The same caution applies to privileged accounts, contractors, and shared endpoints, where local device trust may be weaker than expected.

Organisations should also be careful not to overstate protection in executive reporting. Passkeys materially improve resistance to credential phishing, but they are not a complete defence against help desk impersonation, endpoint compromise, or session replay. That distinction matters, especially when authentication modernisation is used as evidence that broader identity risk has been solved.

Related resources from NHI Mgmt Group

• What do organisations get wrong about phishing in remote work?
• What do organisations get wrong when they treat phishing resistance as a technology project?
• What do teams get wrong about unauthorized account sharing controls?
• What do organisations get wrong about segregation of duties in federated environments?