Let me say the reassuring part first, because this is not a "don't use passkeys" piece: passkeys are genuinely good, they're a real upgrade over passwords, and I use them. If you take nothing else from this, take that.
But there's a part of how passkeys work that the "add passkey auth in 10 minutes" tutorials never mention, and it's the one part actually worth understanding — because it's the part with teeth. Under the right (or wrong) conditions, the passkey system can let a website verify what device and software you're using and refuse to log you in if it doesn't approve. In principle, that can lock you out of your own account on your own device, for running the "wrong" operating system or browser.
That sounds alarming, and the mechanism is real, so I want to explain it honestly — both how it genuinely works and how worried you should actually be, because the answer to the second part is "less than the headline suggests, but not zero." This piece was sparked by a more alarmist article making the rounds ("passkeys are a trap"), and I wanted to write the fair, technical version: what's true, what's overblown, and — if you're the one building auth — the choice that quietly lands on your desk.
The feature is called attestation. Here's the whole story.
First, how passkeys actually work
Quick, because the rest depends on it.
A passkey is a public/private key pair, created by your authenticator — your phone, your laptop, or a hardware key like a YubiKey. When you register, the authenticator generates the pair, keeps the private key locked away (ideally in a secure chip it never leaves), and hands the website the public key. To log in, the site sends a challenge, your authenticator signs it with the private key, and the site verifies the signature with the public key it stored.
Why this is genuinely better than passwords: there's no shared secret to steal — the site never holds anything that logs you in, so a database breach leaks public keys, which are useless to an attacker. And it's phishing-resistant, because the key is bound to the real domain; a fake look-alike site can't trigger it. This part is great. No notes.
The standard underneath is WebAuthn (a W3C/FIDO standard), and "passkey" is just the friendly user-facing name for a WebAuthn credential. So far, so good.
"Passkey" is an umbrella, not one thing
Here's the first thing the marketing glosses over: "passkey" isn't a single thing. It's a spectrum of options. A passkey can be synced across your devices (the convenient kind, backed up to iCloud or Google) or device-bound (never leaves one piece of hardware). It can live on the device you're using (platform) or roam between devices over Bluetooth/NFC (roaming, like a YubiKey). Most of these distinctions are benign — they're just convenience-vs-control tradeoffs you'd reasonably want either way.
But one property is different in kind, because it's not about your convenience at all. It's about what the website gets to know and demand about your setup. That's attestation.
What attestation actually is
When you register a passkey, the authenticator can include a signed statement that proves what kind of authenticator created the key — its make and model — in a way that can't be faked, because it's signed using a key baked into the device's secure chip at manufacture.
That's the core idea: attestation attests to the provenance of the authenticator. Not who you are — what device you used.
There are levels of it, and the differences matter:
-
none— the default. No device info, or an anonymized version. The site gets your public key and nothing identifying about your hardware. This is what the overwhelming majority of sites use. -
direct— the site receives the authenticator's make and model (e.g. "this is a YubiKey 5" or "this is an iOS platform authenticator"). -
enterprise— the strong one: the attestation can include uniquely identifying information, like a serial number. This is meant for controlled deployments where a company issues a known fleet of keys.
And here is the mechanism behind the scary headline: because an attested registration cryptographically proves what device and software stack produced the key, a website can decide to accept only certain ones. "We only accept hardware-backed, user-verified, attested passkeys from approved authenticators." If your setup can't produce that proof — because you're on Linux, or a de-Googled phone, or a custom browser, or an OS that's no longer getting the blessed updates — the site can notice, and refuse you. That's the lock-out. It's real, and that's genuinely how it would work.
So how worried should you actually be? (Honestly: watchful, not scared)
This is where the alarmist version stops and the honest version has to keep going, because the mechanism being possible is very different from it being likely to hit you today. Here's the real context, and most of it is reassuring.
Attestation defaults to none, and the professional consensus is to leave it there. The W3C spec defaults the attestation setting to none, and current (2026) guidance for developers is blunt about it: for almost all consumer and business sign-ins, you should not request attestation. It leaks platform information, reduces user choice, and adds friction for no benefit to a normal login. "Skip it" is the mainstream recommendation, not a fringe one.
The identifying kind needs your consent and specific configuration. Enterprise attestation — the type that can include serial numbers — can't just be silently switched on against a consumer. It requires the authenticator to support it, the platform/browser to be configured (typically by enterprise policy) to release it, and user consent. It's a managed-workplace tool, not something a random website can spring on you.
Privacy is built into the standard on purpose. To stop attestation from becoming a tracking identifier, FIDO guidance requires each attestation certificate to be shared across at least 100,000 devices in a batch. So "direct" attestation tells a site you're using, say, an iPhone 15 — not which iPhone 15. It identifies a model, not a person, by design.
And in practice, essentially no mainstream consumer site requires attestation today. The passkeys you actually use — from Apple, Google, or a password manager — are the benign, non-attested, user-friendly kind. The lock-you-out scenario is a capability sitting in the standard, not a wall you're hitting this week.
So the honest calibration: the mechanism is real and worth knowing about, because it's the point where authentication could quietly turn into a lever over what software you're allowed to run — and standards have a way of tightening over time. But it is not a trap that's currently sprung, and "passkeys are dangerous, don't use them" is an overreaction to a capability that today sits almost entirely unused against consumers. Watchful, not scared.
The part most articles skip: if you're the developer, this is your choice
Here's the angle I most wanted to write, because nearly every passkey piece is aimed at users and this one's aimed at you, the person implementing auth.
When you add passkeys to your app, attestation is a setting you choose, and the default — none — is almost certainly the right one. Requesting attestation means you receive platform/device information about your users, you add friction, and you risk excluding people on perfectly legitimate but non-mainstream setups. For a normal product, that's all cost and no benefit.
So the practical rule is easy: use none unless you have a specific, genuine regulatory or policy reason not to — a regulated workforce that must use issued hardware keys, a high-assurance fleet, a compliance mandate. Those are real and valid. "It felt more secure" is not one of them.
But I'd also frame it as more than a technical default, because it is: the moment you require attestation, you've become the one deciding which devices and software your users are allowed to use to reach their own accounts. That's a real power, and a real responsibility. The lock-out this article's title warns about isn't something passkeys do to people on their own — it's something a developer chooses to impose. Most of the time, you shouldn't. Reach for that lever only when you truly must, and know what you're doing to your users' autonomy when you do.
What to actually do
As a user: use passkeys. They're a big security upgrade and the versions you'll actually encounter are the friendly kind. Just know the word "attestation" and what it enables, so that if the norms ever shift, you'll recognize what's happening instead of being quietly funneled. And if you want maximum control with passkey-grade security, a hardware key like a YubiKey is self-contained and keeps the authority with you.
As a developer: default to attestation: none. Only request more when a real policy requires it. And when you do, remember you're not just tightening security — you're deciding what your users are permitted to run. Choose that deliberately.
The takeaway
Passkeys aren't a trap, and the title isn't a warning to avoid them — it's a warning to understand them. The lock-out is real as a mechanism and, today, almost entirely theoretical in practice, because the setting that enables it defaults off, needs consent in its strong form, and is deliberately privacy-limited.
But it's worth knowing, for one reason that runs deeper than passwords ever did: attestation is the point where "proving who you are" quietly gains the ability to enforce "what you're allowed to run." It's benign now. It's the dial to watch. And if you're the one building the login, it's a dial that's in your hand — so keep it set to "trust the user" unless you have a very good reason not to.
Two honest questions. As a user: does knowing about attestation change how you feel about passkeys — or is this a non-issue being blown out of proportion? And as a developer: has anyone here had a genuine, legitimate reason to require attestation beyond none? I'd like to hear the real use cases from people who've actually shipped it, because they're rarer than the fear implies.
Sources & further reading: WebAuthn is a W3C/FIDO Alliance standard (see the W3C Web Authentication spec and MDN's PublicKeyCredentialCreationOptions docs for the attestation conveyance options). The attestation member defaults to none per spec; current developer guidance (e.g. WebAuthn implementation guides, 2026) recommends none for virtually all consumer and B2B sign-ins and reserving direct/enterprise for regulated or managed-fleet cases. FIDO guidance recommends attestation certificates span ≥100,000 devices per batch to preserve privacy, and enterprise attestation requires authenticator support, platform configuration, and user consent. This piece was prompted by a more alarmist article ("Passkeys are a trap"); I've aimed to present the mechanism accurately and the risk proportionately — verify specifics against the primary WebAuthn spec, which is the authority here.