Passkeys at scale expose the gap between login and lifecycle

At a glance

What this is: This is an independent analysis of FIDO Authenticate 2025 showing that passkeys are now a scale problem, not a proof-of-concept problem.

Why it matters: It matters because IAM teams must connect human authentication, account recovery, and session trust to NHI-style lifecycle governance as identity moves beyond passwords.

By the numbers:

• 55 to 60% of passkey adoption happens on mobile, while only 20% happens on desktop.

👉 Read OneSpan's analysis of passkeys at scale and account lifecycle security

Context

Passkeys are a stronger authentication method, but they do not automatically solve account lifecycle, recovery, or session trust. The primary issue in this article is not whether passkeys work, but how organisations move them from controlled demos into production at scale across human IAM programmes.

That gap matters because identity teams still have to manage enrolment timing, fallback methods, lost-device recovery, platform differences, and post-login assurance. OneSpan's conference notes show a mature market wrestling with operational design choices rather than basic technology adoption.

Key questions

Q: How should security teams roll out passkeys without creating recovery gaps?

A: Start with enrolment at moments of strong user intent, then harden every fallback path that can undo phishing resistance. The main risk is not the passkey itself but the recovery channel, so help-desk resets, SMS fallback, and weak forgotten-password flows need the same governance attention as the primary authenticator.

Q: Why do passkey programmes succeed on mobile faster than on desktop?

A: Mobile adoption is faster because users already trust biometrics and device-bound authentication, while desktop environments vary more in browser support, synced credential behaviour, and recovery experience. That makes mobile a more natural fit and desktop a better indicator of whether the rollout design is actually consistent.

Q: What do teams get wrong about phishing-resistant authentication?

A: They often assume that adding passkeys automatically makes the account resistant to phishing. In reality, any remaining recovery path or secondary login method that is phishable can reintroduce the same risk. True resistance depends on removing or tightly governing those alternate entry points.

Q: How can identity teams tell whether passkeys are working at scale?

A: Look beyond total enrolment and track platform-specific adoption, recovery success rates, help-desk override frequency, and post-login fraud signals. A healthy passkey programme shows low fallback usage, stable desktop behaviour, and no increase in session abuse after the primary factor is strengthened.

Technical breakdown

Why passkey adoption depends on enrolment timing

Passkeys are not adopted in a vacuum. Their success depends on when the prompt appears, what state the user is already in, and whether the flow aligns with active intent. If the user is already authenticated or creating a new account, the moment is more favourable than a later, disconnected prompt. This is why organisations see large differences between theoretical support and real-world adoption. The core mechanism is behavioural, not cryptographic: the same credential model can fail or succeed based on the interaction sequence around it.

Practical implication: place passkey enrolment at natural trust points such as signup or successful sign-in, not as an isolated later prompt.

Why platform differences change passkey outcomes

Passkeys behave differently across mobile and desktop because the surrounding authenticator ecosystem is different. Mobile users already trust biometrics and device-bound authentication, so passkeys feel native. Desktop environments depend more heavily on browser support, synced credentials, and the quality of the recovery experience. That means adoption metrics are not just a product scorecard, they are a signal of platform fit. A passkey programme that ignores these differences will misread both uptake and friction.

Practical implication: measure adoption by platform and tailor the rollout path to mobile, desktop, and browser-specific recovery constraints.

Post-authentication trust is the real control boundary

The article makes a clear distinction between authentication and trust. A passkey can secure the login step, but it does not stop abuse after the session begins. Threats such as token theft, session hijacking, and weak recovery paths can bypass strong initial authentication if the surrounding account lifecycle remains soft. In practice, this means the control boundary extends beyond the authenticator itself into recovery, session assurance, and fraud detection. Strong authentication without those layers is incomplete security.

Practical implication: pair passkeys with recovery hardening, session monitoring, and fraud controls rather than treating them as a stand-alone control.

Breaches seen in the wild

• Azure Key Vault privilege escalation exposure — Azure Key Vault Contributor role misconfiguration enabled privilege escalation.
• Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.

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 now a lifecycle governance problem, not just an authentication upgrade. The conference evidence shows organisations moving past basic implementation questions and into operational design, recovery, and scale. That shift matters because authentication events sit inside a broader identity lifecycle, and weak recovery or enrolment design can undo the assurance that the passkey itself provides. Practitioners should treat passkey rollout as part of account governance, not a front-door project.

Post-authentication trust is where many human IAM programmes still break. The article correctly separates login assurance from what happens after the session begins. That is the right frame for a world where token theft, recovery abuse, and session hijacking can bypass strong authenticators. The governance lesson is that phishing resistance is incomplete if the fallback paths remain weak or inconsistent.

Credential recovery path fragility: The hidden failure mode here is that organisations secure the primary authenticator while leaving recovery channels easier to attack than the login itself. SMS resets, forgotten-password flows, and loosely governed help-desk overrides can become the real trust bypass. The implication is that passkey maturity cannot be judged by enrolment alone; recovery is part of the control surface.

Platform-specific adoption is becoming a management signal, not just an UX metric. A 55 to 60 percent mobile adoption pattern versus 20 percent on desktop shows that identity teams need segmented governance, not averaged rollout assumptions. Mobile-native behaviour can mask poor desktop support, and that mismatch can distort programme reporting. Practitioners should use platform-specific adoption data to identify where the control model is weak, not merely where users prefer one device over another.

Passkeys expose the limits of password-era governance assumptions. Traditional account design assumes the user can be re-identified through fallback methods if the primary factor fails. Passkeys challenge that assumption because the recovery story becomes the real determinant of security posture. Organisations that keep old recovery logic in place are not fully adopting phishing-resistant authentication; they are layering it onto a weaker identity model.

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 behaviour gap that weakens governance even when policy exists.
• For the broader identity picture, see Ultimate Guide to NHIs , Why NHI Security Matters Now for how identity control gaps compound as accounts, credentials, and recovery paths expand.

What this signals

Passkey rollouts now have to be governed like lifecycle programmes, not authentication projects. When adoption is evaluated only at the point of login, teams miss the real failure surfaces in recovery, device change, platform variance, and help-desk exception handling. Lifecycle trust debt: the longer organisations keep legacy fallback paths alive, the more they dilute the value of phishing-resistant authentication.

The next maturity step is to treat the recovery stack as part of the attack surface and to measure it with the same discipline used for privileged access. In practice, that means removing unphishable login claims from phishable recovery paths and aligning reporting across mobile, desktop, and support channels.

With 43% of security professionals already worried about AI systems learning and reproducing sensitive information patterns from codebases, per The State of Secrets in AppSec, identity teams should expect authentication design, recovery design, and data handling to converge. The programmes that win will be the ones that connect login assurance to downstream trust controls instead of treating them as separate workstreams.

For practitioners

• Move enrolment into high-intent moments Trigger passkey setup immediately after account creation or a successful sign-in, when the user is already engaged and authenticated. Do not rely on detached onboarding prompts that compete with normal behaviour.
• Map every recovery path to its abuse potential Inventory SMS resets, forgotten-password flows, help-desk overrides, and device-loss handling. Remove or harden any fallback that would let an attacker bypass the phishing-resistant factor through the weakest route.
• Segment reporting by platform and browser Track adoption separately for mobile and desktop, then compare browser and authenticator behaviour so you can see where friction is structural rather than user resistance.
• Extend trust controls beyond the login step Pair passkeys with session monitoring, fraud detection, and token protection so that authentication strength is not lost after the session starts.

Key takeaways

• Passkeys are reaching scale, but the real challenge is operational governance across enrolment, recovery, and post-login trust.
• Platform differences matter because mobile and desktop adoption patterns reveal where the identity programme is structurally strong or weak.
• Security teams should treat recovery channels and session controls as part of passkey security, or phishing resistance will remain incomplete.

Key terms

• Passkey: A passkey is a phishing-resistant login credential tied to a user device and used instead of a password. It usually relies on public-key cryptography and local unlock methods such as biometrics or a device PIN, which reduces credential replay risk but does not remove recovery and session governance needs.
• Recovery Path: A recovery path is any process used to regain account access when the primary authenticator is unavailable. In practice, it often becomes the weakest part of the identity stack because SMS, help-desk reset, and email-based fallback can be easier to abuse than the original login method.
• 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

Passkeys at scale, recovery governance, and post-authentication trust are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are extending identity governance beyond the login screen, it is worth exploring.

This post draws on content published by OneSpan: FIDO Authenticate 2025 and the lessons learned from passkeys at scale. Read the original.