Passkeys in 2026: Why Browser Support Stopped Being the Bottleneck

For most of the passkey rollout, the honest answer to “should we ship this?” was a compatibility answer. Some browsers had WebAuthn, some had it partially, and the fallback path had to be maintained anyway — so the cost-benefit rarely worked out. That answer has expired. WebAuthn is implemented across Chrome, Edge, Safari, and Firefox, with Level 2 support in current releases and Level 3 features landing progressively. On the platform side, iOS has supported passkeys since iOS 16, Android since Android 9, and Windows Hello on Windows 10 and 11 handles FIDO2 credentials.

The interesting question is no longer whether the browser will cooperate. It is what happens after a user has a passkey and their situation changes — new phone, different ecosystem, switched password manager, lost device. That is where the friction moved, and it is worth being specific about each piece, because the three remaining problems have very different maturity levels.

Portability Was the Structural Problem — and It Now Has a Standard

The reason passkeys were hard to move is the same reason they resist phishing. A passkey is a private key, not a string. You cannot export it to a CSV, mail it to yourself, and paste it into a different manager, because a credential that can be moved in plaintext is a credential that can be stolen in plaintext. For several years the practical consequence was lock-in by construction: the passkeys you created in one provider’s vault effectively lived there.

FIDO’s answer is a pair of complementary specifications. Credential Exchange Format (CXF) defines a JSON-based structure for credentials — passkeys, passwords, TOTP secrets, notes. Credential Exchange Protocol (CXP) defines the encrypted transfer itself, using Hybrid Public Key Encryption to protect credentials end-to-end in transit. CXF reached Review Draft status in March 2025 and was approved as a FIDO Alliance Proposed Standard in August 2025 at v1.0; CXP targeted standardization in early 2026.

The implementation record is what makes this credible rather than aspirational. Apple, Google, Microsoft, 1Password, Bitwarden, and Dashlane all contributed to the work. Apple shipped CXF-based same-device credential transfer in iOS and macOS 26. Android added Credential Exchange Protocol support through a Google Play Services update, and Dashlane began rolling out Credential Exchange on Android on February 25, 2026.

Note the shape of what shipped first: same-device transfer between providers. That solves “I want to switch password managers.” It is not the same as arbitrary cross-ecosystem sync, and the distinction matters when you are writing documentation for users who will read “portable” as “works everywhere automatically.”

Recovery Is Still the Genuinely Unsolved Piece

Portability standards address the case where the user still has their credentials and wants to move them. They do not address the case where the user has lost access entirely.

This is where passkey deployments still quietly fall back to something weaker. If a service’s recovery flow is an emailed magic link or an SMS code, then the phishing-resistant credential is protected by a phishing-vulnerable backstop, and an attacker’s rational move is to skip the passkey entirely and attack recovery. The passkey has not eliminated that attack surface; it has narrowed the number of users who touch it in normal operation.

There is no standard that fixes this, because it is not primarily a protocol problem. It is a policy problem about how much identity assurance a service is willing to demand from someone who has lost everything, and how much support cost it will absorb. The defensible patterns in production today are all variations on redundancy: encourage a second passkey on a separate device or provider at enrollment, treat account recovery as a high-assurance flow rather than a convenience flow, and be explicit with users that the second credential is the recovery plan. None of that is elegant, and all of it is better than a magic link.

For a threat model that includes a targeted attacker, this is the part to scrutinize in any service claiming passkey support. Ask what happens when the device is gone. The answer is the real security level of the account.

The Work Left Is Mostly Relying-Party Work

With browsers and platforms handled, the remaining variable is the site. Relying-party implementation carries the decisions that determine whether passkeys actually improve anything: whether the site offers passkeys as a genuine primary credential or as a second factor bolted onto a password, whether it supports multiple credentials per account, whether it uses conditional UI so returning users see the right prompt rather than hunting for it, and whether it degrades sensibly when a user arrives on a device that has no credential.

FIDO’s published deployment figures give a sense of the upside when this is done well: Amazon reported roughly six-times-faster sign-in, Google reported a four-times improvement in sign-in success rate compared with passwords, and Air New Zealand reported a 50% reduction in login abandonment. Those are the numbers a product owner responds to, and they are attributable to named deployments rather than to a vendor’s projection.

Adoption on the user side is harder to state precisely, and it is worth being careful here because the figures in circulation vary by source and by what exactly is being counted. FIDO’s own published figure, drawn from a 2024 independent survey, is that 53% of people have enabled passkeys on at least one account, with 22% enabling them everywhere they can. More recent industry reporting puts awareness and enrollment meaningfully higher. The direction is not in dispute; the specific percentage depends on whose survey you are quoting, and it is better to cite the year and the source than to average them into a number nobody published.

What This Means If You Are Deciding Now

Stop scoping the browser-support question. It is answered, and time spent on a compatibility matrix is time not spent on the parts that will actually determine whether the rollout succeeds.

Scope these instead. Can a user enroll a second credential easily, and does your enrollment flow ask them to? What is your recovery path, and is it stronger than the passkey it backstops? Do you support credential portability now that CXF and CXP exist, so a user switching providers does not experience your service as the thing that broke? And is the passkey a real primary credential on your site, or a second factor wearing a new name — because users can tell the difference, and only one of them removes the password from your attack surface.