May 24, 2026
Passkey panic hits comment land
Understanding WebAuthn credential protection policy
Browsers add another passkey privacy switch, and even security veterans are sighing
TLDR: A new browser security setting can hide saved logins on security keys until you verify yourself, which helps protect privacy if someone gets physical access. But the big reaction was pure fatigue: even seasoned security followers say passkeys are becoming so complicated they’re hard to trust, explain, or cheer for.
The latest WebAuthn update is supposed to make passkeys and security keys more private by letting sites ask devices to hide your saved login unless you prove it’s really you first. In plain English: if someone gets physical access to your security key, this setting can help stop them from snooping around to see which accounts are on it. Sounds sensible! But the real show is in the community reaction, where the vibe is less “great security win” and more “why does logging in need a flowchart?”
The standout comment came from longtime browser-security watcher captn3m0, who basically spoke for every tired techie staring into the authentication abyss: after 15 years of keeping up with browser security changes, this is the thing that finally feels too complicated. That’s the hot take hanging over the whole story. Not “is privacy good?”—everyone agrees it is—but why is the path to that privacy so wildly confusing? Between different protection levels, browsers silently picking defaults, Chrome and Firefox supporting the feature while Safari shrugs and ignores it, and websites still having to check things correctly on the server side, the comments practically write their own meme: “Congrats, your password is gone; please enjoy 19 new settings instead.”
That’s the drama here: a feature meant to protect ordinary people is landing with the kind of complexity that makes even experts sound exhausted. It’s security theater’s grumpy cousin—good idea, brutal explanation.
Key Points
- •WebAuthn discoverable credentials can be requested with `residentKey`, but the relying party cannot directly control how credentials are discovered within the authenticator.
- •CTAP 2.1 defines the `credentialProtectionPolicy` extension to control whether discoverable credentials can be revealed or used without user verification.
- •The three policy levels are `userVerificationOptional`, `userVerificationOptionalWithCredentialIDList`, and `userVerificationRequired`, each providing a different level of protection.
- •The `enforceCredentialProtectionPolicy` input can force credential creation to fail if the authenticator cannot meet the requested protection level.
- •Chrome and Firefox support these extension inputs, Safari ignores them, and Chrome may apply default protection policies based on `residentKey` and `userVerification` settings.