Passkey rollout still fails when user understanding lags technology

At a glance

What this is: Bitwarden’s summit coverage shows that passkey adoption at scale depends more on user education, workflow consistency, and phased rollout than on cryptography alone.

Why it matters: IAM teams need this because passkey programmes succeed or fail on change management, authentication design, and the handling of fallback paths across human and non-human identity workflows.

👉 Read Bitwarden's passkey rollout guidance from the 2025 Open Source Security Summit

Context

Passkeys are a stronger authentication method, but they still have to be understood, adopted, and supported by real users. The security gap here is not the cryptographic standard itself, but the operational distance between a new authentication model and the people expected to use it.

For IAM teams, this is a human identity problem with direct governance consequences. If users do not understand what a passkey is, they default to familiar but weaker habits, support pressure rises, and policy exceptions start to accumulate. That makes rollout discipline just as important as the technical control.

This kind of adoption problem fits the broader authentication and lifecycle conversation captured in the Ultimate Guide to NHIs and related identity governance resources, especially where credential choice, backup access, and account recovery need to be managed as part of a consistent programme.

Key questions

Q: How should organisations roll out passkeys without overwhelming users?

A: Use a phased rollout with one standard enrolment flow, clear plain-language guidance, and support materials in multiple formats. Start with a small internal group, learn from the friction points, then expand only after help desk and security teams can answer the most common questions consistently.

Q: Why do passkey programmes still need strong support and education?

A: Because most users do not think in cryptographic terms. They need to understand where the passkey lives, how it is recovered, and how it differs from passwords or OTPs. Without that support, confusion drives exceptions, extra tickets, and slower adoption.

Q: What breaks when password fallback remains too easy after passkey rollout?

A: The organisation preserves a weaker authentication path that users can choose instead of the stronger one. That creates downgrade risk, inconsistent enforcement, and a false sense of improved security because the passkey exists but is not the default protection.

Q: Who should require passkeys first in an identity programme?

A: Privileged users and high-risk accounts should be first in line because their access carries greater impact if compromised. Requiring passkeys for those roles ensures the strongest control is applied where the downgrade cost is highest and where weaker fallback options are least defensible.

Technical breakdown

Why passkey adoption depends on the user mental model

Passkeys are technically an asymmetric authentication mechanism, but users do not experience them that way. They experience them as something they either understand enough to trust or something they route around. In enterprise deployment, that means the explanatory model matters: describing a passkey as a digital key stored on a phone or in a password manager is often more effective than explaining public-key cryptography. The technical control can be sound while adoption still fails if the user cannot distinguish passkeys from passwords, passcodes, OTPs, or SMS codes. Practical implementation therefore depends on reducing cognitive load, not increasing technical detail.

Practical implication: build user-facing messaging around behaviour and recovery, not cryptographic internals.

Standardised passkey workflows and rollout rings

At scale, passkey deployment is an operating model problem. Standardising on one authenticator app and one enrolment flow reduces variability, support effort, and confusion across teams. A phased rollout, starting with a small group and expanding by department or ring, lets security teams observe failure points before organisationally broad exposure. This is the same governance pattern used in other identity programmes: constrain the number of moving parts, learn from early cohorts, and only then broaden the blast radius. Without that discipline, passkeys become another fragmented authentication option rather than a controlled upgrade.

Practical implication: treat passkey rollout as a staged identity programme, not a one-time enablement project.

Fallback authentication can weaken the passkey control

Passkey programmes often stall when legacy fallback options remain too easy to use. If a user can simply choose password instead, the organisation has introduced a stronger control without removing the weaker one. The result is downgrade risk, inconsistent enforcement, and policy ambiguity. This is especially important for privileged accounts, where stronger authentication should not be optional. The operational question is not whether passkeys exist in the stack, but whether the surrounding authentication paths preserve their intended security value. Stronger authentication only changes risk when the fallback path is governed as tightly as the primary path.

Practical implication: review downgrade paths and privileged access policy together, not separately.

NHI Mgmt Group analysis

User adoption is the control plane for passkey success. The article makes clear that the problem is not user resistance in the abstract, but the gap between stronger authentication and the language people use to understand it. That gap determines whether passkeys are trusted, enrolled, and retained, which makes communication a governance control rather than a soft skill. For IAM teams, the practical conclusion is that rollout quality depends on comprehension quality.

Passkey deployment becomes a lifecycle issue as soon as backup access and recovery enter the picture. Once users ask where a passkey lives, how it is replaced, or what happens when a device is lost, the programme has moved into lifecycle governance. That is the point where authentication, account recovery, and support processes converge. The implication is that passkey adoption cannot be owned by authentication engineering alone; it has to sit inside the broader identity operating model.

Weak fallback design can erase the security value of the new factor. If password login remains the default escape hatch, the organisation has not replaced weaker authentication so much as renamed it. The passkey control only changes the risk posture when the downgrade path is constrained, visible, and policy-driven. Practitioners should read this as a reminder that authentication strength is measured by the weakest permitted alternative, not the strongest available option.

Named concept: passkey adoption friction. This is the gap between technically sound authentication and the operational effort needed for users to understand, enrol, and sustain it. Foot Locker’s experience shows that the friction is lower only after internal teams are ready to answer questions consistently, support multiple learning formats, and phase rollout deliberately. Practitioners should treat adoption friction as a measurable governance constraint, not a communications afterthought.

From our research:

• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to Ultimate Guide to NHIs.
• Another finding from the same research shows that 97% of NHIs carry excessive privileges, which broadens the attack surface when governance is weak.
• For the lifecycle angle that sits behind stronger authentication and recovery design, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs.

What this signals

Passkey rollouts will increasingly be judged as governance programmes, not authentication projects. The control only lands when users understand it, support teams can explain it, and fallback paths are tightened around high-risk accounts. That makes adoption maturity a programme metric, not a product toggle.

Passkey adoption friction: organisations should expect resistance whenever they introduce a stronger factor without rewriting the user journey around it. The practical signal is fewer exceptions, fewer password downgrades, and fewer support escalations after the first rollout ring.

Identity teams that already manage lifecycle, recovery, and privileged access in one operating model will be better placed to absorb passkey change. Those that treat authentication as a standalone feature will keep rediscovering the same failure mode: technically sound controls that users never fully adopt.

For practitioners

• Standardise the enrolment journey Choose one primary authenticator path, define the enrolment steps in plain language, and remove avoidable variation across teams and geographies.
• Train support staff before broad rollout Make the security and help desk teams fluent in backup passkeys, storage locations, device loss handling, and common user confusion points before expansion.
• Run phased adoption rings Start with a small internal cohort, expand to a department, then scale organisation-wide after each ring exposes the process gaps that need refinement.
• Govern fallback and downgrade paths Review where password login, SMS, or other weaker options remain available, and require stronger controls for privileged accounts and high-risk users.

Key takeaways

• Passkey success depends on user comprehension and workflow consistency as much as on the underlying cryptography.
• Weak fallback paths can neutralise a stronger factor if password or SMS options remain easier to use.
• IAM teams should stage rollout, train support early, and govern privileged access first when passkeys become policy.

Key terms

• Passkey: A passkey is a phishing-resistant authentication credential that replaces shared secrets with cryptographic keys bound to a user device or manager. In practice, the user experiences it as a login method they possess rather than a password they remember, which changes enrolment, recovery, and support requirements.
• Authentication Fallback: Authentication fallback is the weaker alternative a user can choose when the primary method is unavailable or inconvenient. In identity programmes, fallback design matters because the security value of a stronger factor is limited if users can easily bypass it through password or SMS routes.
• Passkey Adoption Friction: Passkey adoption friction is the operational and behavioural resistance that appears when users are asked to change familiar authentication habits. It includes confusion, extra support demand, storage uncertainty, and workflow mismatch, all of which can delay or dilute the security benefit of the new control.
• Phased Rollout: Phased rollout is a staged deployment approach that introduces a control to a small cohort before broadening it across the organisation. For identity programmes, it reduces uncertainty by exposing process gaps early and gives security teams time to correct support, policy, and communication issues before scale.

What's in the full article

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

• Practical examples of how Foot Locker communicated passkeys to non-technical users in a way that reduced confusion.
• The workflow decisions behind a standardised enrolment path, including how users were guided to create and store passkeys.
• The support playbook used for backup passkeys, recovery questions, and the transition away from SMS-based authentication.
• Recommendations for using automation and policy to remove weaker authentication from privileged accounts after enrolment.

👉 The full Bitwarden post covers user education, standardised workflows, and the passkey support model in more detail.

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.