This post is co-authored by Patryk Les, Principal Product Designer, UX, and Luke Walker, Director – Developer Program, at Yubico
A banking customer buys a hardware security key to protect their account. They open the bank’s security settings, choose ‘Create a passkey’, and expect to use the key they bought for exactly this purpose. But the browser only shows the built-in device option.
This hurdle is unfortunately still a common occurrence and friction point for customers wanting to use hardware-backed passkeys like security keys with many of the online accounts and services they use daily. This includes financial access, healthcare, code, creator income, and AI tools that can hold deeply personal and professional context. That is why companies and services around the world like OpenAI are introducing opt-in advanced account protection for phishing-resistant authentication like passkeys: because every user should be able to have the option to choose the security posture that works best for their preference and threat model.
Advanced protection is an excellent way to provide users choice for their security threat model. In order for authentication options that provide higher levels of security to be more widely used, it will be important for organizations to not just provide default security options – but offer the ability for more options as a standard practice.
Next, we’ll highlight why this is important, including key areas organizations need to look at to create a better passkey experience for all users. Be sure to join us for our upcoming webinar on May 21 at 9am PT to see how this works in practice with live implementation demos – register in advance here.
Risk is personal to and different to every user
The industry often presents consumer accounts as low-risk and enterprise accounts as high-risk, but many consumer accounts are high-value targets. A threat model is not simply determined by market segment.
For example, a journalist protecting sources may need stronger account protection. A healthcare professional may have sensitive access tied to personal devices. A creator’s social account may be their business. And a developer’s personal GitHub account may control code, packages or infrastructure.
All of these users have consumer accounts, but they also have real risk. They do not have an IT department, and they don’t have an administrator who can make an exception. If the service does not surface security key support, they simply fall back to something weaker.
That is how a product simplification becomes a security gap.
Enabling the use of security keys enhances accessibility
Beyond security, there is a more basic point: Providing a choice of authenticator to users is also an accessibility choice.
Accessible authentication is not about finding one perfect sign-in method for everyone – it is about giving people viable options. Users have different abilities, devices, assistive technologies and practical constraints. That is why accessible FIDO deployment depends on supporting a range of authentication methods, not forcing everyone into the same flow. That matters for security keys.
Security keys are not only for people with elevated threat models. For some users, they may be the easiest way to sign in — or the only practical way.
Not everyone owns a smartphone. Not everyone can use touchscreen biometrics comfortably. Not everyone can complete a QR-code, phone-pairing or app-based flow. Some users have physical, cognitive, financial, environmental or practical reasons for preferring a USB or NFC security key.
A USB security key with a PIN and a single touch can be simpler than a smartphone-dependent flow. It requires no app install, no Bluetooth pairing, no biometric sensor, no camera positioning and no cloud sync account. Enrollment may still need care, but daily use can be straightforward.
This does not mean security keys are accessible for everyone. Some users may struggle to insert a key, reach a USB port, touch a small contact area, or position a key for NFC. Every authentication method creates barriers for someone, but accessibility improves when users have more than one viable path.
Supporting security keys is not only about serving the most privacy- or security-conscious users; It is about avoiding sign-in flows that exclude people by design. A good passkey default should guide the user. It should not silently decide that the authenticator that works best for their body, device, environment, or situation does not belong in the flow.
Passkeys offer many advantages for different use cases
The word “passkey” often sounds like one product or one experience, but it is not.
The passkey spectrum runs from synced passkeys — stored in a cloud credential manager and available across devices — to hardware-backed platform passkeys and or hardware security keys like the YubiKey. Each has different strengths and solves a different problem.
For most users, synced passkeys are a strong default: They work across devices, recover well and remove the phishing risk that comes with passwords and one-time codes. But they are not the only valid consumer choice.
Some users want stronger possession. Some want independence from platform sync. Some need a credential that works across shared, restricted or unusual environments. A user may want hardware-bound protection for a bank account, email account, GitHub account, crypto wallet, healthcare account or creator account.
These are not edge cases – they are the predictable result of real people having different risks, devices, abilities and preferences.
Default security options should aim to guide users
Most users should not have to understand credential storage models before they can protect an account. Good defaults matter.
A service can reasonably say: “For most people, we recommend creating a passkey on this device.” That is a helpful default.
The harder question is what happens when the design removes other choices entirely. In some cases, a restriction is justified. A regulated workflow may require a specific authenticator class. A managed enterprise environment may only allow approved devices. A high-assurance action may require hardware attestation.
But there is a reason many services end up here that has nothing to do with policy: a concern about account recovery. The worry is familiar — a user registers only a hardware security key, loses it, and cannot get back in. That is a real problem, but it is a problem with single-credential enrollment – not with hardware keys.
The answer is not to exclude security keys from the flow; it is to design enrollment so users understand they should protect themselves from lockouts by registering more than one credential before they need recovery. A user who registers a synced passkey and a security key has a stronger recovery story than a user who registered either alone. The security key becomes a reliable recovery option — one that does not depend on cloud sync, device availability, or a phone being nearby.
We recommend that users register two YubiKeys: one for daily use and one stored safely as a backup. With that in place, losing a key is not a support event – it’s a planned-for scenario with a path the user already holds.
Designed this way, security key support strengthens account recovery rather than complicating it. The real design opportunity is enrollment: a flow that encourages users to register a second credential — a synced passkey, a security key, or both — before they ever need recovery. When that happens, account recovery becomes a path the user already holds. That is what well-designed multi-credential enrollment looks like, and it is well within reach.
When we restrict choice, can we explain why?
If the answer is no, the product is probably not simplifying – it is silently deciding for the user.
Creating a better passkey UX: Why defaults should preserve choice
A better passkey experience does not need to make security keys the default for everyone, but it does need to keep them visible and usable for the users who choose them. That means using synced passkeys as the mainstream default where appropriate, while keeping security keys available as a clear option in the same flow.
It also means avoiding hidden or dismissive labels that make security keys feel like a technical exception in normal enrollment. “Advanced protection” can be the right label for an opt-in high-assurance mode, but it should not be the only place where users can discover security keys.
It also means being honest about recovery. Passkey registration is not just setup. It is the moment an account binds itself to a new root credential. For high-value accounts, that moment deserves careful design. Users should be encouraged to register more than one credential before recovery is needed.
We’re excited that OpenAI officially supports passkeys and security keys as regular sign-in methods. OpenAI offers Advanced Account Security as a deliberate higher-assurance mode, where other sign-in methods are disabled after the user enables it. That is where an “advanced protection” label makes sense: not for discovering security keys, but for choosing a stricter account posture. Additionally, individual members of OpenAI’s Trusted Access for Cyber (TAC) accessing their most cyber capable and permissive models will be required to enable Advanced Account Security beginning June 1, 2026.
Synced passkeys are a major step forward for authentication globally, and they should often be the first recommendation. Not every user needs a hardware security key, but every user who chooses one should be able to use it.
Join us for our upcoming webinar on May 21 at 9am PT to see how this works in practice with live implementation demos – register in advance.
