By NHI Mgmt Group Editorial TeamPublished 2026-06-01Domain: Governance & RiskSource: Descope

TL;DR: FIDO’s 2026 State of Passkeys shows consumer awareness reaching 90%, 75% enabling passkeys on at least one account, and 68% of organisations deploying, piloting, or rolling out passkeys for employee authentication, according to Descope’s summary of the report. The evidence says passwordless is moving from optional upgrade to operational baseline, while recovery, legacy compatibility, and rollout discipline still determine success.


At a glance

What this is: FIDO’s 2026 passkey data shows adoption moving from awareness to habit, with strong consumer enablement and accelerating enterprise rollout.

Why it matters: IAM teams have to plan for passkeys as a live authentication pattern now, because the remaining barriers are integration, recovery, and governance rather than user acceptance.

By the numbers:

👉 Read Descope's analysis of the 2026 FIDO passkey report


Context

Passkeys are a phishing-resistant authentication method built on public-key cryptography, and this report shows they are moving from early adoption into normal user behaviour. The first paragraph of the article is really about a familiar IAM problem: passwords remain the insecure default, and organisations keep paying for that default through compromise, support cost, and user friction.

For IAM and identity architects, the strategic question is no longer whether passkeys work, but where they fit into workforce and customer authentication stacks alongside legacy methods, recovery flows, and policy decisions. The report’s value is in showing that demand is present, implementation blockers are operational, and the remaining work is governance rather than persuasion.


Key questions

Q: How should organisations roll out passkeys without breaking existing login flows?

A: Start with the highest-friction, highest-support-cost applications, then phase in passkeys alongside a measured fallback strategy. Preserve user access during migration, but define exit criteria for password-based sign-in so fallback does not become permanent. The real success factor is not launch speed. It is whether the new login path works across recovery, device change, and legacy application constraints.

Q: Why do passkeys matter even when users still need fallback authentication?

A: Passkeys matter because they remove the reusable secret from the primary sign-in path and sharply reduce phishing risk. Fallback still matters for recovery, but it should be designed as a controlled exception, not the default user experience. If fallback is too easy, the programme keeps the old attack surface alive under a modern label.

Q: What breaks when organisations treat passwordless as only a front-end change?

A: What breaks is recovery governance. If the login method changes but device restoration, identity proofing, and helpdesk escalation stay weak, attackers can shift to the reset path instead of the sign-in path. That leaves the organisation with a better-looking authentication screen and the same underlying assurance problem.

Q: How can IAM teams tell whether passkey adoption is actually working?

A: Look for lower password-reset volume, shorter login times, reduced phishing-related incidents, and a declining share of applications that still require phishable methods. A healthy programme also shows stable recovery outcomes when devices are lost or replaced. If those signals do not move together, adoption is cosmetic rather than architectural.


Technical breakdown

Passkeys, WebAuthn, and the phishing-resistant login model

Passkeys replace shared secrets with cryptographic credentials bound to the device or authenticator. In practice, the relying party verifies possession of a private key through WebAuthn, which removes reusable passwords from the login flow and sharply reduces phishing exposure. The architectural shift matters because authentication becomes origin-bound and less dependent on user memory or helpdesk resets. That changes recovery, device binding, and fallback design, especially in mixed estates where passwords still coexist with newer methods.

Practical implication: map every login path that still depends on reusable secrets and decide where passkeys can safely become the primary factor.

Fallback, recovery, and account restoration are the real deployment boundary

The hardest part of passkey deployment is not the credential itself. It is the surrounding identity recovery model. If a user loses a device or changes hardware, the organisation must re-establish trust without recreating password weakness through weak reset flows or overpowered helpdesk processes. The report shows organisations are gaining confidence in recovery, but that confidence usually comes from secure administrative recovery, cloud recovery features, or multiple registered credentials. That is a governance and lifecycle problem, not just an authentication one.

Practical implication: test recovery paths with the same rigour as sign-in paths, including helpdesk escalation, device replacement, and fallback credential rules.

Why legacy compatibility still slows passkey rollout

Passkey adoption often stalls where authentication architecture is older than the user experience goals. Legacy apps, directory dependencies, and inconsistent support for modern authenticators can force teams to keep passwords or other phishable methods in the stack longer than they want. The technical issue is rarely passkey weakness. It is the collision between modern authentication and an estate that was designed around static credentials, brittle federation, and uneven platform support.

Practical implication: inventory application compatibility and prioritise the systems whose login paths create the biggest residual password risk.


Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

Passkey adoption is now a governance problem, not an awareness problem. Consumer familiarity has climbed to the point where resistance is no longer the main blocker, and enterprise deployment is following that trend. The centre of gravity has shifted from convincing users to ensuring the authentication stack can support secure rollout, recovery, and fallback. For practitioners, this means the strategic debate has moved from education to operating model design.

Passwords remain a standing-privilege risk because they are reusable by design. A credential that can be replayed, phished, and shared creates an authentication surface that passkeys are intended to remove. The article shows that users are willing to enable passkeys when they are offered, which weakens the argument that password retention is primarily a user preference issue. Practitioners should treat password persistence as an exposure decision, not a neutral default.

Recovery is the hidden control plane of passwordless programmes. The report’s confidence figures around device loss and account restoration show that organisations succeed or fail based on how they rebuild trust after a passkey disappears. That makes recovery governance central to identity assurance, because a weak reset path can recreate the very attack surface passwordless was meant to remove. The practical conclusion is that recovery design is part of authentication security, not an afterthought.

Legacy compatibility is the real measure of passwordless maturity. The article makes clear that implementation friction comes from the installed base, not the credential model itself. That means the maturity question is whether an organisation can support passkeys without leaving high-risk systems on phishable methods indefinitely. Practitioners should read passwordless as an estate transformation, not a point feature.

Passkey rollout exposes the difference between authentication improvement and IAM modernisation. Teams can improve login security without fully modernising identity architecture, but the highest-value outcomes appear when authentication, recovery, device trust, and helpdesk processes are aligned. That is why this topic matters across human IAM, because it reveals whether the broader identity programme can support a lower-friction, lower-phishing operating model.

From our research:

  • 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
  • Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
  • That gap is widening as deployment accelerates, as shown in Ultimate Guide to NHIs , 2025 Outlook and Predictions, which frames lifecycle governance as a continuing control priority.

What this signals

Passkey programmes will increasingly be judged by recovery design, not by enrollment rates. The organisations that get the most value from passwordless authentication will be the ones that can restore access cleanly without reintroducing weak reset workflows. That puts identity proofing, helpdesk controls, and device lifecycle handling back at the centre of IAM operations.

The next phase of authentication modernisation is less about replacing one login factor and more about reducing the number of places where reusable secrets still survive. Teams that do not inventory those residual paths will keep paying password tax through support cost, abandonment, and residual phishing exposure.

Passkey adoption also creates a useful signal for broader identity maturity: if a programme can support secure fallback, phased rollout, and clean recovery, it is usually ready for deeper changes in workforce authentication and customer access design. If it cannot, the problem is usually governance rather than technology.


For practitioners

  • Audit password-dependent login paths Map every workforce and customer application that still depends on reusable passwords or phishable fallback methods. Rank them by exposure, user volume, and reset cost, then set a migration sequence that starts with the highest-friction flows.
  • Test passkey recovery as a control Run device-loss and account-restoration drills using secure administrative recovery, cloud recovery, and multi-credential registration rules. Measure whether the process restores access without creating helpdesk privilege inflation or weak identity proofing.
  • Use phased rollout and A/B testing Introduce passkeys in controlled cohorts so you can compare abandonment, login success, and helpdesk volume against existing methods. Keep legacy fallback visible during the pilot, but set a clear retirement path for phishable methods.
  • Align identity teams with support operations Treat passwordless deployment as a joint IAM and service desk programme. Helpdesk scripts, recovery thresholds, and escalation approvals should be redesigned together so support does not become the weakest point in the authentication chain.

Key takeaways

  • Passkeys are moving from promising alternative to operational expectation, which changes how IAM teams should plan authentication roadmaps.
  • The evidence still points to passwords as a live security and experience liability, not a legacy problem that has already faded.
  • Recovery design, legacy compatibility, and fallback discipline now determine whether passwordless programmes reduce risk or simply rename it.

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 CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST SP 800-63Passkeys directly affect authenticator assurance and recovery design.
NIST CSF 2.0PR.AA-01Authentication hardening and recovery map to access control outcomes.
NIST Zero Trust (SP 800-207)PR.AC-1Passwordless sign-in supports continuous verification and reduced standing credential risk.

Adopt passkeys where they strengthen identity assurance without weakening fallback controls.


Key terms

  • Passkey: A passkey is a phishing-resistant credential based on public-key cryptography rather than a shared password. The private key stays on the user’s device or authenticator, while the service verifies a cryptographic response. In identity programmes, passkeys reduce replay risk but increase the importance of recovery and device lifecycle governance.
  • Phishing-resistant authentication: Phishing-resistant authentication is any login method that does not expose reusable secrets to an attacker during sign-in. Passkeys are the clearest example because the credential is bound to the origin and cannot be copied like a password or one-time code. The operational challenge is keeping recovery equally resistant.
  • Account recovery: Account recovery is the process used to restore access when an authenticator is lost, replaced, or unavailable. In passwordless programmes, recovery becomes a control point rather than a convenience feature, because weak restoration can recreate the same compromise paths passwordless was meant to remove.
  • Fallback authentication: Fallback authentication is the secondary method used when the primary sign-in factor is unavailable. For passkey deployments, fallback must be tightly governed because it often becomes the attacker’s preferred route if it remains easier to abuse than the main login path.

Deepen your knowledge

Passkeys, passwordless rollout, and recovery governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are modernising authentication in a mixed identity estate, it is worth exploring.

This post draws on content published by Descope: 2026 FIDO Report, Passkeys at Global Scale. Read the original.

NHIMG Editorial Note
Published by the NHIMG editorial team on 2026-06-01.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org