For Webauthn, Recoverability is still an open issue of ongoing research. From these issues [2], Webauthn having inbuilt recovery is out of scope. In fact a mobile phone becomes a single point of failure and unlike with 2FA, and with the likely requirement of attestation I don't know if free implementations of FIDO keys would be allowed. [3] This limitation was known and was considered out of scope since 2018. Webauthn can only be considered impossible to phish if companies completely remove the ability to log in with a password and TOTP.
https://github.com/w3c/webauthn/issues/1640
[2] https://github.com/w3c/webauthn/issues/931
[3] https://github.com/w3c/webauthn/issues/865
In Introducing passkeys in Chromew3c
webauthn
Bikeshed2018–2026
w3c / webauthn
webauthn
Web Authentication: An API for accessing Public Key Credentials
25Distinct people
40Mentions
1Explicit recommenders
1.5KGitHub stars
What to know before exploring
What it is
Web Authentication: An API for accessing Public Key Credentials
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
The working group is definitely quite corporate-driven – just look at who's most active in it! – and has made some bad decisions in the past (my favorite example being [1],…
lxgr used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- fido-alliance/how-to-fido · linked in 2 of the same discussions
- yackermann/awesome-webauthn · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 3:38:16 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year40 dated mentions
Observed mentions: 2018-03-26 04:28:28 UTC to 2026-07-16 10:45:11 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 2 | 1 | 1 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 12 | 0 | 12 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 10 | 0 | 10 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 2 | 0 | 2 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
Web Authentication Specification
This is the repository for the W3C WebAuthn Working Group, producing the draft "Web Authentication" specification.
The editor's copy is available at https://w3c.github.io/webauthn/, or in the gh-pages branch of this repository.
The current offically published working-draft snapshot is here: https://www.w3.org/TR/webauthn/.
The build history is available from the repo Actions tab
W3C WebAuthn Blog
Web platform tests repository
Contributing
To materially contribute to this specification, you must meet the requirements outlined in CONTRIBUTING.md. Also, before submitting feedback, please familiarize yourself with our current issues list and review the mailing list discussion.
Building the Draft
The following are required before continuing:
mise
Run the following commands to set up your local development environment to work on these specifications:
mise setup
Formatted HTML for the draft can then be built with the following command:
mise build
You can use the following command to automatically regenerate the rendered document as you make changes locally, and view the rendered document at http://localhost:8000:
mise serve
Continuous Integration & Branches
https://w3c.github.io/webauthn/ is autopublished from the gh-pages branch on every push to the main branch, using https://github.com/w3c/webauthn/blob/main/.github/workflows/build-validate-publish.yml to configure the autopublishing behavior.
Read the full README on GitHubWhat Hacker News says
12 sourcesThat's a once type thing, the website is supposed to prompt you after that QR login whether you'd like to enroll your local authenticator (Chrome, Edge, Firefox,etc) after you login so you don't need to keep using the QR code.
The concept is that many people will frequently have multiple passkeys, thus not be 'locked in' to any one sync ecosystem.
From https://github.com/w3c/webauthn/wiki/Explainer:-broadening-t...
> When signing in on a different computer, either the credential will already be locally present (if the computer is using the same sync fabric as the phone) and suggested by autocomplete, or else the user’s phone can be used to transmit the assertion to the computer. In the latter case, the service may invite the user to enroll a local platform authenticator for easier sign-in in the future. (Now the newly registered credentia
Read the rest
l may be part of a different sync fabric, and thus enable local sign-in on other devices.)
As usual - it depends.
There have been two main problems with WebAuthn as a primary factor. The first is that the UX experience of WebAuthn as a primary factor - either for "passwordless" or "usernameless" scenarios - has been pretty rough. The WebAuthn W3C group has put together a document that goes into far more detail [1]. One of the items out of that discussion was a standards change [2] that was merged in a few months ago. Now it's up to browser vendors to implement that change over the coming months and years.
The second problem with WebAuthn is that device based authentication has been historically risky for consumer users long-term. It's unreasonable to expect an individual to have access to their phone, yubikey, or laptop over a period of years. In the B2B space, this isn't as big of a deal. Getting an IT admin that works for you
Read the rest
r company to reset your access and issue a new credential is not a complex problem. Not so in the B2C space. Devices get lost or stolen, and then the service operator needs to build out an alternative recovery method that needs to be as secure as WebAuthn (ideally, without infringing on the user's privacy via KYC methods). New developments like Apple's PassKeys are super interesting and have the potential to really be a game changer for B2C WebAuthn adoption.
In summary, WebAuthn probably can't replace the password for your application today, unless your users are tech savvy and OK with the lock-out risk. However, the space going through some exciting changes and it may be much more feasible in a few years!
[1] https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-Con...
[2] https://github.com/w3c/webauthn/pull/1576
I wish WebAuthn would have a standardised HTTP header or TLS extension so it would be usable without JavaScript, currently every website has to implement their own login protocol in JavaScript.
https://github.com/w3c/webauthn/issues/1255
https://github.com/w3c/webauthn/issues/1616
In Bringing passkeys to Android and ChromeIt is well past time to stop using passwords. We should be using TLS client certs (as in mutual TLS aka mTLS) or WebAuthn passkeys already. I prefer certs because they don't require support in the web application, but they have a terrible UI and browsers seem to be making that worse, so WebAuthn it is, I just wish WebAuthn would have a standardised HTTP header or TLS extension so it would be usable without JavaScript, currently every website has to implement their own login protocol in JavaScript.
https://www.cloudflare.com/learning/access-management/what-i...
https://github.com/w3c/webauthn/issues/1255
https://github.com/w3c/webauthn/issues/1616
In AI-driven thermal cameras used to obtain passwordsFound some possibly related issues:
https://github.com/w3c/webauthn/issues/1616
https://github.com/w3c/webauthn/issues/1255
In PasskeysUnfortunately not. But recently serialisation and deserialisation _has_ been added to the standard. So it's something:
https://github.com/w3c/webauthn/pull/1703
Github maintains a Ponyfill for browsers that don't support this standardised serialisation format yet: https://github.com/github/webauthn-json
In PasskeysExporting is purposefully made impossible in many implementations of Passkeys (aka Webauthn authenticators) other than Apple's. For example, Yubikeys are designed so private keys can never leave the authenticator [0]. Enabling the export of private keys from an authenticator greatly increases the attack surface of an authenticator.
This is a long-standing security/usability tradeoff in the Webauthn spec. Various solutions have been proposed, but as far as I know most of them are still just drafts, e.g. [1]. The best practice has been and, as far as I know, continues to be to register multiple authenticators, e.g. a primary and a backup authenticator. This practice has a variety of benefits:
1. Avoids lockout if an authenticator is lost.
2. If you use multiple authenticators from different vendors (e.g. Yubico and Google) you:
1. Avoid ven
Read the rest
dor lock-in
2. Can rapidly respond in case a security vulnerability is discovered in one of your authenticators, as has occurred for both Yubico [2] and Google [3].
One could use Apple's Passkeys as one's day-to-day "personal" authenticator, and use an authenticator from a different vendor (e.g. Yubico Yubikey or Google Titan Security Key) as their backup key. I don't see how Apple's implementation increases the risk of lock-in beyond that of any of the other major Webauthn authenticator providers.
[0]: https://github.com/w3c/webauthn/issues/865#issuecomment-3804...
[1]: https://github.com/Yubico/webauthn-recovery-extension
[2]: https://www.yubico.com/support/issue-rating-system/security-...
[3]: https://security.googleblog.com/2019/05/titan-keys-update.ht...
I wondered this too, and found https://github.com/w3c/webauthn/issues/151 . The short answer is "not easily".
According to Mozilla's docs & that issue, it seems like WebAuthn considers the UA and the "authenticator" different. The authenticator, here, is a hardware device, either a separate security key or a TPM. But that really means that the hardware the keys are on is a SPoF, and it shows in the comments in the Github issue.
The thread seems to resolve this with "every RP should allow the user to add more authenticators"; this is, to me, something that's not going to work:
1. asking a user to buy two phones, TPMs, or hardware security keys isn't going to happen, realistically, and the consequence of it can't be "the user is locked out of their account"
2. even if I do 1, I need to do the "add a second authenticator" flow for my backup
Read the rest
authenticator each time I register an account. In the event that I do have an authenticator become compromised, or simply just succumb to hardware failure (what's the warranty on a modern phone?) I need to do an O(accounts) operation to migrate to a new authenticator?
3. OIDC has taught me that RPs don't get this. I think StackOverflow is the only site I've seen correctly separate "account on the RP" from "auth from OP used to login" into a one-to-many relationship. I doubt RPs will get it right for WebAuthn, but we'll see.
… I should note that MFAs share some of these problems too. I used Google Authenticator for an MFA, and then my phone reached the end of its useful life, after a short 9 years. Turns out: there's no way to migrate Google Authenticator's data to a new device! Thankfully, in my case, I was retiring the device, and it wasn't completely dead, so I could still use it, and thus, migrate the accounts. And it was an O(accounts) operation. ("Thankfully" (/s), many of my "2FA" accounts were using SMS, so there wasn't too much to migrate from Google Auth.)
At least with a password manager, I can back up & move the managed passwords to another device. (Though to be clear, OIDC > each site has its own password, to me.)
That's exactly why FIDO [1] and WebAuthN [2] are moving towards a concept of backup-able/cross-device-sync-able authenticators.
That is arguably less secure in some contexts, but there are workarounds, and I do see the point that for most services, availability/key loss recovery is as much of a concern as is security.
[1] https://fidoalliance.org/multi-device-fido-credentials/
[2] https://github.com/w3c/webauthn/issues/1714
In Apple, Google and Microsoft Commit to Expanded Support for FIDO StandardAt least the WebAuthN standard seems to be moving in a different direction [1], which is also surprising to me.
In a nutshell, it will be possible for relying parties (i.e. websites) to detect multi-device/backup capable authenticators if required, but disabling multi-device functionality would require a very explicit opt-out, not an opt-in, on the relying party's side.
[1] https://github.com/w3c/webauthn/issues/1714
In Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard