Why do passkeys change authentication risk but not identity governance?

Why This Matters for Security Teams

Passkeys materially lower exposure to phishing, credential stuffing, and password reuse, which makes them an important control improvement. The governance challenge is different: authentication becomes stronger, but identity lifecycle decisions still depend on who can enrol a device, approve recovery, transfer access, and remove trust when someone leaves. That distinction is central to the NIST Cybersecurity Framework 2.0, which treats identity assurance, access control, and recovery as operational capabilities rather than a single login event.

Security teams often assume that adopting passkeys removes most authentication risk. It does not. It changes the risk profile from secret theft to trust in the endpoint, the synchronisation layer, and the recovery path. If those decisions are not governed, a safer factor can still be used to preserve unsafe access for too long or to reissue access to the wrong person. In practice, many security teams encounter passkey abuse only after account recovery or offboarding has already failed, rather than through intentional lifecycle design.

How It Works in Practice

Passkeys replace shared secrets with asymmetric credentials bound to a user device or sync ecosystem. That reduces exposure to phishing and replay attacks because there is no password to capture and reuse. But authentication is only one stage in the identity process. Organisations still need policy for enrolment, device assurance, recovery, and revocation, because the enterprise is governing the identity record, not just the login ceremony.

Practical governance usually includes:

• Defined enrolment rules that say which users, devices, and assurance levels can register a passkey.
• Recovery approval workflows that verify the requester through a separate trusted channel.
• Offboarding steps that revoke sessions, remove authenticators, and disable recovery paths.
• Audit trails that show when a passkey was added, synced, re-bound, or reset.

Control mapping is straightforward in principle. Under NIST SP 800-53 Rev 5 Security and Privacy Controls, organisations can align passkey use to identity proofing, authenticator management, and account recovery controls. Under ISO/IEC 27001:2022 Information Security Management, the same question becomes whether access provisioning, revocation, and exception handling are consistently controlled and evidenced. The key point is that passkeys remove password handling from the attacker’s playbook, but they do not remove the need for joiner-mover-leaver governance, privileged access review, or recovery assurance. These controls tend to break down when consumer sync features, unmanaged devices, and help desk resets are all allowed to bypass the same approval path.

Common Variations and Edge Cases

Tighter passkey governance often increases onboarding friction and support overhead, requiring organisations to balance phishing resistance against operational convenience. That tradeoff is real, especially when users expect seamless sign-in across personal and corporate devices.

The hardest edge cases are not the everyday logins. They are account recovery after device loss, shared or kiosk environments, BYOD patterns, executive travel, and cross-device sync. Best practice is evolving here, and there is no universal standard for exactly how much assurance a synced passkey should carry in every context. Some organisations treat synced credentials as acceptable for standard users but require stronger device binding or step-up verification for privileged accounts. Others prohibit synced passkeys for high-risk roles until governance is mature enough to cover recovery, custody, and revocation.

Another common gap is thinking that passkeys solve identity proofing. They do not. A strong authenticator cannot fix weak onboarding, poor proofing, or overly permissive recovery. The identity governance question remains: who approved the original identity, who can recover it, and under what conditions can access be reinstated? That is why passkeys should be implemented as part of a broader identity programme, not as a replacement for it, and why lifecycle controls should be reviewed whenever authenticator policies change.

Related resources from NHI Mgmt Group

• Why do passkeys change the way teams think about customer identity risk?
• Why do identity governance gaps create more breach risk than authentication failures?
• Why do strategic IT programmes create more identity risk if governance does not change?
• Why do AI agents change infrastructure identity governance?