TL;DR: Passkeys can remove password phishing and SMS-based attack paths, but real adoption depends on deployment choices, user experience, and lifecycle handling across enrolment, recovery, and step-up flows, according to Authsignal and Yubico's webinar analysis. The security model is sound; the governance challenge is making it usable without weakening assurance or creating recovery debt.
At a glance
What this is: This article explains why passkey rollouts stall unless teams align FIDO2 infrastructure, enrolment UX, and credential lifecycle controls across recovery and step-up flows.
Why it matters: It matters to IAM and identity security teams because passkeys only reduce phishing and MFA bypass when enrolment, recovery, and management are governed as part of the full identity journey.
Context
Passkeys replace passwords with FIDO2 credentials based on public key cryptography, which changes the trust model for customer and workforce authentication. The article's central point is that adoption is not limited by cryptography alone; it is limited by how well the deployment handles enrolment, device choice, recovery, and step-up authentication across the full identity journey.
For IAM teams, this is a lifecycle control problem as much as an authentication problem. If enrolment is awkward, recovery is brittle, or users cannot manage multiple authenticators cleanly, organisations may preserve phishing resistance in theory while losing adoption and operational control in practice.
Key questions
Q: How should security teams roll out passkeys without breaking account recovery?
A: Start with low-risk journeys, then define recovery as a controlled identity workflow rather than a convenience feature. Use step-up verification, help-desk approval, and audit logging for resets. The goal is to keep passwordless sign-in simple while making fallback paths stricter than the primary login path. That is where most account abuse begins.
Q: Why do passkeys change authentication risk but not identity governance?
A: Passkeys reduce phishing and password theft, but they also create a new lifecycle problem around device trust, sync, recovery and revocation. Organisations still need clear enrolment rules, recovery approvals and offboarding processes, because the credential may be safer than a password while the surrounding identity workflow remains governable only if policy is explicit.
Q: What are the signs that a passkey programme is not ready for scale?
A: Common warning signs include heavy dependence on legacy fallback methods, unclear recovery handling, poor device-choice guidance, and low adoption outside the easiest user journeys. If users can enrol but cannot recover cleanly or complete high-risk actions with the new authenticator, the programme is still fragile.
Q: What is the difference between passkey enrolment and passkey lifecycle management?
A: Enrolment is the moment a credential is created and bound to an account. Lifecycle management covers what happens after that point, including backup, rotation of trust when devices change, deletion, support recovery, and step-up use across the customer journey.
Technical breakdown
Why passkeys change the authentication trust model
Passkeys use a public-private key pair, with the public key held by the relying party and the private key remaining on the user's device or authenticator. Because the server never stores the private key, a server-side breach does not reveal reusable credentials in the way password databases do. Origin binding also ties the credential to the correct site, which blocks phishing pages from replaying the authentication ceremony. That security model is strong, but it only works if the relying party supports the FIDO2 flows correctly and users can complete enrolment and recovery without falling back to weaker paths.
Practical implication: Treat passkeys as an architecture change, not a single login option, and validate the relying party flow before broad rollout.
Why passkey type selection affects governance
The article separates device-bound, platform, and syncable passkeys because each has different operational trade-offs. Device-bound keys maximise resistance to malware and cloning, but they introduce physical recovery needs. Platform passkeys are convenient on a single device but become fragile when the device is lost or replaced. Syncable passkeys improve continuity across an ecosystem, but they also extend trust into the cloud account and device sync layer. This is an identity governance issue because the authenticator choice affects recovery, backup, offboarding, and support design just as much as it affects security strength.
Practical implication: Design policy around authenticator classes, not just passkey enablement, so recovery and backup rules match the assurance level of each method.
How lifecycle control determines whether adoption holds up
The article's lifecycle message is that passkeys are not a one-time enrolment event. Teams have to govern enrolment at high-assurance moments, manage public key records on the relying party side, and define what happens when users change devices, lose keys, or need recovery. It also shows that step-up use cases matter because passkeys need to cover more than initial sign-in. In practice, weak lifecycle design creates support burden, inconsistent assurance, and pressure to keep legacy fallbacks alive longer than intended.
Practical implication: Map passkey governance to enrolment, recovery, deletion, and step-up flows before large-scale rollout.
Breaches seen in the wild
- Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
- SonicWall SSL VPN account compromises 2025: Attackers used valid credentials to log in to more than 100 SonicWall SSL VPN accounts across 16 environments in October 2025.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Passkey adoption fails most often as a governance problem, not a cryptography problem. The article makes clear that the FIDO2 model is strong, but organisations still lose momentum when enrolment, recovery, and device choice are not designed as a coherent identity lifecycle. The decisive issue is not whether passkeys can resist phishing, but whether the surrounding process lets users adopt them without forcing weaker fallback behaviour.
Authenticator choice is now an assurance-policy decision. Device-bound, platform, and syncable passkeys do not create the same operational risk profile, even though all three can support passwordless authentication. That means the question is not whether to 'support passkeys', but which authenticator classes are acceptable for which journeys, which recovery paths they require, and which support burdens they create. Practitioners should treat passkey class selection as policy, not preference.
Lifecycle control is the real adoption control. Passkeys only become durable when enrolment happens at the right trust moment, public keys are governed on the relying party side, and recovery does not become a hidden privilege pathway. That makes passkey programmes a direct test of whether IAM teams can manage credentials after issuance, not just before login. The implication is that lifecycle discipline, not feature availability, separates pilots from production-scale adoption.
Phishing resistance does not remove user-journey risk, it relocates it. When organisations move away from passwords and SMS codes, they reduce familiar attack paths but increase the importance of step-up design, account recovery, and support-assisted identity assurance. The article shows that users will adopt passkeys when the experience is faster and clearer, yet bad recovery design can recreate the same weakness through another channel. Practitioners need to govern the whole journey, not just the front-door authenticator.
Passkey programmes should be measured by completed lifecycle coverage, not enrolment counts alone. A high number of enrolled passkeys does not tell you whether users can recover safely, whether step-up is enforced at high-risk moments, or whether multiple authenticators are managed cleanly across devices. The control question is whether the organisation can sustain assurance after day one. That is the metric IAM teams should use when deciding if adoption is real.
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 adoption should be governed as an identity lifecycle programme. The organisations that succeed are the ones that design for enrolment, device change, backup, and recovery as one control surface rather than as separate support issues. That is where adoption becomes durable and where IAM teams can prevent recovery from becoming the new weakest link.
Authenticators now need policy, not just enablement. Once teams allow multiple passkey types, they need rules for where device-bound keys are required, where syncable passkeys are acceptable, and how step-up authentication behaves for sensitive transactions. Without that policy layer, the programme may expand convenience while blurring assurance.
Passkey rollouts should be judged by completed journeys, not login conversion alone. A programme can show high enrolment and still leave gaps in recovery, account changes, or call-centre assisted flows. The operational question is whether the identity team can maintain assurance after the first successful login.
For practitioners
- Define passkey policy by authenticator class Set different rules for device-bound, platform, and syncable passkeys so assurance, backup, and recovery expectations are explicit for each class.
- Bind enrolment to high-assurance moments Offer initial passkey enrolment during account creation or immediately after strong identity verification, rather than waiting for a future sign-in event.
- Design recovery before rollout Document what happens when users lose a device, change ecosystems, or need to replace a hardware key, and make the recovery path match the assurance level of the original authenticator.
- Use step-up authentication for high-risk actions Extend passkey enforcement beyond login into account change, payment, and support scenarios so the control protects the full customer journey.
- Measure adoption and lifecycle completion together Track enrolment, successful recovery, and use of passkeys in step-up flows as separate metrics so the programme does not mistake initial uptake for durable control.
Key takeaways
- Passkeys reduce phishing exposure, but their real-world value depends on whether the surrounding identity process supports enrolment, recovery, and step-up use.
- Different passkey types create different governance burdens, so policy has to distinguish between device-bound, platform, and syncable authenticators.
- The control question is no longer whether passkeys work, but whether the organisation can manage their lifecycle without falling back to weaker authentication paths.
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-63 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Passkeys are presented as a stronger authentication model replacing password and SMS weaknesses. |
| NHI-01 — Improper Offboarding | Lifecycle control includes deletion and replacement of credentials when devices or accounts change. | |
| Recommendation — Use FIDO2-based passkeys to replace weak authentication paths that remain vulnerable to phishing and replay. Define deletion and replacement steps for passkeys when users lose devices or leave the environment. | ||
| NIST SP 800-63 | SP 800-63B — Authentication | The article focuses on authentication assurance, user verification, and passwordless sign-in design. |
| Recommendation — Align passkey deployment with digital authentication guidance and enforce verifier-controlled step-up where needed. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Passkey policy affects which authenticators and step-up paths are permitted for different journeys. |
| Recommendation — Map authenticator policy to access permission decisions so higher-risk flows require stronger verification. | ||
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.
- FIDO2: FIDO2 is a passwordless authentication standard that uses public-key cryptography instead of shared secrets. A service stores the public key while the authenticator keeps the private key, allowing users to prove possession without sending reusable credentials over the network.
- Syncable Passkey: A syncable passkey is a passkey that can move across a user’s devices through a trusted ecosystem. It improves convenience and recovery, but it also broadens the portability of the credential, which matters when the organisation needs stronger device-level control or tighter assurance boundaries.
- Step-up Authentication: Step-up authentication is an additional verification step triggered when a session becomes higher risk or a user attempts a sensitive action. It is used to reduce exposure without forcing extra friction across every interaction, which makes it useful for runtime access governance.
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on July 11, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org