Ethan Hawksley’s argument is not that passkeys are bad technology — he calls them fantastic. It is that they are built against the wrong threat for the wrong users. Because they are bound to the site they were created for, they can’t be phished, and because they are asymmetric they can’t be recovered from a breached server. That makes them a good fit for a corporate environment and, he argues, a poor fit for individuals, whose realistic worst cases are permanent lockout, automated account bans and device loss.

Where the design bites:

  • Recovery remains the weakest link. An account is only as secure as its recovery path — SMS, email links, security questions — so passkeys don’t remove the lockout risk, and can hide it behind a false sense of security.
  • Hardware keys can’t be backed up by design: passkeys are added or deleted, never moved. The advice is to buy two or three keys and enrol every one of them per site, which gets expensive. Discoverable credentials, where the site asks the key for your username instead of you typing it, are limited to roughly 25-100 accounts per key, up to 300 on top-end models.
  • Synced passkeys anchor your identity to Apple or Google. If their automated systems ban your account, you lose every third-party passkey stored alongside it. Export and interoperability are still fragmented and inconsistent, unlike a password, which is a string you can write down by hand.
  • Third-party password managers fight the platform. The OS APIs exist now, but the experience lacks the decades of polish that password autofill got, and it is especially inconsistent in native apps outside the browser.
  • Logging in on a machine that isn’t yours is where it gets awkward: you can’t always plug in a key, using a synced passkey means trusting someone else’s computer with all your other passkeys, and the QR-code-plus-Bluetooth alternative is plagued by failed connections and unsupported hardware.

His conclusion: enterprise users have good reason to adopt passkeys, but the ecosystem isn’t mature enough for individuals. Randomly generated passwords in a third-party manager plus an independent TOTP app keep control with the user; people who reused one password everywhere come out ahead on passkeys, and everybody else is currently taking a step back.

What the thread adds

The 693-comment thread on Hacker News is where the article’s claims get stress-tested — including by people who use passkeys daily and like them.

  • drtz — puts arithmetic behind the author’s case: registering passkeys across every device and every account is a matrix problem, so a password manager is the only realistic home for them, which then breaks login on a device you don’t own, where a password could at least be typed by hand. And users are pushed in “without any warning or knowledge of what they’re signing up for.”
  • hannasanarion — the third-party-manager gap from daily use: Amazon prompts them to create a passkey on every login “even when I logged in with a passkey,” because theirs live in Bitwarden rather than the OS. They also note the pitch gets confusing, since “it can’t leave your device” is the headline security claim when the vault syncs across devices by design. jasonjayr adds that the protocol lets sites demand hardware-bound credentials — which would cut software managers out entirely, but is not yet widely used.
  • TeMPOraL — the sharpest addition: password sharing is a feature, not a bug. Handing a friend your debit card and PIN, or a nanny a spare house key, is ordinary delegation of authority, and passkeys remove it. In reply, john_strinlai gives the shortest version of the opposing case: “phishing is very relevant to regular people.”
  • vanschelven — compares passkeys to IPv6: a supply-side solution that skipped the research into what would make users switch. coldpie refines it into the article’s own split — for a business the account belongs to the business, so hard restrictions on where you log in are reasonable; for a consumer, the key store belongs to a company whose interests aren’t yours, and the protocol would need rewriting on that assumption.
  • littlecranky67 — a theory rather than a finding, which the replies treat as such: the standard’s attestation feature is dormant today but could later be used to require that a passkey come from a non-rooted Apple or Google device, or as a proof-of-humanness gate. EvanAnderson agrees and expects exactly that. Nobody claims it has happened.
  • ethin and rconti — the practical cost, from people not arguing in the abstract. One says they love passkeys and still lost a Google account to them, because authentication demanded a passkey — or an Android phone — they no longer had, with no way around it. The other describes a working day of Chrome, 1Password, the operating system and a separate second factor all competing for a touch, “an ugly inconsistent dance, dozens of times a day.”

Dissent runs both ways in the thread. nunez calls passkeys a massive quality-of-life improvement, argues the lockout risk is minimal for people whose passkeys sync through iCloud or a Google account, and says the flow they want gone is magic-link email auth. torstenvl’s claim that passkeys are “grotesquely insecure” drew bennetthilberg’s reply that the key material is not the problem — an enclave-held key with biometric unlock and origin binding beats a shared string and a TOTP secret that can be phished from anywhere — while conceding lockout is real and noting that most lockout scenarios would take passwords and TOTP codes down with them.

Comment after comment describes the same friction the author opens with: being nudged into creating a passkey in the middle of an ordinary login (drtz, dspillett, hannasanarion, joshstrange, Liftyee, rconti, projektfu, among others). The disagreement is about whether that is a temporary implementation problem or the design working as intended.

Thread caveats: HN handles are pseudonymous and the site publishes no per-comment scores, so the ordering is HN’s own ranking rather than a vote. This is a slice of a 693-comment thread, not a consensus.