As of September 2026, yes if you run real user accounts, and no if you run a marketing site with a contact form. The standard is settled, the platform support is broad, and the adoption numbers have crossed from early to normal. The remaining question is whether you own your login at all.
That last point decides most of these conversations. Plenty of B2B products we work with do not implement authentication themselves. They rent it. In that case the answer is not build it, the answer is ask your identity provider when.
Here is what actually changed, what the adoption data says, and how we would sequence the work.
It is a key pair instead of a shared secret. Your device generates a private key it never sends anywhere and hands the site a public key. To sign in, the site sends a challenge, the device signs it after checking your face or fingerprint, and the site verifies the signature.
The consequence is that there is nothing to steal in a breach and nothing to type into a fake page. A phishing site cannot collect a passkey, because the signature is bound to the real site's origin. That property is the whole reason this standard exists.
It is not a password stored more safely. It is a different mechanism with different failure modes, and treating it as a fancier password is where most implementation plans go wrong.
The specification finished. Web Authentication: An API for accessing Public Key Credentials Level 3 was published by the W3C Web Authentication Working Group as a Recommendation, dated 25 August 2026. A W3C Recommendation is the end of the standards track, not a draft.
That matters for how you argue for the work internally. Building against a Candidate Recommendation is a bet. Building against a Recommendation is implementing a finished standard, which is a much easier conversation with a cautious engineering lead.
The API surface itself is small and has been stable for a while. The specification extends the Credential Management API through the PublicKeyCredential interface, with navigator.credentials.create() for registration and navigator.credentials.get() for authentication. Two calls. The complexity is everywhere else.
More than most product teams assume. The FIDO Alliance reported on May 7, 2026 that 5 billion passkeys are now in use worldwide, that 90 percent of people are now aware of passkeys, that 75 percent of people have enabled a passkey on at least one account, and that 49 percent of people use passkeys regularly when available.
The methodology is worth stating because it is unusually clear. Those consumer figures come from a Sapio Research study in April 2026 of 11,000 consumers across ten countries, being the United States, United Kingdom, France, Germany, Australia, Singapore, Japan, South Korea, China and India, with a stated margin of plus or minus 0.9 percentage points at 95 percent confidence.
On the enterprise side, a parallel workforce study of 1,400 decision makers at organisations with 500 or more employees, with a margin of plus or minus 2.6 percentage points, found that 68 percent of organisations have deployed or are actively deploying passkeys for employee sign ins, and that 82 percent say fully passwordless authentication is an ultimate goal, with 28 percent having achieved it.
Broad, with a floor most of your users are already above. The passkeys.dev device support table lists Android from v9, iOS and iPadOS from v16, macOS from v13, Windows from 23H2 and Chrome OS from v129, with browser floors including Chrome 108, Edge 122, Firefox 122 and Safari 16.1.
Ubuntu is listed as supported through browser extensions rather than natively, and third party credential managers are noted as a capability from Android v14. So the edges are Linux desktop users and people on old hardware, which for most B2B products is a small and technically comfortable minority.
The practical read is that you will not be building for a fringe. You will be building a second path that a majority of your users can use today and a minority cannot, which is exactly the shape of a good progressive enhancement.
Two ceremonies and a lot of state management. Registration asks the browser to create a credential and stores the returned public key against the user. Authentication asks the browser for an assertion and verifies the signature. Both need a server generated challenge that you store and check once.
The parts teams underestimate are the boring ones. You need to let a user register more than one passkey, because people have more than one device. You need a management screen where they can name and revoke them. And you need a recovery path for the person who loses every device at once.
Do not write the cryptography yourself. Use a maintained server library for your language and a maintained client helper, and spend your effort on the account model instead. That is where the real product decisions are, and it is covered by the same reasoning in our website security guide.
Shared accounts break first. If three people at a client company all sign in with the same login, passkeys make that awkward on purpose, because the credential lives on one person's device. That is a security improvement and it will be reported to you as a bug.
The second complaint is confusion at the prompt. A user who expects a password field and gets a system dialog asking for their fingerprint will sometimes cancel it. Clear copy before the prompt fixes most of this, and it is a plain form design problem rather than an authentication one.
The third is support load during the transition. Every new sign in method adds a category of ticket. Plan for it, write the help article before launch rather than after, and make the fallback obvious on the login screen.
More, for a reason that is easy to sell. B2B accounts are targets. A compromised login into a company's project management tool or CRM is worth far more to an attacker than a compromised streaming account, and phishing is how most of those compromises start.
The workforce data supports the direction. If 68 percent of larger organisations have deployed or are actively deploying passkeys for their own employees, then your enterprise buyers are already having this conversation internally. Being able to answer yes on a security questionnaire is worth something concrete.
That is the honest commercial argument. Not that your users are demanding it, but that your buyers' security teams increasingly expect it, and that expectation shows up in procurement before it shows up in support tickets.
Then this is a vendor question, not a build. If your authentication runs through an identity provider or a platform's built in membership system, you get passkeys when they ship them and you cannot meaningfully get there sooner.
The useful work in that case is to check. Ask your provider directly whether passkeys are supported today, on which plan, and what the roadmap is. That answer belongs in your own security documentation either way.
If the answer is no and it matters to your buyers, that is a real input into whether you stay. We look at exactly this trade in our piece on Webflow memberships and the alternatives, where the same question comes up about what a platform will and will not let you control.
Nothing to do. A site whose only interactive element is a contact form has no authentication to improve, and adding a login so you can add passkeys would be a strange way to spend a budget.
The one exception is a gated resource area. If you are protecting content behind a sign up, you have accounts whether you think of them that way or not, and the same reasoning applies at a smaller scale.
We mention this because we have been asked to add passkeys to sites that had no users, purely because the term appeared in a board deck. It is worth naming that failure mode out loud.
The cost is a sprint or two for a team that already owns its auth, plus ongoing support for a second sign in path forever. The benefit is a phishing resistant option for the majority of your users and a better answer on security reviews.
What it is not, yet, is a way to remove passwords. With 49 percent of people using passkeys regularly when available, you are adding an option, not retiring a system. Any plan that assumes you can delete the password path this year is going to run into the other half of your users.
So we would frame it as an addition with a long tail, and budget accordingly. The teams that get burned are the ones who scoped it as a replacement.
Ship passkeys as an optional second method first, behind a settings screen, for the users most likely to want it. Watch the adoption rate for a quarter. Only then decide whether to promote it to the default on the login screen.
Build the device management and recovery flows in the same release as the happy path, not afterwards. Every team that defers those ends up shipping them urgently, at the worst moment, when a customer has locked themselves out.
If you want a second opinion on whether this is worth doing on your product right now, or help scoping it alongside a site build, we are glad to help. You can reach our team at phoenix.studio and we will give you a straight answer, including when that answer is not yet.
Tell us where you want to go. We'll tell you how we'd get you there.