Passkey Adoption Is 5 Billion Strong. 57% of Enterprises Still Sign In With Phishable Methods.

The FIDO Alliance's State of Passkeys 2026 report, released on World Passkey Day, puts the global count at roughly 5 billion passkeys in use. That passkey adoption figure is real, and it is also the least useful number in the report for anyone who runs a login system. A passkey registered on an account that still accepts a password and an SMS code leaves that account as phishable as before, for any attacker who goes for the weaker door.

This piece lines up the consumer and workforce numbers as a funnel, explains why a second survey quoting 87% enterprise adoption does not contradict the 68% in the FIDO report, and ends with the metrics worth tracking if you own authentication. The reader in mind is a security or platform engineer who has to report passkey progress to leadership next quarter.

The passkey adoption funnel: from awareness to a password that stops working

FIDO surveyed 11,000 consumers and 1,400 enterprise decision-makers across ten countries, including India, with stated margins of error of 0.9 and 2.6 percentage points respectively at 95% confidence (release). Putting the headline figures in one table shows where the drop-offs sit.

Read the consumer rows top to bottom and the pattern is a 26-point gap between enabling a passkey and using one regularly. Enabling is a single prompt. Regular use only happens when the passkey is the easiest option on the login screen every time. On the enterprise side, 82% call fully passwordless the ultimate goal and 28% have reached it. That gap is the state of the industry.

One caveat on the source: the FIDO Alliance is the body that promotes passkeys, and the figures are self-reported by survey respondents. They are good for direction and weak for precision.

Why one survey says 87% and another says 68%

An April write-up on Security Boulevard cites 87% of enterprises as deploying or piloting FIDO2 passkeys, attributed to the HID and FIDO Alliance 2025 State of Authentication survey, up from 53% two years earlier. The 2026 report says 68% have deployed or are actively deploying.

The two figures differ in year, in wording, and in how much is known about them. The 87% reaches us through a secondary article that gives no sample size and no definition of piloting. A pilot can mean ten people on an IT team. My reading is that 87% is an upper bound on organisational interest and 68% is closer to commitment. Neither says how many employees can sign in without a password today, which is the 28% row.

The fallback is the attack surface

The 57% figure deserves more attention than the 5 billion. A passkey is a WebAuthn credential scoped to the origin that created it. A phishing site on a lookalike domain cannot get the browser to produce a valid sign-in for the real site. That property is what makes passkeys phishing-resistant, and it holds only for sign-ins that use the passkey.

If the same account also accepts a password with an SMS code, or lets a user regain access through an emailed link, the attacker does not need to defeat the passkey. They pick the route that is still phishable. Every fallback you keep is a choice made on the attacker's behalf.

Passkey type changes where that trust sits. Synced passkeys live in a platform or password-manager account, so recovering that account becomes part of your chain of trust. Device-bound keys, such as hardware security keys, avoid the dependency but are harder to replace when lost. A reasonable split is device-bound for administrators and other privileged roles, synced for the wider population.

Metrics that measure removal, not enrolment

Enrolment totals only ever go up, which makes them pleasant to report and uninformative to act on. These four move when the risk moves:

• Share of successful sign-ins by method over 30 days, with password, SMS and email codes grouped as phishable.
• Share of active accounts on which password sign-in is disabled.
• Recovery events per thousand accounts, split by the method used to recover.
• Passkey-enrolled users who still sign in with a password. This is the 75-versus-49 gap measured on your own users.

The first and last of these are one query each if your auth events are logged with a method field. The schema below is hypothetical; adapt the names.

-- Sign-in method mix, last 30 days
SELECT method,
       COUNT(*) AS sign_ins,
       ROUND(100.0 * COUNT(*) / SUM(COUNT(*)) OVER (), 1) AS pct
FROM auth_events
WHERE event = 'sign_in_success'
  AND occurred_at >= now() - interval '30 days'
GROUP BY method
ORDER BY sign_ins DESC;

-- Passkey-enrolled users who still sign in with a password
SELECT COUNT(DISTINCT e.user_id) AS still_using_password
FROM auth_events e
JOIN passkeys p ON p.user_id = e.user_id
WHERE e.event = 'sign_in_success'
  AND e.method = 'password'
  AND e.occurred_at >= now() - interval '30 days';

What to do this quarter

1. Instrument sign-in method first. You cannot report a phishable share you do not log.
2. Offer enrolment right after a successful sign-in, when the user has already proved who they are and has the device in hand.
3. Disable password sign-in for enrolled users in privileged roles before anyone else.
4. Audit every recovery path and raise the weakest one to match the sign-in it replaces.
5. Put an end date on SMS codes as a primary factor, and publish it internally.

The next FIDO report will probably quote a bigger passkey count. The number worth watching is the one that should fall: the share of sign-ins that can still be phished.