Notifications
Clear all
Topic starter
26/08/2026 11:51 am
TL;DR: Many services still hide or block hardware security keys in passkey flows, even for users whose threat model calls for stronger phishing-resistant authentication, according to Yubico. The real design problem is not whether passkeys work, but whether enrollment, recovery, accessibility, and account assurance can coexist without silently removing user choice.
NHIMG editorial — based on content published by Yubico: how passkey UX should preserve security key choice for high-risk users
Questions worth separating out
A: Keep hardware security keys visible in the main enrollment path, not hidden behind advanced settings.
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.
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.
Practitioner guidance
- 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.
- Require multi-credential enrollment for high-value accounts Prompt users to register a second credential during enrollment, not after loss.
- 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.
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
👉 Read Yubico's analysis of passkey UX, recovery, and hardware security key choice →
Security keys and passkeys: why choice still matters for IAM teams?
Explore further
26/08/2026 11:51 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Passkey UX should preserve security key choice for high-risk users
