TL;DR: Passkeys are moving from pilot to production at scale, with more than 3 billion in use worldwide, but conference sessions showed that the hard problems are enrolment timing, recovery, platform variance, and post-authentication trust, according to OneSpan and FIDO Alliance discussions. Authentication now has to be treated as part of the full account lifecycle, not a single login control.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on OneSpan's blog post: Passkeys behave at scale in ways that make adoption depend less on the protocol itself than on enrolment timing, platform experience, and lifecycle controls around recovery and post-login trust.
Why it matters: It matters because identity teams implementing passkeys have to govern the full journey from enrolment to recovery and session assurance, not just replace passwords at the login prompt.
Context
Passkeys are a login control, but at scale they quickly become an identity lifecycle problem. Once organisations move beyond pilot deployments, the practical questions shift to enrolment timing, recovery paths, platform variance, and what happens after authentication succeeds.
In this article, OneSpan describes what practitioners are learning from real-world deployments and conference discussions. The core issue is that authentication alone does not close the trust gap if account recovery, device change, and post-authentication protections still rely on weaker paths.
Key questions
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: Why do passkey rollouts often look better on mobile than on desktop?
A: Mobile users are already trained to use biometrics and device-bound authentication, so the interaction feels familiar. Desktop adoption depends more on browser support, platform consistency, and user habit, which creates uneven results across environments. Teams should interpret adoption by channel, not as a single enterprise average.
Q: How should teams implement passkeys across the full account lifecycle?
A: They should govern enrolment, recovery, device replacement, and post-login session assurance as one lifecycle, not as separate workstreams. A passkey rollout is incomplete if the surrounding processes still permit weaker authentication paths to re-enter the account. The control objective is continuity of assurance across the account journey, not only a stronger first login.
Q: Should organisations replace passwords everywhere before improving password recovery?
A: No. Teams should first make recovery and support paths consistent, because users judge the new authentication model by what happens when something goes wrong. If fallback is messy, passwordless adoption suffers even when the primary login is strong. A clean recovery design is part of the control, not an afterthought.
Technical breakdown
Why passkey adoption depends on enrolment timing
Passkey enrolment is not just a technical registration step. It is a user-journey decision that changes materially based on when the prompt appears. If users are asked immediately after account creation or a successful sign-in, they are more likely to adopt the new method because the trust context is already active. If the prompt arrives at the wrong moment, users defer or ignore it. This makes enrolment timing part of the authentication architecture, not a marketing or UX afterthought.
Practical implication: place enrolment prompts at moments of existing user trust, not as standalone conversion events.
Platform variance changes passkey outcomes
Passkeys do not behave identically across devices and operating systems. The article highlights a strong mobile skew, with mobile users more willing to adopt biometric flows because the interaction model already feels familiar. Desktop environments are less uniform, and browser behaviour can vary enough to affect adoption and support outcomes. That means passkey rollout metrics should be segmented by platform, not treated as one global adoption curve. The same policy can produce very different user behaviour depending on where the authentication happens.
Practical implication: measure passkey adoption separately for mobile and desktop so platform friction does not hide weak rollout performance.
Why authentication does not equal account trust
A passkey can secure entry, but it does not automatically secure the account lifecycle around it. If SMS recovery, password reset links, or other fallback paths remain available, an attacker can bypass the stronger method by targeting the weaker one. This is the central architectural lesson in the article: authentication controls are only as strong as the weakest recovery and re-authentication path. The control surface therefore includes enrolment, recovery, device change, and post-login session assurance, not just the primary login ceremony.
Practical implication: remove or harden weaker recovery paths before treating passkeys as the primary trust control.
NHI Mgmt Group analysis
Passkey programmes fail when teams treat authentication as a point control rather than a lifecycle control. The article shows that the hardest problems appear after the cryptographic login is already working, especially around recovery, device replacement, and fallback authentication. That means the real governance question is not whether passkeys function, but whether the surrounding identity process preserves their assurance under change. Practitioners should govern the whole account journey, not just the login ceremony.
Enrolment timing is a trust-design decision, not a rollout detail. Asking users to adopt passkeys at the wrong moment produces avoidable resistance even when the technology is sound. That makes adoption dependent on interaction context, which is an identity design variable teams too often leave outside security governance. The practitioner takeaway is to manage passkey enrolment as part of access journey design.
Platform-specific behaviour is now a first-order identity metric. Mobile adoption and desktop adoption are not interchangeable signals, because the user expectations, browser experience, and biometric norms differ materially. This creates a platform fragmentation problem for identity teams that report a single adoption rate without separating usage contexts. Practitioners should treat platform variance as an operating condition, not an implementation defect.
Authentication-only thinking is now a policy gap, not a mature stance. Once recovery links, SMS fallbacks, and post-login token risks remain in the environment, the organisation has not actually replaced password trust with passkey trust. The named concept here is login-lifecycle discontinuity: security is strong at the door but weak in the corridors that follow. Identity programmes need to govern those corridors as part of the same assurance model.
Passkeys are becoming an account-security baseline, but they do not remove the need for broader identity proofing and fraud controls. The article is explicit that trust extends beyond the login event, especially in environments facing AI-enabled fraud and session theft. That means IAM, identity proofing, and fraud detection now intersect more tightly than many rollout plans assume. Practitioners should align those disciplines before passkey scale exposes the seams.
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
Passkey rollout metrics should no longer be reported as a single adoption number. Identity teams need to separate enrolment success, recovery success, and platform-specific usage, because the real failure points emerge when those measures are blended into one headline rate.
Login-lifecycle discontinuity: the organisation may have a strong authentication method at entry while still relying on weaker fallback paths elsewhere in the account journey. That gap is where passkey programmes either mature into real assurance or stall as partial replacements for passwords.
For practitioners
- Map the full account journey Document enrolment, recovery, device change, and sign-in fallback paths as one control chain, then identify where weaker methods can still override a passkey.
- Move enrolment to trusted moments Trigger passkey registration immediately after account creation or a successful sign-in, when the user is already authenticated and more likely to complete the flow.
- Segment adoption by platform Track mobile and desktop adoption separately, and review browser or OS-specific drop-offs before assuming the rollout has a single success rate.
- Remove weak recovery paths Retire SMS recovery and unsecured password reset flows where passkeys are meant to carry the primary trust burden.
- Treat session security as part of passkey governance Assess whether token theft and session hijack protections are aligned with the assurance level created at login.
Key takeaways
- Passkeys reduce login friction only if the surrounding account processes stop undermining them with weaker recovery and reset paths.
- The article’s evidence points to a scale problem, not a protocol problem: adoption depends on timing, platform experience, and lifecycle design.
- Security teams should govern passkeys as part of end-to-end identity assurance, with recovery and session controls carrying as much weight as enrolment.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article centres on passkey adoption and the trust assumptions around authentication flows. |
| NHI-01 — Improper Offboarding | Device change and account recovery highlight lifecycle gaps when authenticators or devices change. | |
| Recommendation — Assess whether passkeys are replacing weaker authentication paths rather than sitting beside them. Tie authenticator recovery and replacement to formal lifecycle controls before users switch devices. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Passkey enrolment, fallback, and recovery are authenticator lifecycle issues. |
| IA-2 — Identification and Authentication (Organizational Users) | The article is about how users authenticate across login and recovery paths. | |
| Recommendation — Apply IA-5 to govern the creation, replacement, and retirement of passkey authenticators. Use IA-2 to ensure primary authentication and recovery flows meet the same assurance target. | ||
| NIST SP 800-63 | SP 800-63B — Authentication and Lifecycle | The post is fundamentally about authentication assurance and the lifecycle around it. |
| Recommendation — Align passkey rollout and recovery design with SP 800-63B assurance expectations. | ||
Key terms
- Passkey Enrolment Fraud: Passkey enrolment fraud happens when an attacker gains temporary access to an account and registers their own device or authenticator as trusted. After enrolment, the attacker can authenticate legitimately because the system believes the new binding is valid. The weakness is not the passkey itself, but the governance around who can bind it.
- 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.
- Authenticator Lifecycle Management: Authenticator lifecycle management is the governance of a credential from issuance to renewal, replacement, and retirement. For human identity programmes, it ensures that keys, smart cards, and certificates stay tied to the right user and are removed when the user, role, or device is no longer trusted.
- Post-authentication Trust: Post-authentication trust is the assurance required after a user has already signed in. It covers session integrity, token protection, fraud detection, and step-up checks, because a strong first factor does not stop attackers from abusing an active session or stolen token.
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.
Published by the NHIMG editorial team on June 7, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org