By NHI Mgmt Group Editorial TeamBased on Descope: “2026 FIDO Report: Passkeys at Global Scale” (June 1, 2026)

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: This is Descope’s breakdown of FIDO’s 2026 passkey data, showing consumer awareness and enterprise deployment both moving from early interest to routine use.

Why it matters: For IAM teams, the implication is that passkeys are no longer a future-state experiment and must be treated as a mainstream authentication programme with recovery, fallback, and migration decisions.

By the numbers:

  • Consumer awareness has climbed to 90%, up from 75% in the 2025 World Passkey Day report.
  • 68% of organizations are deploying, piloting, or rolling out passkeys for employee authentication.

Context

Passkeys are a phishing-resistant authentication method built on public key cryptography and device-bound credentials. In this article, Descope uses FIDO’s 2026 State of Passkeys report to show that passkey adoption is moving beyond awareness into everyday authentication behaviour for both consumers and employees.

For IAM leaders, the governance issue is no longer whether passkeys work in principle. The harder questions are how to phase them into existing authentication stacks, how to preserve account recovery, and how to avoid leaving passwords in place as the fallback that silently becomes the default.

The article’s underlying message is that user willingness is no longer the main blocker. Legacy compatibility, budget approval, and recovery design now decide whether passwordless becomes a real operating model or remains a partial rollout.


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: When do passkeys deliver more value than passwords in enterprise environments?

A: Passkeys deliver the most value when organisations want stronger phishing resistance, lower user friction, and less reliance on shared secrets across many applications. They are especially useful where employees sign into multiple business systems and where password reset volume creates operational cost. The strongest cases combine security improvement with simpler sign-in and fewer credential management problems.

Q: How do you know if a passwordless rollout is actually working?

A: Look beyond go-live status and measure whether support tickets are falling, adoption is stable across user groups, and users are not bypassing the new process. If the programme still drives heavy fallback use or repeated recovery events, the operating model is not yet mature.

Q: What should IAM teams prioritise when legacy systems do not support passkeys well?

A: Prioritise the applications that matter most to security and user friction, then use phased rollout and compatibility testing to isolate where legacy constraints are unavoidable. The goal is to prevent old systems from becoming permanent exceptions that preserve password dependence. If the legacy layer cannot be modernised immediately, govern its fallback tightly and separately.


Technical breakdown

Why passkeys outperform passwords in practice

Passkeys replace shared secrets with asymmetric key pairs, so the server stores a public key rather than a reusable password. That removes the classic phishing and replay path that makes passwords so persistent as a breach mechanism. The operational benefit is not only stronger authentication but also less dependence on MFA as a compensating control after password compromise. In enterprise settings, that matters because authentication is not just a security layer. It is a workflow layer that affects login friction, helpdesk load, and recovery design.

Practical implication: treat passkeys as an authentication redesign, not a bolt-on security checkbox.

Why adoption is now driven by both security and user experience

The article shows that organisations are not adopting passkeys for a single reason. Phishing resistance, MFA fatigue reduction, login speed, remote work experience, and reduced support costs all sit inside the same decision. That matters because identity programmes often fail when security teams optimise only for attack resistance while business teams measure friction. Passkeys sit at the intersection of IAM, UX, and support operations, so rollout success depends on whether those functions share the same success criteria.

Practical implication: align security, product, and support metrics before expanding passkey rollout.

What recovery and legacy compatibility really mean for authentication architecture

Most objections in the article are not about passkeys themselves but about the surrounding control plane. Recovery, restoration, and legacy compatibility are the real design constraints because authentication does not end at initial login. If an organisation cannot restore access cleanly when a passkey is lost, or cannot integrate passkeys with older systems, users will fall back to weaker methods. That is why migration discipline matters more than enthusiasm. The authentication stack has to accommodate transitional states without letting the fallback become the permanent control.

Practical implication: design recovery and fallback paths as governed controls, not convenience exceptions.


NHI Mgmt Group analysis

Passwordless is now an operating model question, not an adoption curiosity. The article shows that awareness has matured into habitual use for consumers and active rollout for organisations. That changes the IAM problem from persuasion to governance, because the remaining friction is architectural rather than behavioural. Teams now have to decide how passkeys fit into broader authentication policy, not whether the market accepts them.

Passkey rollout exposes the difference between authentication choice and authentication control. A passkey programme succeeds only when fallback, recovery, and legacy integration are governed with the same rigor as the primary flow. This is where many organisations still blur convenience with resilience. If the recovery path is weak, the passwordless architecture is only partially passwordless in practice, and the risk simply moves to the exception path.

Authentication modernisation is becoming a lifecycle issue across human identity and machine-adjacent access. The same discipline that governs joiner-mover-leaver flows, account recovery, and privileged fallback now has to be applied to passkey enrolment and restoration. That makes passkeys less of a product choice and more of an identity operating model change. Practitioners should evaluate authentication as a governed lifecycle, not a one-time migration project.

Consumer readiness is no longer the limiting factor, so enterprise hesitation is increasingly self-imposed. The article’s data suggests users will adopt passkeys when offered, which removes a long-standing objection to rollout. What remains is organisational tolerance for migration complexity, support redesign, and legacy debt. In practice, that means the strongest blockers are internal programme decisions, not external demand.

Passkey adoption is creating a new baseline for phishing resistance, but only if fallback is not allowed to dilute it. The field is moving from optional stronger auth to expected stronger auth, and that raises the bar for how identity teams measure success. The relevant question is no longer whether passkeys can work, but whether the broader authentication stack preserves their security properties under real-world exceptions.

From our research library:

What this signals

Passkey adoption is crossing the threshold where IAM roadmaps should treat passwords as technical debt rather than a default state. The practical challenge is no longer user education, because consumer willingness is clearly there. The real work is deciding which applications can move first, which fallback methods can remain, and which recovery paths need redesign before wider rollout.

Recovery design is becoming the decisive control point for passwordless programmes. Once passkeys are accepted by users, weak restoration logic becomes the easiest place for the old password model to re-enter the stack. Teams should expect more scrutiny on administrative recovery, device redundancy, and legacy compatibility than on the passkey prompt itself.

Consumer behaviour is now aligned with enterprise ambition, which changes the governance baseline. Organisations can no longer justify delay by assuming user resistance. The next phase is controlled migration, where authentication policy, support operations, and account recovery have to be managed as one programme.


For practitioners

  • Map your current fallback paths Identify where password reset, recovery codes, SMS fallback, or legacy MFA still sit behind the primary sign-in flow. Those paths often become the real control surface once passkeys are introduced.
  • Phase passkeys by application criticality Start with apps where phishing exposure or support volume justifies the change, then expand to adjacent systems once recovery and compatibility are proven.
  • Standardise device and account recovery Define who can restore access, what evidence they must check, and which channels are allowed when a passkey is lost or unavailable.
  • Measure rollout success beyond adoption rate Track login completion time, password reset tickets, phishing-related incidents, and the percentage of users who remain on fallback methods.

Key takeaways

  • Passkey adoption has moved from awareness to routine behaviour, which changes the IAM conversation from education to operational design.
  • The main blockers are now legacy compatibility, budget approval, and recovery architecture, not lack of user demand.
  • The organisations that will benefit most are the ones that govern fallback and restoration as part of the authentication control plane.

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

FrameworkControl / ReferenceRelevance
NIST SP 800-63SP 800-63B — AuthenticationPasskeys are a federation and authentication method governed by digital identity guidance.
Recommendation — Apply SP 800-63B to structure passkey authentication and fallback requirements.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsThe article is about controlling authentication access paths and fallback behaviour.
Recommendation — Use PR.AA-05 to govern authentication pathways, entitlements, and exception handling.
NIST Zero Trust (SP 800-207)Authentication principles — Authentication principlesPasskeys align with continuous trust reduction and phishing-resistant access in Zero Trust.
Recommendation — Align passwordless rollout with Zero Trust principles that reduce reliance on shared secrets.
OWASP ASVSV6 — AuthenticationThe article concerns authentication method design and assurance for user login flows.
Recommendation — Apply V6 requirements to verify authentication strength, recovery, and login assurance.

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.
  • Passwordless Authentication: An authentication approach that removes passwords and uses a device-bound cryptographic key plus local user verification. It reduces phishing and replay risk, but it only improves assurance when enrollment, recovery, and revocation are tightly governed.
  • 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.
  • Phishing-Resistant Authentication: Phishing-resistant authentication proves identity without relying on a user to approve a prompt or reveal a reusable secret. It typically binds access to a device, key, or cryptographic proof that an attacker cannot easily reuse or coerce. This approach reduces reliance on human judgment at login time.

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.
NHIMG Editorial Note
Published by the NHIMG editorial team on June 4, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org