By NHI Mgmt Group Editorial TeamBased on Descope: “Passkey Trends for 2026: What the Data Says” (May 13, 2026)

TL;DR: Passkey awareness is broadening, with 75% of global consumers recognizing them and 28% enabling them whenever possible, while 45% of organisations have deployed them in at least one app and 87% still rely on passwords for customer-facing authentication, according to FIDO Alliance and Descope. The gap is no longer about demand; it is about whether identity teams can modernise authentication without breaking existing customer journeys.


At a glance

What this is: This analysis shows that passkey adoption is accelerating in customer IAM, but most organisations still have password-led authentication and limited readiness to modernise at scale.

Why it matters: Customer IAM teams need to treat passkeys as a migration and operating model problem, not just a feature rollout, because authentication changes affect UX, support load, and security posture together.

By the numbers:

  • 45% of organisations have deployed passkeys in at least one app.
  • 87% of organisations still use passwords for customer-facing auth.

Context

Passkeys are a customer authentication method built on public key cryptography, so the user proves possession of a device-bound credential instead of sharing a reusable password. In customer IAM, that changes both the security model and the implementation burden, because authentication has to fit existing sign-up, sign-in, recovery, and step-up flows.

The gap in this article is not whether passkeys work, but whether CIAM teams can adopt them without leaving passwords in place as the real default. That is an identity governance problem as much as an authentication problem, because rollout choices affect user journeys, support costs, and the operational ownership of passwordless flows.


Key questions

Q: How should organisations roll out passkeys without breaking customer login flows?

A: Start with journeys that already tolerate fallback, such as signup, account recovery, and step-up authentication. Keep passwords or other alternatives available during transition, but define when they apply and who owns exceptions. That lets teams prove value through measurable improvements in sign-in success, user experience, and support load before expanding passkeys more broadly.

Q: Why do passkey programmes stall after an initial rollout?

A: They stall when users cannot see the credential at the right moment, when stale credentials still appear, or when failures make the method seem unreliable. Adoption depends on consistency across browser, provider, and backend state. If any one of those layers is out of sync, users fall back to passwords.

Q: What are the signs that passkey adoption is not working well enough?

A: Warning signs include low enrollment rates, repeated login failures, heavy reliance on password fallback, and support demand around device changes or account recovery. If users cannot complete registration easily or the authentication flow creates confusion across devices, the deployment is not mature. Successful adoption should reduce friction while preserving access assurance and limiting help desk burden.

Q: Should customer IAM teams keep passwords as a fallback when deploying passkeys?

A: Yes, in most environments they should keep controlled fallback paths during migration, but those paths need explicit boundaries. The goal is to reduce password dependence over time, not to let fallback methods become the permanent primary control for customer authentication.


Technical breakdown

Why passkeys are phishing-resistant in customer IAM

Passkeys replace shared secrets with asymmetric cryptography. The private key stays on the user’s device or authenticator, while the service stores only the public key and challenge-response parameters. That means there is no password to steal, reuse, or relay through a fake login page. In customer environments, the practical value is not only reduced phishing exposure, but also lower dependence on password reset and MFA recovery paths that often become support-heavy and attack-prone. Because the credential is bound to the origin, attackers cannot simply replay captured authentication data elsewhere. This is why passkeys change the security baseline rather than merely adding another login factor.

Practical implication: treat passkeys as a credential model change and redesign recovery, fallback, and enrollment around origin-bound authentication.

Why customer IAM readiness lags behind passkey adoption

Passkey adoption usually stalls at the integration layer, not the cryptography layer. Many organisations still rely on legacy auth stacks, fragmented product teams, and developers with limited auth experience to deliver customer-facing identity. That creates partial rollout, where passkeys exist in one journey but passwords remain the default across others. In practice, the hardest work is orchestration across existing CIAM flows, device support, account recovery, and step-up controls. A passkey programme fails when teams treat it as a single feature toggle instead of a lifecycle change in how customers enroll, authenticate, and recover access.

Practical implication: map every customer auth journey before rollout so passkeys do not become an isolated exception path.

How hybrid authentication changes the control model

Most organisations will not remove passwords immediately. They will run passkeys alongside passwords, one-time passwords, magic links, and risk-based step-up controls while they prove business value and user acceptance. That means the control model becomes hybrid, with different authentication methods serving different assurance levels and journey states. The governance question is no longer whether passkeys exist, but where they are mandatory, where they are optional, and where fallback methods reintroduce risk. Customer IAM teams need a clear view of which flows are primary, which are transitional, and which remain exceptions for compatibility reasons.

Practical implication: define where passkeys are primary, where fallback is allowed, and which journeys still depend on passwords or OTPs.


NHI Mgmt Group analysis

Passkey adoption is now constrained by operating model maturity, not user demand. Consumers are ready to use passkeys, and many organisations have started deployment, but that does not mean customer IAM programmes are ready to absorb them cleanly. The real constraint is whether identity teams can rework enrollment, recovery, and step-up flows without leaving passwords as the hidden control plane. The practitioner conclusion is that adoption metrics alone do not equal readiness.

Customer-facing passkeys expose a CIAM ownership gap that most organisations still understate. The article points to developers with minimal auth experience and to legacy-system drag, which means passkeys are often being bolted onto systems that were never designed for graceful method coexistence. That is a governance issue because accountability for authentication quality becomes diffuse across product, platform, and security teams. The practitioner conclusion is to assign clear ownership before rollout fragments into inconsistent flows.

Hybrid authentication will define the next phase of passwordless maturity. For most organisations, passkeys will coexist with passwords and fallback methods for some time, especially in recovery and low-support environments. That means the control question shifts from replacement to containment: where do weaker methods remain, and how tightly are they bounded? The practitioner conclusion is that passwordless maturity will be measured by reduction in password dependence, not by a binary cutover.

Passkey migration should be governed as customer journey architecture. The article shows that lower-stakes flows such as signup, recovery, and step-up are the safest entry points because they let teams prove outcomes before altering primary login. That sequencing matters because it reduces operational risk while building evidence for broader change. The practitioner conclusion is to treat each journey as a separate governance decision, not a single rollout event.

From our research library:

What this signals

Passkey adoption is becoming a governance problem, not just a UX upgrade. As more customer journeys shift toward passwordless sign-in, teams have to decide where fallback is acceptable, where it is not, and how to stop hybrid authentication from ossifying into permanent password dependence. The operating model matters as much as the cryptography because the control boundary moves from the password to the journey.

Customer IAM teams should expect migration pressure to rise before full replacement becomes realistic. Most organisations will need passkeys to coexist with passwords, OTPs, and magic links for a transition period, which means policy clarity and ownership are more important than a single cutover date. The programme that wins is the one that can measure success by journey, not just by feature rollout.


For practitioners

  • Map customer authentication journeys Inventory every customer sign-in, signup, recovery, and step-up path before introducing passkeys so you can see where passwords still anchor the experience.
  • Start with lower-stakes flows Pilot passkeys in signup, account recovery, or step-up authentication first, where you can measure adoption and failure patterns without disrupting the primary login path.
  • Define fallback rules explicitly Document where passwords, OTPs, or magic links remain acceptable and what conditions trigger them, so hybrid authentication does not quietly become permanent password dependence.
  • Assign CIAM ownership clearly Name the team responsible for passkey rollout, authentication recovery, and auth method policy so delivery does not fragment across developers with minimal auth experience.
  • Measure support and success outcomes Track sign-in success rates, recovery volume, and login-related tickets alongside security outcomes to judge whether passkeys are improving the programme rather than just adding another option.

Key takeaways

  • Passkeys are gaining traction, but customer IAM readiness still lags because most organisations have not fully reworked the journeys that depend on passwords.
  • The article’s data shows meaningful adoption momentum, yet it also shows that partial deployment can leave the old authentication model intact in practice.
  • The practical response is to govern passkeys as a staged CIAM migration, with clear ownership, explicit fallback boundaries, and measured rollout paths.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP ASVS, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP ASVSV6 — AuthenticationPasskeys are an authentication method change for customer login journeys.
Recommendation — Use V6 to verify passkey enrollment, authentication, and fallback behaviour across customer journeys.
NIST SP 800-63SP 800-63B — AuthenticationThe article centres on customer authentication methods and assurance choices.
Recommendation — Apply SP 800-63B to align passkey and fallback authentication with assurance requirements.
NIST Zero Trust (SP 800-207)Authentication policy and continuous verification — Authentication policy and continuous verificationPasskeys fit a broader zero trust approach to reducing credential replay risk.
Recommendation — Align customer authentication policy with zero trust principles and minimise reusable secrets.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsCustomer authentication method choice affects access and authorization controls in CIAM.
Recommendation — Review authentication paths under PR.AA-05 to ensure access decisions match intended assurance.

Key terms

  • Passkey: A passkey is a passwordless credential based on public key cryptography. A private key stays on the user’s device, while a public key is stored by the service. During login, the device signs a challenge after local unlock, which reduces phishing and eliminates shared secret reuse.
  • Customer Identity And Access Management: Customer Identity and Access Management is the discipline of governing how external users sign in, recover access, and move through digital services. It combines authentication, profile management, and lifecycle control so organisations can deliver secure, low-friction experiences at scale.
  • Passwordless Authentication: An authentication approach that removes passwords and uses a device-bound cryptographic key plus local user verification. It reduces phishing and replay risk, but it only improves assurance when enrollment, recovery, and revocation are tightly governed.
  • Hybrid Authentication: Hybrid authentication is an environment where passwordless methods, passwords and MFA all coexist during migration or by design. It creates governance complexity because assurance, fallback rules and user experience must remain consistent across different applications and risk levels.

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 building or maturing an IAM programme, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on June 5, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org