A post titled “Passkeys are a trap. Do not use them.” has been making the rounds on Hacker News this week, and Scott Helme’s rebuttal is the best response to it I have read. The short version: the trap argument rests on a misunderstanding of how WebAuthn attestation actually works, and the alternative it recommends, going back to TOTP codes and passwords, hands the advantage straight back to phishers.
The argument, and why it is compelling
The original post is written for non-technical users and makes one central claim. Passkeys support something called attestation, which lets a website demand cryptographic proof of what software created the credential. The author calls this a hidden dial that sites can slowly turn up until you can only log in with approved software on an approved operating system. String in browser extensions, the FIDO Alliance membership list, and regulator pressure, and the conclusion lands on passkeys not being designed with your interests in mind.
I get why this lands. It has the shape of a real privacy argument, and skepticism toward platform vendors is usually healthy. It just does not match how the protocol behaves.
Your passkeys do not attest
The passkeys most people actually use are synced passkeys held in iCloud Keychain, Google Password Manager, 1Password, Bitwarden, or whichever manager they picked. When a website asks these for an attestation statement, what comes back is none. Helme knows this from the inside, because he maintains an open source WebAuthn library for PHP.
That detail kills the hidden dial scenario on its own. A consumer site that decided tomorrow to accept only attested passkeys would lock out nearly all of its users immediately, because nothing sync-able attests. Guidance for consumer-facing sites has been to not even request attestation for years. And unlike a settings toggle, attestation can only be required when a credential is registered, not retroactively applied to credentials people already have.
There is also a ceiling on what attestation could ever prove. When present, it identifies the make and model of the authenticator through its AAGUID, backed by a vendor certificate chain. It says nothing about your operating system, your browser, your extensions, or whether your phone is rooted. The original post describes it as proving an approved passkey manager, OS, and firmware are in use, which is not what the field carries.
The YubiKey irony
This is my favorite part, because it is the kind of self-contradiction that survives only when nobody checks. Worried readers are told to buy a hardware security key, a YubiKey, to avoid OS-wide attestation. YubiKeys are exactly the authenticators that do attest. Every one ships with a Yubico-issued attestation certificate, and enterprise attestation exists so organizations can require approved hardware. The recommendation pushes you toward the thing you were fleeing.
To be clear, YubiKeys are excellent and I would still suggest one to anyone who wants hardware-backed credentials. Just not for the reason that post gives.
TOTP is a step backwards
The fallback advice, back to TOTP codes and passwords, ignores where account takeovers actually come from. Relay phishing kits like Evilginx sit between you and the real site, pass your password and your one-time code along in real time, and keep the session. Troy Hunt’s Mailchimp compromise is the canonical recent example. This is not a theoretical threat model, it is how a large share of takeovers happen today.
A passkey is bound to the domain it was created for. Your browser will not offer your example.com passkey to examp1e.com, and there is no code to read out over the phone. The original post concedes this in its addendum, then still tells readers to avoid passkeys. Swapping a phishing-resistant credential for a phishable one is a bad trade, and the addendum quietly admits which side of the trade is safer.
The lock-in objection is aging out
The argument against passkeys that used to have real force was portability: credentials stuck to one vendor’s ecosystem. That objection is dissolving. The FIDO Alliance’s Credential Exchange Protocol and Format lets users export and import passkey collections between managers, and the rollout over the past year has Apple, Google, Microsoft, 1Password, Bitwarden, Dashlane, NordPass, and Samsung on the co-development list. iOS 26 shipped it first, with Android support arriving through Google Play Services.
The adoption numbers behind this fight are large. The FIDO Alliance reported in May 2026 that around 5 billion passkeys are in active use, that most consumers have enabled at least one, and that a majority of organizations are deploying them for employee sign-ins. Whatever the merits of the trap argument, the installed base is not a niche experiment anymore.
What remains a genuine problem is fragmentation. Site support is inconsistent, some sites allow only one passkey and no fallback, and cross-device flows still fail in annoying ways. In the Hacker News discussion, those usability complaints were more substantive than the attestation panic. That is where pressure on the ecosystem should go.
What to actually do
Take the passkey when a site offers one, and store it in a manager you trust. If portability matters to you, pick a manager that supports credential exchange. Keep an alternative sign-in method configured on sites that allow it. And if a consumer site ever starts demanding attested passkeys, object loudly, because that would be worth resisting. It has not happened, the biggest providers do not support it, and in the meantime, abandoning phishing-resistant login while waiting for a hypothetical leaves you exactly where the phishers want you.