Passkey adoption is reshaping customer login and recovery

At a glance

What this is: This is a CIAM-focused analysis of why passkeys are gaining adoption and where login and recovery design still break down.

Why it matters: It matters because identity teams have to support passwordless login without creating brittle recovery paths, fragmented customer journeys, or inconsistent assurance across apps.

By the numbers:

• More than 15 billion accounts are enabled for passkeys, according to Strivacity.
• Google has logged 2.5 billion passkey authentications across 800 million accounts, according to Strivacity.
• Amazon reports 175 million users with passkeys, according to Strivacity.
• TikTok saw login times improve 17x after enabling passkeys, according to Strivacity.

Context

Passkeys are a customer authentication method that replaces passwords with device-bound credentials and user verification such as a face or fingerprint. In CIAM, they matter because they change the centre of gravity from memorised secrets to recovery design, device trust and cross-app consistency.

The article argues that the adoption curve is being driven by platform support, smartphone readiness and regulatory recognition. The governance gap is that many customer journeys still assume passwords and SMS can act as universal fallback, even as users move toward passwordless sign-in.

That makes passkeys a lifecycle and recovery problem as much as a login problem. Organisations that introduce them without a clear customer recovery model risk trading phishing resistance for confusion, fragmentation and avoidable account lockout.

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: What breaks when passkey recovery is not governed properly?

A: The programme falls back to the weakest legacy recovery path, which attackers often target first. If help-desk verification, device replacement, or fallback login is inconsistent, the user can still be phished or socially engineered even when the primary login is passkey-based.

Q: When should organisations keep passwords and MFA alongside passkeys?

A: Keep them during transition periods, for customer segments that are not yet passkey-ready, and wherever recovery assurance is still being proven. Hybrid access is a bridge, not the destination, but it prevents avoidable lockout and abandonment.

Q: Why do passkeys need a single enterprise-wide policy?

A: Because inconsistent browser, device and app behaviour quickly creates different recovery paths and different user expectations. A single policy gives CIAM teams one assurance model, one customer message and one way to govern sign-in across the portfolio.

Technical breakdown

Why passkeys work in CIAM environments

Passkeys are asymmetric credentials stored on a user device and released only after local verification, which means the secret never has to be typed or copied into a login form. That reduces phishing exposure because the credential is bound to the relying party and cannot be replayed in the same way as a password or one-time code. In customer identity, the operational value comes from moving authentication from knowledge to possession plus inherence, while keeping the flow familiar enough for mainstream users. The implementation challenge is less about protocol theory and more about app and browser consistency across devices and recovery states.

Practical implication: treat passkeys as an authentication pattern that must be standardised across customer journeys, not as a single feature toggle.

What breaks when recovery still depends on passwords or SMS

Recovery is the weakest part of many passwordless rollouts because it often reintroduces the very factors passkeys are meant to remove. If a customer loses a device, swaps phones, or changes browser ecosystems, the fallback path has to restore access without lowering assurance below the original sign-in method. That is why vendor-managed recovery alone is not enough. The article points to secure fallback options and identity verification for higher-risk accounts because recovery becomes an identity proofing event, not just a support task. Without that design, passwordless authentication only shifts the problem rather than eliminating it.

Practical implication: design recovery as a governed assurance step with explicit fallback controls for lost-device and account-replacement scenarios.

How ecosystem lock-in affects passkey governance

Passkeys are tied to the major platform ecosystems, so customer experience can vary by browser, device family and operating system. That matters for governance because inconsistent prompts and account binding rules create trust issues even when the cryptography is sound. In CIAM, the risk is not only technical incompatibility but a fractured policy model where one app accepts passkeys cleanly and another falls back to weaker methods. Strivacity's article reflects a broader industry reality: adoption depends on whether organisations can enforce one cross-app experience rather than letting each application improvise its own pattern.

Practical implication: define one enterprise passkey policy and enforce it across all customer applications and recovery journeys.

NHI Mgmt Group analysis

Passkey adoption is now a customer identity governance issue, not just an authentication upgrade. Once passkeys move beyond pilot use, the real decision shifts from whether they work to whether the organisation can govern them consistently across applications, devices and recovery journeys. That makes CIAM architecture, not just login UX, the critical control plane. The practitioner conclusion is clear: passwordless programmes succeed only when the governing model is consistent end to end.

Recovery is the pressure point that determines whether passwordless reduces or redistributes risk. A passkey programme that falls back to weak support flows simply moves the trust problem from login to account rescue. The article's emphasis on secure fallback and identity verification reflects a wider pattern in customer identity: recovery is where assurance is either preserved or lost. Practitioners should treat recovery as part of authentication policy, not as an afterthought handled by support teams.

Platform dependence creates a governance gap that many customer identity programmes under-estimate. Passkeys rely on operating-system and browser ecosystems, which means assurance and usability are shaped by providers outside the organisation's direct control. That does not make passkeys unsuitable, but it does mean policy cannot be written as if every customer arrives through the same device stack. The practitioner conclusion is to design for controlled inconsistency while keeping the assurance floor high.

Standardisation across apps is the named concept that will separate durable passkey deployments from fragmented ones. A passkey can be technically valid and still fail operationally if each application implements its own prompts, fallback logic and recovery sequence. That creates customer confusion, support load and uneven assurance. The practitioner conclusion is to standardise login and recovery policy before broad rollout, or the programme will inherit password-era inconsistency under a new authentication layer.

From our research library:

• eBay's passkey data shows 55-60% of passkey adoption happens on mobile, against around 20% on desktop.

What this signals

Standardised recovery is the real control maturity marker for passwordless CIAM. Organisations will increasingly be judged not by whether they support passkeys, but by whether customers can move between devices and apps without losing assurance or creating help-desk dependency. That pushes passkey governance into the same conversation as lifecycle design, support design and identity proofing.

Passkey programmes fail when each application invents its own exception path. The strategic move is to treat login, device change and account recovery as one policy surface, then enforce consistency across the customer estate. That is where the governance value sits: reducing variation before it becomes operational debt.

For practitioners

• Standardise passkey policy across all customer apps Define one approved customer authentication pattern for enrollment, sign-in, and recovery so every app uses the same assurance rules and fallback sequence.
• Design recovery as a governed assurance step Require secure fallback options, device-loss handling, and identity verification for higher-risk accounts before you expand passwordless sign-in.
• Keep hybrid access available during rollout Support passwords plus MFA alongside passkeys while adoption matures, so early failures do not block customers who are not yet ready to switch.
• Educate customers at high-intent moments Introduce passkeys during sign-up, password reset, and account recovery flows where users are already expecting a change in authentication behaviour.

Key takeaways

• Passkeys improve customer authentication, but their real governance challenge is recovery, not cryptography.
• Adoption is already substantial, yet platform dependency and inconsistent user journeys still block clean rollout at scale.
• The organisations that standardise login and recovery across apps will turn passwordless access into a durable CIAM pattern.

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.
• Account Recovery: Account recovery is the process used to restore access when a user cannot authenticate normally. In mature IAM programmes, recovery is treated as part of the trust chain because a weak reset path can bypass stronger login controls and become the easiest route to account takeover.

Deepen your knowledge

Identity lifecycle management, secrets management, and workload identity security 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.