TL;DR: Passkeys are gaining momentum as Apple, Google, Microsoft, FIDO Alliance and major brands report broad support and adoption, while consumers increasingly recognise the model and regulators accept it for secure authentication. The real challenge is not whether passkeys work, but how to roll them out without breaking recovery, consistency or hybrid access paths.
At a glance
What this is: Passkeys are moving into mainstream customer authentication, with strong platform support and growing adoption, but rollout still hinges on recovery, UX consistency and hybrid login support.
Why it matters: For IAM practitioners, passkeys matter because they change how customer identity, recovery and step-up authentication are designed across human, NHI and adjacent automation touchpoints.
By the numbers:
- More than 15 billion accounts are enabled for passkeys.
- Google has logged 2.5 billion passkey authentications across 800 million accounts.
- Amazon reports 175 million users with passkeys.
- TikTok saw login times improve 17x after enabling them.
👉 Read Strivacity's analysis of passkey adoption and rollout strategy
Context
Passkeys are a passwordless authentication method that binds sign-in to a device and a local biometric or device unlock factor. For customer identity teams, the central issue is not whether the login ceremony is modern, but whether the surrounding recovery, enrollment and fallback flows can operate safely across mixed device and application estates.
The article argues that platform support, device penetration and regulatory acceptance have lowered the adoption barrier, but the operational problem has shifted to implementation consistency. That makes passkeys a CIAM governance issue, not just a user experience choice, because the weakest recovery path or the most fragmented app path can reintroduce the very risks passwordless was meant to reduce.
In practice, passkey programmes are now judged by whether they can coexist with passwords, MFA, device replacement and account recovery without creating support overload or security regressions. That is a familiar pattern in identity modernisation: adoption succeeds when the programme is designed around user reality, not around the cleanest demo flow.
Key questions
Q: How should security teams roll out passkeys without breaking customer login flows?
A: Start with an opt-in model, keep passwords plus MFA available during transition, and standardise one policy across all applications. The aim is to avoid fragmented login behaviour, inconsistent assurance and support churn. A controlled rollout also lets teams validate recovery, device replacement and step-up paths before passkeys become the default.
Q: Why do passkey programmes still fail if passwords are removed?
A: Removing passwords does not remove the need for recovery, enrollment and fallback governance. If the account recovery path is weak, attackers can bypass the stronger primary login path through support channels, device rebind or poorly verified resets. The real control question is whether the weakest path still meets the organisation’s assurance target.
Q: What do organisations get wrong about passkey adoption?
A: They often treat it as a front-end authentication change instead of a lifecycle and policy change. That leads to inconsistent treatment across apps, unclear fallback rules and unmanaged recovery risk. Teams should govern passkeys as part of customer identity architecture, not as a single login feature.
Q: How do you know if passkeys are actually improving security?
A: Look for fewer password-reset events, lower phishing exposure on supported journeys, and stable or improving completion rates for enrollment and recovery. If support tickets rise sharply or fallback use dominates, the programme may be shifting risk rather than reducing it. The best signal is improved assurance without degraded account access.
Technical breakdown
Passkey authentication and platform-bound credential storage
Passkeys use public key cryptography to replace shared secrets with a private key stored on the user’s device and a public key registered to the service. The user unlocks the device with biometrics or a local PIN, but the biometric itself is not sent to the application. This changes the attack surface by removing password reuse, phishing replay and credential stuffing from the primary path. The remaining risk shifts to device compromise, registration control and recovery design, which are governance problems rather than protocol flaws.
Practical implication: treat passkey rollout as a device-and-recovery control programme, not just a sign-in UI update.
Hybrid authentication paths in CIAM environments
Most customer estates will not go passwordless overnight. Hybrid environments therefore keep passwords, MFA, passkeys and recovery flows active at the same time, which creates policy drift if the application layer handles each path differently. Consistent assurance depends on clear routing rules for when passkeys are preferred, when passwords remain allowed, and how step-up occurs for higher-risk actions. Without that consistency, users experience fragmented login behaviour and security teams inherit unclear assurance levels across channels.
Practical implication: define one authentication policy model across all apps before scaling passkeys beyond early adopters.
Recovery, device replacement and account rebind controls
Passkeys reduce dependence on memorised secrets, but they raise the importance of recovery because losing a device can sever the user’s normal authentication path. Recovery must therefore be treated as a privileged identity event, with stronger verification than routine login and with careful controls around device rebind, fallback factors and support-assisted reset. In CIAM programmes, weak recovery often becomes the back door that neutralises the benefits of strong authentication.
Practical implication: design recovery as a high-assurance workflow with stricter checks than initial enrollment.
Breaches seen in the wild
- Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
- AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Passkeys are becoming a customer identity control, not a novelty feature. The adoption signals in the article show that ecosystem readiness has crossed a practical threshold, which means the remaining blockers are now governance and operational design. When authentication is easier to use and harder to phish, the question shifts to whether the organisation can standardise it across channels without creating exceptions that reintroduce legacy risk. Practitioners should treat passkeys as a mainstream CIAM control path, not a pilot.
The real failure mode is recovery, not cryptography. Passkeys replace shared secrets with asymmetric authentication, but the programme still depends on recovery paths, device replacement and support-assisted rebind. That is where assurance can collapse if the fallback path is weaker than the primary path. Teams should view recovery as part of the authentication architecture, because a strong front door with a weak side door still leaves the identity programme exposed.
Platform lock-in creates an identity governance constraint, not just a UX trade-off. Apple, Google and Microsoft support makes adoption possible, but it also ties the user experience to ecosystem-specific behaviours that organisations do not fully control. That means passkey strategy needs policy decisions about portability, support, and fallback criteria, especially in hybrid estates where different applications mature at different speeds. Practitioners should standardise the policy layer before scaling the credential layer.
CIAM modernisation succeeds when trust is rebuilt in the flow, not asserted in policy text. The article’s rollout advice aligns with a broader identity pattern: users adopt strong controls when they understand the benefit and when recovery feels safe and predictable. For security leaders, that means passkey programmes should be governed like any other authentication change. The practical test is whether the new path improves assurance without multiplying ambiguity elsewhere in the login lifecycle.
From our research:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant behaviour gap that identity programmes often underestimate.
- That same control gap is why passkey rollout should be paired with governance over recovery and fallback flows, as explored in Ultimate Guide to NHIs , Key Challenges and Risks.
What this signals
Passkey adoption will expose which CIAM programmes still treat recovery as an afterthought. The next governance question is not whether passkeys are supported, but whether the organisation can keep the fallback path stronger than the old password path. Teams that leave recovery loosely governed will find that passwordless simply moves risk into account rebind and support-assisted resets.
With 43% of security professionals concerned about AI systems learning and reproducing sensitive information patterns from codebases, identity teams should expect stronger pressure to reduce shared secrets wherever possible. That concern aligns with broader passwordless adoption, but it does not reduce the need to govern enrollment, device trust and support escalation carefully. Stronger authentication only helps if the surrounding lifecycle is equally disciplined.
Passkey programmes should be evaluated alongside the broader identity lifecycle, not as isolated authentication projects. Standardising the credential layer without standardising policy across applications creates uneven assurance and operational debt. For practitioners, the signal is clear: authentication modernisation succeeds when governance, recovery and user education move together.
For practitioners
- Standardise a single passkey policy model Define where passkeys are preferred, where passwords remain available, and how step-up is triggered for sensitive transactions across every customer-facing application.
- Treat recovery as a high-assurance workflow Require stronger identity verification for device loss, device replacement and account rebind than you use for ordinary sign-in or self-service reset.
- Preserve secure fallback paths during migration Keep passwords plus MFA available for users who are not ready for passkeys, but prevent fallback paths from becoming the default weak link in the journey.
- Test adoption by segment before broad rollout Start with opt-in cohorts, measure conversion and support demand, then expand only after you have confirmed that enrollment, recovery and login are stable.
Key takeaways
- Passkeys are now a mainstream authentication option, but their success depends on governance outside the login prompt.
- Recovery is the critical control point because a weak fallback path can erase the security gains of passwordless sign-in.
- Identity teams should standardise policy, not just technology, if they want passkey adoption to scale safely across customer apps.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
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.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Passkeys are a digital identity authentication method for customer sign-in. | |
| NIST Zero Trust (SP 800-207) | PR.AC-1 | Passkeys support continuous verification in customer access journeys. |
| NIST CSF 2.0 | PR.AC-7 | Strong authentication and recovery design both fit CSF access control outcomes. |
Use NIST digital identity guidance to set assurance targets for passkey enrollment and recovery.
Key terms
- Passkey: A passkey is a passwordless authentication credential that uses public key cryptography to prove device possession and local user verification. The private key stays on the user’s device, while the service stores only the public key, reducing phishing and credential reuse risk.
- Customer Identity And Access Management: Customer Identity and Access Management is the discipline of governing how external users register, authenticate, recover access and maintain account trust. In practice, it includes login journeys, recovery flows, step-up checks and policy consistency across applications and channels.
- Recovery Flow: A recovery flow is the controlled process used when a user loses access to their primary authentication method. It is a high-risk identity path because attackers often target resets, device replacement and support-assisted verification to bypass stronger primary authentication.
- 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
Passkey adoption, recovery governance and hybrid authentication design are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are modernising customer identity or planning a passwordless rollout, it is worth exploring.
This post draws on content published by Strivacity: Passkeys are taking off, what is still standing in the way, and how to roll them out. Read the original.
Published by the NHIMG editorial team on 2026-06-04.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org