Passkey UX should preserve security key choice for high-risk users

At a glance

What this is: This is an analysis of why passkey enrollment flows should keep hardware security keys available as a normal option, with the key finding that default UX often creates avoidable security and accessibility friction.

Why it matters: It matters because IAM teams increasingly govern mixed populations of human users, high-risk consumer accounts, and sensitive workflows where removing authenticator choice can weaken both security posture and account recovery.

👉 Read Yubico's analysis of passkey UX, recovery, and hardware security key choice

Context

Passkey adoption only improves security when the enrollment flow preserves the authenticator choices that match a user's threat model, device reality, and recovery needs. In practice, many consumers and employees are still pushed toward a built-in option even when they intentionally bought a hardware security key for phishing-resistant authentication.

That matters for identity programmes because authentication design is not just a user experience decision. It shapes account assurance, accessibility, recovery, and the practical reach of phishing-resistant controls across high-value human accounts, including finance, healthcare, code, and AI tools.

A good default can guide most users toward synced passkeys while still exposing security keys as a viable option for the people who need them. The common pattern here is not unusual: security teams often simplify flows in ways that silently narrow protection choices for the very users most likely to need stronger ones.

Key questions

Q: How should security teams design passkey enrollment so users can still choose hardware security keys?

A: Keep hardware security keys visible in the main enrollment path, not hidden behind advanced settings. Let users register more than one credential during setup so recovery exists before loss, and ensure the default recommendation guides most users without removing stronger options for higher-risk accounts.

Q: Why do passkey flows fail when they only offer one authenticator option?

A: They turn enrollment into an implicit policy decision that can weaken account assurance, accessibility, and recovery. Users with higher threat models or limited device access may be forced into weaker methods, and the service then inherits avoidable lockout and support risk.

Q: What do organisations get wrong about hardware security keys?

A: They often treat the key as the end of the problem, when the real control boundary is the full lifecycle around enrolment, reset, replacement, and offboarding. If those steps are weak, users can be phished, support teams can be abused, or exceptions can reopen the same risk the key was meant to close.

Q: When should organisations use advanced protection modes instead of standard passkey choice?

A: Use stricter modes when the account genuinely needs stronger assurance or when policy requires a narrower set of authenticators. For most users, the better approach is to preserve choice in the main flow and reserve advanced protection for accounts that truly need it.

Technical breakdown

Synced passkeys, platform passkeys, and hardware security keys

Passkeys are not a single mechanism. Synced passkeys live in a credential manager and can move across devices, platform passkeys are bound to a device ecosystem, and hardware security keys store the credential on a dedicated authenticator. Each model changes recovery, portability, and phishing resistance. The core design question is not whether a passkey exists, but which trust boundary the credential occupies and what happens when the user changes devices, loses access, or needs stronger possession than a synced credential provides.

Practical implication: map authenticator type to account risk and recovery design before you hide one option behind another.

Why enrollment UX becomes a security control

Enrollment is the moment an account binds to one or more root credentials. If the flow only presents one authenticator path, the service is not just simplifying choice, it is constraining assurance architecture. That constraint is often justified as recovery protection, but the real issue is single-credential enrollment, not hardware keys themselves. Good authentication design lets users register more than one credential so recovery is already established before the first loss event.

Practical implication: treat enrollment as part of identity governance, not as a cosmetic setup screen.

Accessibility and account assurance in the same flow

Accessible authentication is not achieved by forcing every user through the same method. Some people cannot rely on a smartphone, biometrics, QR pairing, or app-based flows, while others need a USB or NFC key because it is the simplest practical option. Security keys are not universally accessible, but neither are phone-first flows. A usable passkey experience needs multiple valid paths, clear guidance, and no hidden demotion of hardware-backed options.

Practical implication: design sign-in journeys so accessibility requirements and high-assurance authentication can coexist without trade-offs being made by default.

NHI Mgmt Group analysis

Authenticator choice is a governance control, not a convenience feature. When a passkey flow hides hardware security keys, the service is making an implicit policy decision about acceptable assurance levels. That decision affects who can adopt phishing-resistant authentication, who can recover safely, and which users are forced back to weaker methods. IAM teams should treat authenticator choice as part of identity policy, not just front-end design.

Single-credential enrollment is the real recovery failure mode. The problem is not that hardware keys are inherently hard to recover from. The problem is that many flows do not guide users to register a second credential before they need it. That turns a recovery design issue into a support crisis, and it is especially visible in high-value consumer accounts where no administrator can intervene.

Passkeys only scale when the experience preserves the user's threat model. A journalist, creator, developer, clinician, or finance user may need a different assurance posture than the average consumer. The industry keeps overfitting to the lowest common denominator, then calling the result simplicity. In identity programmes, that shortcut narrows adoption of stronger authentication rather than expanding it.

Hardware keys belong in the mainstream passkey path, not a special-case corner. The industry should stop treating security keys as an exotic exception reserved for advanced protection mode. Synced passkeys may be the mainstream default, but a normal flow must still let users select stronger possession when the account and threat model justify it. That is the design standard practitioners should expect.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, which shows how confidence and practice often diverge in identity-adjacent controls.
• That same gap is why identity teams should read Ultimate Guide to NHIs , Why NHI Security Matters Now before tightening recovery and authenticator policy.

What this signals

A better passkey programme now needs to treat authenticator selection as part of identity policy rather than a UI preference. If the service cannot explain why a security key is excluded, the design is probably constraining assurance for convenience instead of for control.

Choice integrity: the next passkey maturity test is whether the default flow still preserves stronger options for users with higher risk, different devices, or accessibility needs. That will matter most in accounts that combine personal and professional value, where a weaker fallback is not a neutral fallback at all.

Identity teams should look at this through the same lens they apply to lifecycle and recovery design. If the onboarding path does not encourage more than one credential, then the recovery path is being deferred into an incident response problem instead of being engineered up front.

For practitioners

• Preserve authenticator choice in the passkey flow Keep hardware security keys visible alongside synced and platform passkeys so users can select the authenticator that matches their risk and accessibility needs. Avoid design patterns that bury security keys in advanced or secondary paths unless a policy requirement truly exists.
• Require multi-credential enrollment for high-value accounts Prompt users to register a second credential during enrollment, not after loss. Pair a synced passkey with a hardware key, or two hardware keys where assurance is high enough, so recovery is planned rather than improvised.
• Separate policy restrictions from UX simplification Document when a restricted authenticator set is a compliance or enterprise policy decision and when it is merely a product shortcut. That distinction matters because users should not lose strong authentication options by accident.
• Test sign-in journeys for accessibility and recovery together Run usability reviews with users who rely on USB, NFC, assistive technology, shared devices, or non-smartphone environments. Validate that authentication choice still works when recovery, threat model, and accessibility constraints overlap.

Key takeaways

• Passkey adoption is undermined when services hide hardware security keys that users intentionally chose for higher assurance.
• The main design failure is single-credential enrollment, which turns recovery into a crisis instead of a planned identity state.
• IAM teams should preserve authenticator choice, multi-credential enrollment, and accessibility in the same flow rather than treating them as separate decisions.

Key terms

• Passkey Enrolment Fraud: Passkey enrolment fraud happens when an attacker gains temporary access to an account and registers their own device or authenticator as trusted. After enrolment, the attacker can authenticate legitimately because the system believes the new binding is valid. The weakness is not the passkey itself, but the governance around who can bind it.
• Hardware security key: A hardware security key is a physical authenticator that stores cryptographic material and proves possession during login. Because the private key is not copied into the browser or app, it is much harder for attackers to steal, replay, or phish than a shared secret.
• Account Recovery: Account recovery is the process used to restore access when a user cannot authenticate normally. In mature IAM programmes, recovery is treated as part of the trust chain because a weak reset path can bypass stronger login controls and become the easiest route to account takeover.
• Authentication Choice: The ability for a user to select among viable sign-in methods that match their security, accessibility, and device needs. For identity teams, choice is not indecision. It is a control that can either expand adoption of stronger authentication or quietly push users back toward weaker defaults.

What's in the full article

Yubico's full article covers the operational detail this post intentionally leaves for the source:

• Specific guidance on when synced passkeys should remain the default versus when hardware security keys should stay visible in the same enrollment path
• Practical UX examples for multi-credential enrollment that reduce lockout risk without forcing users into weaker fallback methods
• Discussion of accessibility constraints across smartphone, USB, NFC, biometric, and shared-device scenarios
• Context on OpenAI's advanced account protection and how opt-in higher-assurance modes change the sign-in experience

👉 Yubico's full article explains the enrollment and recovery patterns behind hardware-backed passkeys.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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 NHI governance in your organisation, it is worth exploring.