TL;DR: Passkeys have crossed into mainstream use with more than 3 billion active credentials globally, but the hard work now sits in enrollment, recovery, platform variation, and phishing-resistant account lifecycle design, according to OneSpan’s report from FIDO Authenticate 2025. The security shift is no longer about proving passkeys work; it is about removing the fallback paths that quietly preserve password-era risk.
At a glance
What this is: This analysis argues that passkeys have moved into mainstream use, but production success now depends on account lifecycle design, recovery paths, platform behaviour, and removing insecure fallback methods.
Why it matters: IAM teams need to treat passkey rollout as a lifecycle and governance problem, not a pure authentication upgrade, because weak recovery and fallback controls can preserve password-era exposure.
Context
Passkeys are a phishing-resistant authentication method, but they do not solve account security on their own. The article shows that the harder work begins once deployment leaves the lab and has to survive enrollment friction, device loss, platform switching, and recovery design at scale.
For IAM and identity governance teams, this is an account lifecycle problem that spans human identity controls and recovery governance, not just a login modernization project. If insecure fallback methods remain in place, the passkey layer may improve authentication while the broader account journey still preserves legacy risk.
Key questions
Q: How should teams implement passkeys without leaving legacy recovery risk behind?
A: Treat passkeys as part of the account lifecycle, not a standalone login project. Define how users enroll, switch devices, recover access, and leave the system, then remove any fallback path that still depends on phishable methods. If recovery remains weaker than authentication, the programme still inherits password-era exposure.
Q: Why do passkey rollouts fail even when users understand them?
A: Passkey rollouts usually fail because the surrounding identity operations are not ready. Enrolment, device binding, recovery, and deprovisioning must all work together. If those controls are fragmented, the authentication method may be strong on paper but weak in practice, especially when support teams handle exceptions outside the normal workflow.
Q: What signs show that an authentication programme is not truly phishing resistant?
A: Look for shared secrets, OTP dependence, push fatigue risks, and exceptions for privileged users. If the strongest methods are not required on the most sensitive paths, the programme is likely describing resilience it does not actually enforce.
Q: What should identity teams do when passkeys coexist with password-era workflows?
A: Decide which legacy flows will be retired, which will be time-limited, and which will be prohibited entirely. Then align security, support, and product ownership so the default journey favours passkeys and the exception paths do not reintroduce phishable access.
Technical breakdown
Why passkey rollout becomes an account lifecycle problem
A passkey can replace passwords at the authentication step, but the account lifecycle still has to handle enrollment, device change, recovery, and platform variance. That makes the real control plane broader than the login ceremony. If users can fall back to SMS recovery, forgotten-password flows, or inconsistent platform prompts, the environment still contains phishable paths even when the primary method is stronger. The technical challenge is not whether passkeys work. It is whether the surrounding identity journey can enforce a coherent, phishing-resistant state across creation, use, and recovery.
Practical implication: treat passkey rollout as lifecycle design, not a front-door authentication swap.
Why platform behaviour changes passkey adoption at scale
Passkey adoption differs sharply by platform because mobile and desktop environments do not produce the same user expectations or UX constraints. The article notes that mobile adoption is materially stronger because users already rely on biometrics and device-bound authentication habits, while desktop experiences vary more widely. That means implementation teams are not just shipping a credential type. They are shaping a cross-platform identity experience in which timing, device context, and prompt placement influence whether users actually enroll and continue using the stronger path.
Practical implication: measure adoption separately by platform and tune enrollment prompts to the user moment, not the implementation schedule.
Why recovery is the real weak point in phishing resistance
Passkeys can support phishing resistance only when the account no longer retains alternative phishable recovery methods. A single SMS recovery route or password reset path can undermine the protection that the passkey itself provides. In practice, this shifts the design question from authentication assurance to recovery governance. Security, product, and support teams have to agree on what counts as an acceptable fallback, because the weakest recovery channel becomes the easiest bypass of the stronger primary method.
Practical implication: inventory and remove phishable recovery routes before claiming a phishing-resistant account model.
NHI Mgmt Group analysis
Passkeys are not the finish line for identity security; they expose whether the account lifecycle was ever governed as a whole. The article shows that organisations can deploy stronger authentication while still preserving insecure recovery and fallback paths. That means the security outcome depends less on the credential format and more on whether the surrounding account journey has been rebuilt around phishing-resistant defaults.
Phishing resistance collapses if any recoverable path remains phishable. One insecure reset or recovery channel reintroduces the same trust problem passkeys were meant to remove. For practitioners, the lesson is structural: authentication strength is only as durable as the weakest adjacent account action.
Platform-specific behaviour is now a governance issue, not just a UX issue. Mobile and desktop adoption patterns differ enough that passkey programmes need segmented measurement, not a single success metric. The named concept here is account lifecycle gap: the space between a working authentication method and a fully governed identity journey, where risk persists outside the login step.
Authentication alone no longer defines digital trust for human identity programmes. The article’s broader point is that identity assurance now spans proofing, recovery, fraud resistance, and session continuity. Teams that treat passkeys as a narrow IAM feature will miss the control failures that live around the credential itself.
Passkey adoption validates stronger authentication, but it also validates the need for lifecycle governance across human identity programmes. The practical boundary is clear: if support processes, recovery routes, and platform behaviour are not controlled together, the organisation only upgrades the front door while leaving side entrances open.
What this signals
Account lifecycle gap: The core issue is not whether passkeys can authenticate users, but whether organisations can remove every weaker path that still governs account recovery and device change. If the lifecycle still depends on phishable fallback methods, the stronger credential only masks the real control gap.
Passkey programmes should now be judged by the integrity of the surrounding identity journey, not by enrollment counts alone. That means recovery policy, support escalation, and platform-specific behaviour become part of the security design, not operational afterthoughts.
For practitioners
- Map the full passkey account lifecycle Document enrollment, device replacement, recovery, and deprovisioning paths before scaling deployment. The goal is to identify where password-era fallback behaviour still exists and which teams own each state transition.
- Remove phishable recovery methods Eliminate SMS recovery, weak reset flows, and other fallback paths that preserve legacy attack opportunities. If the account can still be recovered through a phishable path, the passkey deployment is not yet phishing-resistant.
- Segment adoption metrics by platform Track mobile and desktop enrollment separately, then compare completion rates, drop-off points, and support burden. Platform-specific measurement reveals whether the issue is prompt timing, UX variation, or device expectations.
- Align product, IT support, and security on recovery policy Set one recovery standard for what is allowed, what is prohibited, and when a human approval step is required. The policy should reflect the lowest acceptable trust path, not the easiest support path.
Key takeaways
- Passkeys improve authentication, but they do not close the broader account lifecycle problem that appears in enrollment, recovery, and device change.
- The real risk is not the credential itself, but the fallback paths that preserve password-era exposure after deployment.
- IAM teams should govern passkeys as a lifecycle programme and remove any recovery channel that still depends on weaker, phishable methods.
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 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | SP 800-63B — Authentication | Passkeys are an authentication method and the article focuses on how authentication behaves at scale. |
| SP 800-63C — Federation | The article touches account journeys and trust across platforms and sessions, which intersects with federation design. | |
| Recommendation — Apply SP 800-63B to align authenticator assurance with passkey enrollment and recovery design. Use SP 800-63C to govern federated account journeys that extend beyond the login event. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The piece is about how identity assurance and access paths stay consistent across the lifecycle. |
| PR.DS-01 — Data-at-rest is protected | Fallback paths and recovery data can expose sensitive account controls if not governed carefully. | |
| Recommendation — Enforce PR.AA-05 so access paths and recovery routes match the intended assurance level. Protect recovery-related data and artifacts so backup paths do not weaken the primary control. | ||
| ISO/IEC 27001:2022 | A.8.5 — Secure Authentication | Passkeys and fallback recovery are authentication controls covered by secure authentication practice. |
| Recommendation — Implement A.8.5 to ensure stronger authentication is not undone by weaker fallback methods. | ||
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.
- Account lifecycle: Account lifecycle is the full sequence of join, use, recovery, change, and removal for an identity. For passkeys, it includes enrollment, device replacement, credential binding, support escalation, and deprovisioning, because security breaks when any lifecycle step falls back to weaker controls.
- Phishing Resistance: Phishing resistance is the ability of a user and an authentication process to withstand impersonation attempts and malicious requests. It depends on stronger verification habits, safer authenticators, and workflows that make it harder to accept fraudulent prompts.
- Fallback Path: A secondary access route used when the primary authentication method fails. Fallback paths matter because they often become the real control in day-to-day use. If they are easier than the intended method, the organisation will drift toward them and weaken its identity posture.
Deepen your knowledge
NHI governance, human identity lifecycle, and secrets management 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.
Published by the NHIMG editorial team on June 7, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org