Passkeys pass 5 billion in use as phishing-proof login goes mainstream

The FIDO Alliance’s State of Passkeys report, published for World Passkey Day in May 2026, put the number of passkeys in active global use at 5 billion. The figure marks a shift from years of slow, optional rollout toward passkeys becoming a default login option across major consumer platforms, driven in large part by a parallel rise in attacks specifically engineered to defeat older forms of multi-factor authentication (MFA).

What the adoption numbers show

According to the FIDO Alliance’s survey data, 90% of consumers surveyed said they are now familiar with passkeys and 75% have enabled them on at least one account, with 40% using them across most of their apps. Regionally, adoption is highest in China and India (88% each), ahead of the Asia-Pacific average of 77%, the United States at 74%, and Europe at 70%. On the enterprise side, 68% of organizations surveyed said they are deploying, piloting or rolling out passkeys, with 28% reporting full deployment and 82% naming a fully passwordless environment as a strategic goal. Early adopters cited concrete benefits: 47% reported an improved security posture, 45% reported faster logins, and 35% reported reduced help-desk costs tied to password resets.

Why the shift is happening now

Passkeys are built on the FIDO2/WebAuthn standard: instead of a shared secret (a password, or a one-time code) that can be phished, intercepted or replayed, the device holds a private cryptographic key and the login server holds only the matching public key. Critically, that credential is bound to the legitimate website’s domain, so a look-alike phishing page cannot obtain a working credential from the user even if the user is fooled into visiting it — the browser or authenticator simply refuses to complete the handshake on the wrong domain.

What MFA bypass attacks actually look like

The push toward phishing-resistant credentials is a direct response to adversary-in-the-middle (AiTM) phishing kits, which have become widely available on underground markets. In an AiTM attack, the victim is sent to a proxy site that sits between them and the real login page, relaying every field the user enters — including the one-time code or push approval from a standard MFA app — and capturing the resulting authenticated session cookie in real time. Because the attacker steals a live, already-authenticated session rather than a static password, the fact that MFA was “used” at all becomes irrelevant: the code or approval was valid, it was just captured and replayed by someone else in the same instant.

Canada’s national cyber agency, the Canadian Centre for Cyber Security, describes this class of attack plainly in its guidance for organizations: SMS codes and app-based push approvals can both be captured by an AiTM proxy, and the agency states that “phishing-resistant MFA is the only way to completely stop these campaigns before a threat actor can get hold of an MFA-verified session.” Its guidance recommends deploying FIDO2 security keys, passkeys, or Windows Hello for Business to every user without exception, rather than treating phishing-resistant authentication as an option reserved for privileged accounts.

What phishing-resistant actually means

Not all MFA is equal, and the terminology matters for anyone setting policy:

  • Knowledge-based MFA (SMS codes, authenticator app codes typed by hand) can be phished by a fake login page that simply asks for the code alongside the password.
  • Push-based MFA (tap-to-approve notifications) can be defeated by AiTM proxies or by “MFA fatigue” attacks that spam approval requests until a user taps accept by mistake.
  • Phishing-resistant MFA (FIDO2 security keys, passkeys, platform authenticators like Windows Hello or Face ID tied to WebAuthn) cryptographically binds the login to the real domain, so there is no code or approval for an attacker’s proxy site to capture in the first place.

The gap that remains

Even with 5 billion passkeys active, FIDO’s own numbers show the transition is partial: only 28% of surveyed organizations report full workforce deployment, and 49% of consumers say they use passkeys “most of the time” rather than by default everywhere they’re offered. Passwords and legacy MFA remain in wide use as fallback options on most services, which means AiTM phishing kits will keep working against a large share of the account base for as long as that fallback stays enabled.

Part of the gap is structural rather than a matter of user preference. Passkeys are tied to a device or a synced credential manager, which means a lost phone, a new laptop, or an employee who never enrolled a second device can still trigger a fallback to a password-and-code recovery flow — and that recovery flow is frequently the weakest link an AiTM kit can target, regardless of how strong the primary passkey login is. Security teams that have rolled out passkeys broadly report that account-recovery paths, not the passkey mechanism itself, are now the most common gap attackers probe first.

The other constraint is cross-platform consistency. A passkey created on one device ecosystem does not always sync cleanly to another, and enterprise environments running a mix of Windows, macOS, iOS, Android and older on-premises identity systems have had to stage rollouts service by service rather than flipping a single organization-wide switch. That staged approach is part of why FIDO’s own workforce figures show a wide range between organizations still piloting passkeys and the 28% that report having finished the rollout.

What adoption looks like in practice

Large consumer platforms — including the major mobile operating systems, cloud email providers and social networks — now offer passkey enrollment as a default prompt rather than a setting buried in account security menus, which accounts for much of the jump in the 75% enablement figure. On the enterprise side, identity providers have added passkey support to single sign-on flows, letting IT teams enforce phishing-resistant login for the applications that sit behind SSO without requiring every downstream app to implement WebAuthn individually. That architecture is what has let organizations move from pilot to broader deployment faster than earlier hardware-security-key rollouts, which typically required physically distributing a key to every employee.

Sources

Leave a Reply

Your email address will not be published. Required fields are marked *