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

Why This Matters for Security Teams

Passkey enrollment is not just a usability choice. It determines whether phishing-resistant authentication becomes the default path or a feature only power users discover. If hardware security key are buried behind advanced options, many users never register them, and the organisation loses one of the strongest recovery and high-assurance factors available. That matters most for privileged users, finance workflows, and admins who face targeted credential theft.

Current guidance from NIST AI Risk Management Framework is clear on aligning controls to risk, and the same design principle applies here: enrollment paths should reflect the assurance level the account actually needs. NHIMG research on The State of Non-Human Identity Security shows how often organisations underinvest in strong identity controls until the damage is visible, with only 1.5 out of 10 highly confident in securing NHIs. The lesson transfers to human authentication design: optional strong factors tend to remain optional unless they are presented early and clearly.

In practice, many security teams discover missing hardware key coverage only after a user loses a device and the fallback options are already too weak to trust.

How It Works in Practice

The practical pattern is to make the enrollment flow preference-based, not gate-based. Present passkeys and hardware security keys together in the primary setup path, then explain the recommendation in plain terms: passkeys are convenient, hardware keys are best for higher-risk accounts or users who want a portable, phishing-resistant second factor. The key is to preserve choice while steering most users toward a secure default.

Security teams should design enrollment so users can register multiple authenticators in the same session. That usually means at least one platform passkey plus one hardware key, with recovery or backup methods established before the first device is lost. This is consistent with the broader identity guidance in NIST AI 600-1 Generative AI Profile, which emphasises managing risk in context rather than relying on a single control path. For implementation, OWASP Top 10 for Agentic Applications 2026 and the broader CSA MAESTRO agentic AI threat modeling framework reinforce a similar principle for identity-enabled systems: do not hide stronger controls behind paths only experts notice.

• Keep hardware security keys in the main enrollment screen, not in settings.
• Allow more than one credential during first-time setup.
• Use a default recommendation, but do not block stronger options.
• Require re-authentication or step-up verification for adding a second factor.
• Make recovery visible before the user needs it.

For high-risk roles, teams can require at least one hardware key while still allowing a passkey for day-to-day convenience. These controls tend to break down in large federated environments because identity providers, endpoint policies, and local app enrollment screens do not always share the same state.

Common Variations and Edge Cases

Tighter enrollment control often increases support overhead, requiring organisations to balance phishing resistance against onboarding friction. That tradeoff is real, especially when users bring multiple devices, work across managed and unmanaged endpoints, or need to enroll from a mobile-first workflow.

Best practice is evolving on whether hardware keys should be recommended or required for all users. There is no universal standard for this yet, but current guidance suggests reserving mandatory hardware key enrollment for privileged users, administrators, and high-value business roles. For the wider workforce, the safest pattern is to surface the option prominently and explain why it matters, instead of forcing every user into the same path.

NHIMG’s Ultimate Guide to NHIs and the research on DeepSeek breach both reinforce a broader lesson: identity controls fail when strong options are treated as exceptions instead of standard design choices. The same is true for passkey enrollment. If a platform nudges only toward convenience, users will rarely discover the stronger path unless security teams deliberately make it part of the default experience.

In lower-maturity environments, the main edge case is account recovery. If recovery depends on SMS or email alone, adding hardware keys without a parallel recovery design can improve phishing resistance while creating a new lockout risk. That is why enrollment, recovery, and step-up authentication should be designed together, not separately.

Related resources from NHI Mgmt Group

• How should security teams govern API keys used for generative AI access?
• How should security teams design MFA enrollment so users actually complete it?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities at scale?