Passkeys Are Winning Slowly — and Identity Proofing Is the Gap

The story the industry told itself about passkeys was that the transition had already happened. It had not. FIDO's Passkey Index, published in October 2026, puts passkeys at 36% of successful sign-ins, up from 26% the year before, with 38% of accounts enrolled. Sign-in success runs at 93% against 78% for passwords, and the median sign-in is about 2.8 times faster. Those are excellent numbers and they describe a technology that is winning. They do not describe a technology that has won, and any identity strategy built on the assumption that passwords are already gone is building on a fiction.

The enterprise picture is similar. FIDO's May 2026 survey found 68% of organisations have deployed passkeys or are actively deploying them, while only 28% describe themselves as fully passwordless. Dashlane's measurement of the largest consumer relying party, Google, found passkey sign-ins at 28%. Two thirds of relying parties say they intend to offer passwordless accounts within twelve months, which is encouraging and also exactly what they said last year.

What Passkeys Actually Fixed

It is worth being precise, because the benefits are real and specific. A passkey removes the shared secret from the server, so a database breach no longer hands attackers a reusable credential. It binds authentication to the origin, so a lookalike domain cannot collect the response. It eliminates the typed code, which removes the phishing kits built to relay one. The result is a genuinely large reduction in credential phishing and stuffing for any population that has enrolled.

None of that touches the question of whether the person enrolling is who they claim to be, or whether the person recovering a lost authenticator is the same person who set it up. Passkeys moved the trust boundary from the login form to the enrolment and recovery process, and most deployments have not moved their controls with it.

Enrolment Is an Identity Problem

Before a user can hold a passkey, someone has to decide that the account belongs to them. In a workforce that decision is usually made by a human resources record and a manager, which is adequate. For customers, contractors and anyone whose account protects money or sensitive records, it requires identity proofing: document verification, a biometric comparison, and liveness detection that distinguishes a live person from a replay, a mask or a synthetic face injected into the camera feed.

The attacks have followed the maturity of the check. Presentation attacks using printed photographs and replayed video are the oldest and the best understood, which is why the ISO/IEC 30107-3 framework for presentation attack detection exists and why any vendor claiming liveness should be able to describe its performance against a defined attack set, not just show a demo. Injection attacks are newer and more interesting: instead of fooling the camera, the attacker replaces the camera. Virtual camera drivers, emulators and instrumented applications feed a synthetic stream directly into the verification pipeline, bypassing the physical capture the liveness check assumed. Vendors that only analyse the final image are vulnerable to this by construction.

Recovery Is the New Helpdesk Compromise

The most reliable way to defeat a strong authenticator is to convince someone to issue a new one. Helpdesk social engineering used to target password resets. It now targets passkey re-enrolment, device replacement and account recovery, and it is easier than attacking the cryptography will ever be. The controls that work are procedural and unglamorous: verify identity through a channel the attacker does not control, require a cooling-off period before a new authenticator becomes usable, notify the existing device and the account owner, and keep a record of every recovery event with the evidence used to approve it. For privileged accounts, recovery should require two people and should never be available through the same channel the attacker used to make contact.

What to Measure

Adoption dashboards love enrolment percentages, which are stable and flattering. The numbers that predict incidents are less comfortable: the share of sign-ins that are actually phishing-resistant rather than merely enrolled, the number of recovery events per month and how many were verified out of band, the time between a device being reported lost and its credentials being revoked, and the percentage of administrator accounts that still have an SMS fallback. A deployment in which 60% of staff hold a passkey but every administrator can reset theirs by phone call has not reduced the organisation's exposure as much as the dashboard suggests.

Passkeys are the right destination. The mistake is treating them as a login feature rather than as the point where identity proofing, device management and recovery policy all meet. The cryptography is the easy part, and it is already done.