Passkey adoption is rising, but customer IAM readiness lags

At a glance

What this is: Passkey adoption is accelerating, but most customer identity programmes still depend on passwords and lack the engineering capacity to move faster.

Why it matters: IAM teams need to treat passkeys as a migration and operating-model problem, not just an authentication feature, because readiness gaps shape phishing resistance, UX, and support load.

By the numbers:

• 75% of global consumers now recognize passkeys, and 28% enable them whenever possible.
• 87% of organizations still use passwords for customer-facing auth, while only 2% believe passwords balance security and UX.
• 45% of organizations have deployed passkeys in at least one app, and 27% expect to within two years.

👉 Read Descope's passkey adoption analysis for customer IAM teams

Context

Passkeys are a phishing-resistant authentication method that replaces shared secrets with device-bound public key cryptography. The core issue in this post is not whether passkeys work, but whether customer IAM programmes can absorb them without stalling on legacy architecture, limited engineering capacity, and partial rollout patterns.

For IAM leaders, the governance question is broader than login UX. Passkey adoption affects authentication policy, recovery flows, step-up design, support load, and how quickly organisations can reduce password dependence without creating a fragmented identity journey.

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 passkeys often fail to replace passwords quickly?

A: Because the barrier is usually programme readiness, not user demand. Legacy systems, limited authentication expertise, and competing product priorities slow implementation. Most organisations end up layering passkeys onto existing flows instead of redesigning the identity journey, which preserves compatibility but delays the security and operational benefits.

Q: How do security teams know whether passkeys are working well?

A: Look at sign-in success rate, average login time, recovery friction, and login-related ticket volume. If passkeys are deployed but the organisation still sees high failure rates, heavy support demand, or widespread fallback use, the implementation is incomplete or poorly governed. Adoption counts alone do not prove the programme is effective.

Q: Should passkeys replace passwords entirely in customer IAM?

A: Not usually at the beginning. Most organisations will operate a hybrid model for a long period, especially where legacy applications, device constraints, or risk-sensitive recovery flows still depend on passwords or other fallback methods. The practical goal is controlled reduction of password dependence, not an abrupt cutover.

Technical breakdown

Why passkeys are resistant to phishing

Passkeys use public key cryptography, so no reusable secret is transmitted during login. The private key stays on the user’s device, while the relying party verifies the signature against the stored public key. This removes the shared-secret pattern that makes passwords vulnerable to phishing, replay, and credential stuffing. In practice, the authentication ceremony is bound to the app or domain, which makes fake login pages far less useful to attackers than they are against password-based flows.

Practical implication: treat passkeys as a control that changes the trust model, not just the login experience.

Hybrid passkey deployment and fallback flows

Most organisations are not replacing passwords overnight. They are adding passkeys to selected journeys such as signup, recovery, and step-up authentication while retaining passwords, OTPs, or magic links as fallback paths. That hybrid model reduces migration risk, but it also creates governance complexity because multiple authentication methods must be maintained consistently across policy, support, and telemetry. The identity stack must understand when passkeys are primary, when they are optional, and when fallback methods are acceptable.

Practical implication: design passkey policy with explicit fallback rules, not informal user-by-user exceptions.

Why passkey readiness becomes an operating model issue

The bottleneck is often not the credential type itself but the team structure around it. If developers with minimal auth experience are responsible for customer identity, passkey implementation tends to be partial, inconsistent, and delayed by competing roadmap priorities. That means authentication modernisation becomes a delivery and governance problem, not a purely technical one. Programmes that keep passwords in place everywhere while adding passkeys only in isolated flows often fail to capture the security and support benefits that justify adoption.

Practical implication: assign clear ownership for CIAM policy, rollout sequencing, and recovery design before expanding passkeys.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Passkey adoption is now a governance problem, not a proof-of-concept problem. Consumer familiarity has moved far enough that the constraint is no longer user awareness. The limiting factor is whether customer identity teams can standardise policy, recovery, and rollout across existing systems without creating authentication drift. That makes passkey work a programme-level decision, not a feature toggle.

Hybrid authentication will dominate because most organisations are still anchored to password-era architecture. The article shows a practical reality: organisations add passkeys in a few places, then leave passwords as the default everywhere else. That pattern preserves compatibility, but it also delays the security and UX gains that passkeys are supposed to deliver. IAM teams should expect coexistence, not replacement, as the near-term operating model.

Passkeys change the economics of identity support as much as the security posture. Faster sign-ins and fewer login failures reduce friction for users and service desks alike. That matters because the business case increasingly depends on measurable operational outcomes, not abstract security improvement. For practitioners, the signal is clear: authentication modernisation must be evaluated through success rate, recovery burden, and ticket volume, not just phishing resistance.

Customer identity teams need a named passkey migration concept: staged authentication modernization. The article’s lower-stakes rollout advice maps to a controlled adoption model where signup, account recovery, and step-up paths are used to prove internal value before broader deployment. That approach acknowledges the real constraint is organisational readiness, not technical possibility. Practitioners should structure passkey adoption as a phased migration with explicit exit criteria.

From our research:

• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate, according to AI Agents: The New Attack Surface report.
• Only 44% of organisations have implemented any policies to govern AI agents, even though 92% agree governance is critical to enterprise security.
• For the broader identity picture, read Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for lifecycle controls that also shape passwordless and federated access decisions.

What this signals

Passkey programmes are moving from product feature to operating model, which means the next constraint is ownership, not awareness. Teams that treat authentication modernisation as a shared delivery concern across product, security, and identity are more likely to avoid fragmented fallback logic and inconsistent recovery paths.

Authentication modernisation debt: organisations often introduce passkeys before they have a coherent plan for recovery, policy, and exception handling. That creates a hidden dependency on password-era processes even when the login experience looks modern. The practical lesson is to map where the old model still governs the new one.

As passwordless adoption grows, the governance question will increasingly overlap with broader identity standards and control design. If your programme is also dealing with machine access, service accounts, or agentic workloads, the same lifecycle discipline that applies to humans must also be applied consistently across identity types.

For practitioners

• Start with low-stakes authentication flows Deploy passkeys first in signup, account recovery, and step-up journeys where fallback options already exist and rollback is manageable.
• Define fallback policy before rollout Decide which users, devices, and risk states can use OTPs, magic links, or passwords so fallback does not become an uncontrolled permanent path.
• Assign a named owner for CIAM modernisation Give one team authority over authentication policy, recovery design, and migration sequencing so passkey work is not fragmented across product teams.
• Measure success beyond adoption counts Track sign-in success rate, authentication time, recovery volume, and login-related tickets to understand whether passkeys are actually improving the identity journey.

Key takeaways

• Passkeys are winning attention, but most customer identity programmes still run on password-era assumptions and legacy process ownership.
• The evidence points to a hybrid future: passkeys are being added in targeted flows while passwords remain the default in many organisations.
• The practical control point is not adoption alone, but whether teams can govern fallback, recovery, and measurement as part of one migration plan.

Key terms

• Passkey: A passkey is a phishing-resistant login credential based on public key cryptography. The private key stays on the user’s device and the service verifies a signed challenge, which removes the reusable shared secret that makes passwords easy to steal and replay.
• Customer Identity And Access Management: Customer identity and access management, or CIAM, governs how external users register, authenticate, recover access, and move through digital services. It must balance security, scale, and usability because authentication failures directly affect conversion, support cost, and trust.
• Fallback Authentication: Fallback authentication is an alternate login path used when the preferred method is unavailable, such as OTPs, magic links, or passwords. In passkey programmes, fallback must be explicitly governed so it does not become the de facto permanent control and erase the security benefit.
• Phishing-Resistant Authentication: Phishing-resistant authentication is any method that cannot be tricked into revealing reusable secrets to a fake site or intermediary. Passkeys are a common example because they bind the credential to the legitimate service and the user’s device, limiting replay and interception.

Deepen your knowledge

Passkey adoption, fallback design, and authentication modernisation are covered in the NHI Foundation Level course, the industry's only accredited NHI security programme. If you are mapping passwordless rollout against existing IAM and CIAM constraints, it is a useful place to start.

This post draws on content published by Descope: Passkey Trends for 2026: What the Data Says. Read the original.