Why safer products can still feel risky: what passkeys teach us about adoption

Passkeys create an awkward product problem. The underlying technology can make an account safer, while the person using it becomes less certain that they will retain access.

A July 2026 Hacker News discussion about passkeys attracted 785 comments. People asked where a passkey was stored, whether it would work on another device and what would happen after a phone or computer failed. The commenter NicuCalcea wrote: “I don't think a single person I know in real life uses one.”

Hacker News is a self-selected developer community, so its comments cannot tell us how common those experiences are. They can show us which questions a product has left unresolved. This makes passkeys a useful case study in the psychological and contextual processes behind consumer behaviour.

What does passkey adoption tell us about consumer psychology

Passkey adoption depends on more than the security of the underlying technology. People need to see a useful advantage, understand what unfamiliar prompts mean and feel confident that they can use the credential across their devices, manage it and recover after something goes wrong.

Adoption is a decision to start and continue a behaviour. A person can accept a passkey prompt once without understanding what changed or choosing to use passkeys elsewhere.

Foundational technology-acceptance research gives us two useful questions. Does the person expect the technology to be useful? Does it appear easy enough to use? Fred Davis tested these as perceived usefulness and perceived ease of use in the original Technology Acceptance Model.

That model does not explain every adoption decision. Account type, security needs, device compatibility, help from other people and previous experience can all change the judgement. It does provide a better starting point than assuming a technically superior product will sell itself.

What is a passkey

A passkey is a digital credential that uses public-key cryptography to authenticate someone to a particular website or app. The service stores a public key. The corresponding private credential is managed on the user's side by a device, credential manager or security key.

The WebAuthn standard scopes a credential to the service that created it. This gives passkeys strong resistance to credential phishing because a fraudulent site cannot ask the authenticator to produce a valid response for another service.

The term still covers different arrangements. The FIDO Alliance's passkey definition distinguishes credentials synchronised between authorised devices from credentials bound to one device. That difference matters when somebody changes platform, loses a device or needs a second person to access an account legitimately.

The UK National Cyber Security Centre's comparison of FIDO2 and traditional credentials finds important security advantages in FIDO2 authentication. It also identifies conditions involving device security, synchronisation accounts, backups, revocation and recovery.

Technical security is therefore one part of the experience.

Concept	Plain-English meaning	Passkey example
Technical security	The protection a system provides against defined attacks	A credential scoped to one service resists credential phishing.
Perceived security	The user's judgement of how safe the system seems	A passkey seems safer, less safe or simply unfamiliar.
Usability	Whether people can complete tasks effectively, efficiently and satisfactorily in context	A person can create, use, manage and remove a passkey across their real devices.
Perceived control	Confidence that the person can understand, manage and recover the outcome	They know where the passkey is stored and what happens after a device is changed or lost.

These dimensions interact without becoming interchangeable. A quick first sign-in does not show that recovery is understood. Strong protection against phishing does not guarantee that a person will feel confident about access next month.

Have passkeys failed to gain adoption

Available evidence indicates that passkeys have achieved material adoption. It also shows that the user experience remains uneven.

In May 2026, the FIDO Alliance reported that 75% of surveyed consumers had enabled passkeys on at least some accounts. Sapio Research conducted the online survey in April 2026 with 11,000 adults who regularly use websites, apps or online services across ten countries.

The result comes from the standards body promoting passkeys, which should inform how it is interpreted. It measures reported enablement. It does not establish how frequently people use passkeys, whether sign-ins succeed or whether users understand storage and recovery.

A 2023 CHI laboratory study provides a more detailed view. It compared platform and roaming FIDO2 authentication on smartphones with 87 participants. Most participants were willing to adopt passwordless authentication, while their priorities changed with the type of account. The researchers identified multi-client access and account delegation among the remaining barriers.

Implementation is another source of variation. A 2026 USENIX Security study analysed 872 passkey-enabled websites. It found marked differences in how sites let users add and delete passkeys.

The Hacker News criticism and the wider adoption evidence can both contain useful information. Adoption can rise while particular journeys remain confusing. A standards-based technology can also produce different experiences when websites, operating systems and credential managers implement separate parts of the journey.

Why can a safer system create more uncertainty

Several forces are involved. None requires us to assume that people have misunderstood a perfectly simple offer.

The protection is difficult to see

The main passkey benefits concern attacks that may never happen to a particular user. Protection against phishing and stolen password databases has considerable value, but the benefit remains largely invisible during an ordinary sign-in.

The immediate costs are easier to notice. The person encounters a new term, a system dialog and questions about where the credential will be available. This is a value-perception problem as well as a security problem. A future protective benefit is being compared with effort and uncertainty in the present journey.

Product copy often responds by repeating that passkeys are faster and safer. Those claims do not answer the operational questions. A person may believe the security claim and still need to know how they will access the account from a work laptop tomorrow.

The established routine is understood

Passwords have serious security and usability weaknesses. They also give many users a rough model of what they possess and what happens when they forget it.

That familiarity makes the behaviour easier to repeat. Our article on how habits and routines shape purchasing decisions explains why an established cue and response can persist even when an alternative has advantages.

Familiarity is not a complete explanation for passkey reluctance. Some people use several operating systems. Some households share access where a service has not provided proper delegated accounts. Some users have legitimate concerns about a single-device credential or the recovery of a synchronisation account. These are product requirements rather than psychological errors.

Control moves across several interfaces

A website can invite someone to create a passkey, then hand control to an operating-system dialog. The credential may be held by Apple Passwords, Google Password Manager, Windows Hello, a third-party manager or a hardware key. The website may have little control over how the next part looks.

FIDO's 2023 UX guidance reports research with 26 US participants who used a prototype and demonstration site. In early account-creation designs, moving directly from an email step to an unfamiliar operating-system passkey dialog disoriented some participants. Some became less confident that they were following the correct account-creation path and abandoned the process.

The study was small and covered a particular non-regulated journey. Its findings still identify a practical design problem. A short journey can be difficult to understand when an unexplained system action breaks the user's model of what is happening.

Recovery determines whether control feels durable

People often judge a new system by asking what happens when normal life interrupts it. Phones break. Staff leave. People change platform. A relative may need help. A credential can be created without the person remembering which manager stored it.

Recovery is part of the authentication product. NIST's current digital identity guidance recommends testing realistic tasks with representative users. It says identity systems should make correct action easy and recovery possible when something goes wrong.

The right recovery method depends on the account and required security level. The broader adoption lesson is stable: users need enough information to judge continuity before they hand over control.

How should product teams design unfamiliar behaviour

An adoption journey needs to answer six questions. The same audit can be used for a passkey, a software migration or a revised account workflow.

1. Is the value visible at this moment

Explain the outcome in terms the person can observe. “Sign in without typing a password” is more immediate than a general claim about modern security. Explain phishing resistance where the account risk makes it relevant.

Timing changes how useful the benefit appears. FIDO's research found that account settings and recovery could be relevant moments for introducing passkeys. Someone who has completed a password-reset process has direct evidence of the effort a passkey might remove.

2. Does the interface explain the next action

Tell the user what the operating system or external service is about to ask them to do. Confirm what happened when control returns to the product.

This creates continuity between the website and a system dialog the product team cannot design. It applies the wider principles of designing a decision interface to an adoption decision.

3. Does the user know where the new object lives

Name the credential source where the platform makes that information available. Show it again in account settings. Let people distinguish several credentials and remove one they no longer need.

Google's passkey journey guidance recommends showing the source of each passkey and distinguishing multiple credentials from the same provider. This is useful because the management interface supplies the missing model after creation.

The general product question is simple: could the customer find and manage the thing they have just created after the confirmation message disappears?

4. Is continuity explained

Cover the device and access patterns that matter to the audience. Explain whether a credential will synchronise, how another device can authenticate and whether the account supports multiple credentials.

If several people need access, provide proper member or delegated access where the service permits it. Asking customers to replace a shared password without providing a supported sharing model removes a behaviour without replacing its job.

5. Is recovery visible before failure

Establish an appropriate recovery method during account creation. Explain what the person should retain and how they can regain access. Encourage a backup credential where a device-bound arrangement makes that necessary.

Recovery information should be easy to find before an incident. A promise that support will help does little when the user cannot see how identity will be established safely.

6. Can the user choose and verify the change

Give people a clear opportunity to accept, postpone or decline where the security policy allows it. Confirm successful creation and let them test or view the credential in account settings.

Freedom of choice does not require presenting every option as equally secure. A product can recommend the stronger route and explain why. It should also state the consequences and preserve a workable route for customers whose devices or access needs are not yet supported.

Better adoption preserves informed choice

An adoption target can encourage the wrong design. A team may count every created passkey as success, including credentials that users do not understand, cannot use elsewhere or later remove.

Measure the behaviour across its lifecycle. Useful measures include successful sign-ins, failure rates, recovery attempts, support demand, credential removal and continued use. Security incidents and the use of weaker fallbacks also matter. NIST includes authentication failures and account-recovery attempts among the measures for evaluating identity systems.

User research should cover creation, routine sign-in, a second device, credential management and recovery. Include the platforms, assistive technologies and delegated-access needs present in the real audience.

The same standard applies outside authentication. A business introducing an unfamiliar process should make the value visible, explain the state change and show how the customer remains in control. Promotion cannot compensate for missing continuity or recovery.

Frequently asked questions

What is a passkey

A passkey is a digital credential based on public-key cryptography. A website or app stores the public key, while the private credential is managed through a device, credential manager or security key. Passkeys are scoped to the service that created them, which gives them strong resistance to credential phishing.

Are passkeys safer than passwords

Passkeys provide important protection against phishing, password reuse and the theft of password databases. Overall security still depends on the device, credential manager or synchronisation account, site implementation and recovery method. A device-bound credential and a synchronised credential also have different backup and continuity conditions.

Why are some people reluctant to use passkeys

Reasons can include unfamiliar terminology, unclear credential storage, uncertainty about other devices, account-sharing needs and concern about recovery. Familiar password routines can contribute, but resistance should not automatically be treated as bias. Some concerns identify a real mismatch between the implementation and the user's circumstances.

What can passkeys teach product teams about adoption

A technical benefit needs a comprehensible journey. Users should be able to see the immediate value, understand what changes, identify where control resides and know how continuity and recovery work. Product teams should test those tasks with representative users and measure continued successful use rather than initial acceptance alone.

Passkeys have not removed the need to understand users. They have made that need visible across the whole credential lifecycle. A safer design earns confidence when people can understand the value, manage the change and recover from an ordinary failure.