Published: October 12, 2026 | Reading Time: ~11 minutes | Channel: techminute
At 14:00 UTC on October 12, the number one story on the Hacker News front page was not a model release, not a chip launch, and not another sandbox escape. It was a 5,000-word essay with a title engineered like a mugshot flash: "Passkeys are a trap. Do not use them." By that hour it had collected 789 points and 428 comments — engagement that most AI launches would envy — arguing that the password replacement every major site on Earth is currently pushing at you is, structurally, a device for taking choices away from you.
Here's the uncomfortable part: the essay is largely correct about the mechanics. And so are its loudest critics. That collision — between a security architecture that genuinely works and a standards process that quietly centralizes control — is the most important authentication story of the decade, and almost nobody is covering it, because the people best equipped to explain it are the ones who've been congratulating themselves for killing the password.
The essay, published October 10 on the Substack Non-Functional under the byline "The Hack," [1] is aimed explicitly at non-technical readers, and its core claim is simple: "unlike with any other kind of login credential, you do not have ultimate control over your passkeys." With a password, you decide where it lives — your head, a sticky note, a manager, a text file. With a TOTP authenticator, you pick the app, because the standard (RFC 6238) is fully open and reimplementable — the essay gleefully notes you could run it on a Game Boy. [1] With passkeys, you get whatever your device, your OS, and the website jointly decide you get.
Passkeys are the product of the FIDO Alliance, the consortium behind the FIDO2/WebAuthn standards that Apple, Google, and Microsoft have spent three years shipping into every phone and browser on the planet. The essay's sharpest observation isn't technical at all — it's sociological. It enumerates who sits in the FIDO Alliance: Big Tech, banks, national governments, intelligence agencies, device makers, and even Mozilla. What's absent, it notes, is any consumer advocacy group — a contrast it draws with the W3C, where public-interest groups and universities sit alongside the corporates. [1]
That framing sets up the essay's central move. It grants, up front, that passwords are a disaster — it cites the ancient solarwinds123 password and Hawaii's emergency-management sticky note as museum pieces of password failure [1] — and it concedes passkeys "can be far more secure than passwords." The trap, it argues, is not that passkeys are insecure. It's that the word "passkey" is a parts catalogue pretending to be a single thing.
What most users never learn is that "passkey" is a marketing noun stretched over a menu of optional, mutually exclusive properties. The FIDO Alliance itself instructs everyone to write it in lowercase, as a common noun — "a cross-platform general-use term, not a feature tied to any specific platform." [4] Which platform, and which features, matters enormously. The essay walks the catalogue: [1]
| Property | Both options exist | Why you'd care |
|---|---|---|
| Copyable vs non-copyable | Yes | Can you rescue the key off a dying laptop — or does it die with it? |
| Transferable vs non-transferable | Yes | Can it move to your new phone, or is it chained to the old one? |
| Hardware-backed vs software-backed | Yes | TPM / Secure Enclave chip, or a plain file you control? |
| User-present vs non-user-present | Yes | Must a human press something, or can software act alone? |
| User-verified vs non-user-verified | Yes | Biometric/PIN required — or does mere device presence count? |
| Attested vs non-attested | Yes | And here is where the essay says the trap springs. |
The WebAuthn specification genuinely does carry a machine-readable summary of these choices with every credential — the authenticator data flags — so the website knows exactly what kind of credential it's dealing with. [1] And the spec's attestation settings are real: attestationConveyancePreference can be set to none, indirect, direct, or — most invasive — enterprise, the mode in which the site receives the authenticator's model identifier (the AAGUID) and attestation statement "unaltered," with no privacy-anonymizing CA in the loop. [3] That last option exists, in the W3C's own language, for enterprise-managed device fleets. It is also, functionally, the machinery of a device-permission system — the same philosophical territory as the remote-attestation debates that have shadowed Android bootloaders and macOS security for years.
Here's the essay's chain of logic, reconstructed: a website may someday declare it accepts only attested, hardware-backed, user-verified, non-copyable passkeys. A hobbyist passkey manager could lie about those flags — software can claim anything — except under attestation, where a tamper-resistant cryptoprocessor in your device cryptographically vouches that an approved passkey manager produced the credential. Your custom manager, your Linux setup, your refurbished phone running LineageOS — all of it becomes visibly, rejectably non-standard. And a site doesn't need to do this to everyone at once; it can flip ten thousand accounts at a time and see if anyone notices. [1]
The pro-passkey case isn't speculation; FIDO's own materials are a wall of numbers: [4]
| Metric | Value | Source (as cited by FIDO) |
|---|---|---|
| People who enabled a passkey on ≥1 account (2024 survey) | 53% | FIDO Alliance |
| Enabled on every account possible | 22% | FIDO Alliance |
| Hacking-related breaches involving stolen credentials | 77% | Verizon |
| Rise in AI-powered phishing attacks on corporate credentials | 3,000% | SlashNext |
| Spear-phishing success rate against trained security professionals | 47% | IBM X-Force 2025 |
| Reduction in phishing/credential-theft exposure | 99.99% | Yubico |
| Faster sign-in times | 6x | Amazon |
| Sign-in success rate improvement vs passwords | 4x | |
| Reduction in mobile account-takeover fraud | 98% | CVS Health |
| Reduction in login abandonment | 50% | Air New Zealand |
| Increase in sign-in conversion | 70% | Dashlane |
Those vendor-supplied numbers should be read as marketing adjacent — they're cherry-picked deployments, not randomized trials. But the directional claim survives skepticism: phishing is the dominant failure mode of human authentication, and passkeys are cryptographically bound to the domain they were created for. A phished passkey simply produces a signature the fake site can't use. That's the essay's own addendum, buried in the final footnote: passkeys are "in most use cases" domain-bound and "resistant to what are called Man-In-The-Middle attacks" — followed by the author's rueful admission, "I feel I have made a compelling case for passkeys in this article." [1][6]
If you want evidence that passkeys are neither magic nor a finished utopia, Palo Alto Networks' Unit 42 published it in August. Their three-attack series against Google's synced-passkey ecosystem on Windows (Chrome + TPM) is a reminder that every new architecture arrives with its own attack surface: [5]
Crucially, Unit 42's own framing requires the honest caveat the essay's critics will reach for: every one of these attacks presupposes malware already running on the victim's device. That's not a design flaw unique to passkeys — a compromised endpoint is game over for most authentication schemes. But the research's middle finding cuts deeper, because it's about the spec's own flag system: a section titled "UV Flag: When MFA Depends on a Single Bit" documents real relying parties that accepted authentication while ignoring the user-verified flag — meaning the "multi-factor" ceremony silently degraded into a single factor. [5] The website was told the user wasn't verified. It logged them in anyway. The essay warned that sites won't phrase their credential requirements clearly. Unit 42 found sites that don't even read them.
If you're a normal user: the essay's practical advice is to treat passkey enrollment as a one-way door with a fog machine in front of it. You won't be told which catalogue item you're creating. Whether that matters depends on a bet: do you believe sites will use attestation to lock out hobbyist software and alternative operating systems, or do you believe phishing — which passkeys provably kill — is the bigger dragon? FIDO's data says the dragon is phishing: AI-assisted phishing up 3,000%, and even trained professionals click 47% of the time. [4] Your correspondent's honest read: for the median user, the trade is good.
If you're a power user: the community's exit ramps are real and worth knowing. Attestation has a structural limit — HN user agwa points out it can generally only be enforced at registration; a site can't retroactively re-attest a credential at login, and browsers are supposed to prompt you when a site requests attestation. [6] Multiple passkey managers now export credentials (Bitwarden, KeePassXC, 1Password), restoring the password-manager ownership model — cattle, not pets, as one commenter put it: many keys per account, spread across managers, none individually precious. [6]
If you're an agent builder: file this under the same arc this column has tracked all autumn — the $50,000 budget cap, the silicon containment, the sandbox escapes. Remote attestation is the device-level cousin of agent budget caps: a machine-readable floor of "what kind of client are you" that a counterparty can demand before doing business with you. FIDO itself now lists an Agentic AI focus area on its standards roadmap. [4] The question "may the server verify what you are running?" has already been answered, affirmatively, for your phone. Your agents are next.
If you're the FIDO Alliance: you have an adoption problem disguised as an adoption success. 53% uptake [4] with the kind of top-of-Hacker-News backlash that reads like a user-revolt post-mortem means the consortium's naming and defaults — one word, "passkey," covering at least a dozen user experiences — did more reputational damage than any single implementation flaw. The W3C comparison in the essay stings precisely because it's checkable: the spec body has consumer advocates; the alliance that owns the consumer branding does not. [1]
The passkey backlash isn't really about cryptography — the cryptography is the best part. It's about a consortium shipping a consumer product whose terms are a parts catalogue, marketed with one word, with no consumer advocate in the room where the defaults are set. The essay's 789 points didn't come from people who lost their accounts; they came from people who realized they were never told which kind of lock they'd just installed. Read the essay, then read the addendum where it argues itself into a draw [1][6] — and if you enroll a passkey this week, do it in a manager that exports, keep the backup, and remember that "it just works" and "you control it" have never once been the same sentence.
All claims verified against Gold-tier sources (the primary essay in full, the W3C WebAuthn Level 3 spec, the FIDO Alliance's official materials, IETF RFC 6238) and Silver-tier security research (Palo Alto Networks Unit 42). Community points from Hacker News are labeled as community-sourced. Each source URL was scraped and confirmed accessible. Last verified: 2026-10-12.
