Passkeys finally cleared the boring obstacles
Cross-platform portability shipped, enterprise deployment hit 87%, and the remaining problem turned out to be where you put the enrolment prompt.
Passwordless authentication spent years in the state where the technology worked and the deployment did not. That has changed, and the reasons are worth being precise about, because they are mostly not cryptographic.
By 2026, 87% of enterprises are deploying or piloting passkeys, up from 53% two years earlier. Consumer awareness is around 90%, with roughly 75% having enabled them somewhere.
The blocker was lock-in, and it got fixed
The objection that actually held enterprise rollouts back was never "is WebAuthn secure". It was: if a user's passkeys live in Apple's keychain and they move to an Android phone, what happens?
For a long time the answer was "they re-enrol everything", which is an unacceptable support burden at scale. Apple, Google and Microsoft have now all shipped cross-platform passkey portability, which removes the objection that made IT departments hesitate. That is an unglamorous interoperability fix, and it did more for adoption than any amount of advocacy.
The measurable results are about support cost
The security argument for passkeys is well understood — a phishing-resistant credential bound to an origin cannot be replayed against a lookalike domain, which removes an entire category of attack rather than mitigating it.
The argument that actually gets budget approved is operational. Password reset tickets fall by 60–80% after deployment, and observed password usage drops around 26% once passkeys are live. For most organisations, password resets are one of the largest single categories of helpdesk volume. Removing most of it is a line item a finance team understands without needing to be persuaded about credential phishing.
The finding that is actually about product design
The most useful detail in the 2026 data has nothing to do with cryptography.
When eBay moved the passkey enrolment prompt to appear contextually — immediately after a successful login — adoption was 102% higher than when enrolment was only available in the settings menu.
Double the adoption, from moving one prompt.
This should not be surprising and it usually is. Settings pages are where features go to be ignored. The moment right after a successful login is the one moment when the user has just proved they hold the credential, has it fresh in mind, and is not yet doing the thing they came to do. It is the highest-intent, lowest-friction point in the entire session.
The general lesson generalises well past passkeys: for any security improvement that requires a user action, the enrolment moment is a product decision, and it will dominate your adoption numbers far more than the underlying technology does.
What to do if you are adding this
A few things worth getting right, mostly learned from other people's rollouts.
Offer passkeys alongside the existing method rather than replacing it. A hard cutover generates lockouts, and lockouts generate exactly the support volume you were trying to eliminate.
Put the enrolment prompt after a successful login, not in settings. See above.
Register more than one authenticator where you can. A single passkey on a single device recreates the single-point-of-failure problem that account recovery flows exist to solve, and account recovery is where most authentication systems are actually weakest.
Think hard about the recovery path, because it is now your weakest link. A phishing-resistant login with an email-based reset flow behind it is only as strong as the email account. This is the part that gets least attention and deserves most.
Treat the fallback as permanent. Some users will be on old devices, shared machines, or platforms without support, and designing as though everyone can enrol produces a system that quietly excludes people.
Where this leaves passwords
Not gone. Password usage dropped 26% after deployment, which is a real dent and not an elimination. The realistic 2026 position is that passkeys are now the sensible default for new consumer-facing authentication, with passwords as a maintained fallback rather than the primary path.
That is a less exciting claim than "passwords are dead", which has been asserted annually for about fifteen years. It is also the first version of the claim with deployment data behind it rather than enthusiasm.
Building something like this?
We are a product studio in Kathmandu. Tell us what you are building and an engineer will reply.