Can you please elaborate on the advantages of multiple security keys (one per site) vs a single security key? The later is simpler and avoids the need to reveal the site by naming the keys (if you have many). It is also the default for YubiKey (the previous gold standard).
Great question, and one worth thinking through carefully rather than just defaulting to “more is better.”
Why Yubikey comparisons don’t fully apply here
On a Yubikey, the single key IS the physical device. The security model is built around physical possession of one object. You only have one key because carrying multiple hardware tokens is impractical, not because one is optimal. Passport Prime’s security keys are virtual constructs inside the device, so the physical constraint that shapes Yubikey’s default approach doesn’t exist here. That changes the calculus.
The real argument for segregation: revocation granularity
This is the strongest case. If you use a single security key for every site and something goes wrong (a site breach, suspicious activity, or you just want to deregister from a service cleanly), your only option is to act on everything registered under that key at once. With separate keys, you can delete or disable one without touching the others.
For most sites this probably doesn’t matter. For high-value accounts (email, financial, password manager), it matters quite a bit.
Your privacy point is fair, but not the full picture
You’re right that a single key avoids the need to label anything with site names, which is cleaner from a correlation standpoint. That’s a legitimate tradeoff. The flip side is that a single key ties all your site credentials to the same signature counter and credential set. Separate keys provide better unlinkability between sites, though for most threat models that benefit is fairly theoretical.
You can also label Prime’s security keys by category rather than by site (“finance”, “social”) if you want some organisation without leaking specific site associations.
Practical recommendation
For a typical user, one key per high-value category (rather than one per site) is a reasonable middle ground. You get meaningful revocation control without the overhead of managing dozens of keys. A strict one-per-site approach has real organisational benefits but could be seen as overkill for most people.
My understanding was that security keys and passkeys use similar public and private key technology as crypto and thus even if the information held by the website were publicized, it wouldn’t impact security. Is that correct? If so, why would revocation be necessary?
Caveat up front: the deep technical detail of these standards is beyond my own depth, and my replies in this thread lean on AI assistance to fill in the specifics.
On the cryptography
You’re correct. Security keys use public-key cryptography. The site only stores a public key, a credential ID, and counters, and a leak of any of that doesn’t help an attacker authenticate. Revocation isn’t about leak mitigation.
On per-site unlinkability
Worth flagging since it sits next to the privacy argument: even with a single virtual key on Prime, the standard derives a different public key per relying party (per website). Public keys leaked from two different sites can’t be linked back to the same authenticator. Cross-site unlinkability is built in.
Where multi-key actually has utility: organisation
Once you set aside the security and privacy framing, the case for multiple virtual keys is purely organisational:
-
Mirroring how you mentally group accounts (work, personal, finance, social, throwaway). Easier to find a specific registration in a long list.
-
Discipline in keeping categories separate, so any future reorganisation has cleaner edges.
These aren’t security arguments. They’re about how the user wants the device organised.
Practical recommendation
A single virtual key with sensible labelling does the job for most users and is structurally simpler. Multi-key makes sense if you have enough registrations that buckets help you stay organised, or you want to mirror how you separate your online life mentally. Treat it as a preference rather than a security upgrade.
Is there a way for FIDO (and upcoming FIDO2) keys to show which sites they are registered on?
Good question. It depends on the type of credential used during registration.
When you register at a site using a non-resident credential (the default for traditional FIDO/U2F flows), the authenticator stores nothing about that site. Everything lives on the relying party’s server: your public key, the credential ID, and the signature counter. The key just produces signatures when challenged. There’s nothing on the key to enumerate, by design.
Discoverable credentials (also known as resident keys or passkeys) are the opposite. These do store the relying party ID and user handle on the authenticator itself, and FIDO2 includes a credential management command for enumerating them. That’s why some physical security keys, when paired with a companion app, can show you a list of registered accounts.
Prime’s Security Keys app currently uses the non-discoverable approach, so it doesn’t list registered sites today. Each site you register with gets a fresh deterministically derived keypair, but no per-site metadata is stored on the device.
Once full FIDO2 support lands we can explore surfacing a registered-sites view in the app. cc @Jack to keep this on the radar for the FIDO2 roadmap.
Hope that helps!
Correct, that’s in the FIDO 2 roadmap (DES-2270)