FIDO2 security keys and passkeys: how to choose

A FIDO2 security key is a small device that signs login challenges with a private key that never leaves the hardware. It is the most effective single control against credential phishing that is available today, because it does not rely on the user noticing a fake website: the browser itself tells the key which site is asking, and a key registered on example.com simply has no credential for examp1e-login.com.

This guide explains what happens inside a FIDO2 login, how passkeys fit in, and what to check before you buy keys for yourself or roll them out across a team.

The protocol stack in one diagram

FIDO2 is the umbrella name for two specifications that work together:

When you register a key, the authenticator generates a new key pair for that website (the relying party), returns the public key and keeps the private key. When you log in, the site sends a random challenge; the browser adds the origin it is actually connected to, and the key signs the whole thing. The server verifies the signature with the public key it stored at registration.

Three properties make this strong:

• Origin binding. The relying party ID (normally the site's domain) is part of what gets signed. A phishing proxy on another domain cannot obtain a valid assertion for the real site.
• Per-site key pairs. There is no shared secret to steal from the server and no way to correlate the same key across sites.
• Non-exportable private keys. On a hardware key the private key is generated and used inside a secure chip. Malware on the laptop can ask the key to sign (if the user touches it), but it cannot copy the key.

User presence versus user verification

Two flags in every FIDO2 response are often confused:

• User presence (UP) means someone physically touched the key. It proves a human is there, not who they are.
• User verification (UV) means the authenticator checked a PIN or a fingerprint locally. The PIN never goes to the website.

A key used with UV counts as two factors on its own: something you have (the key) and something you know or are (PIN or biometric). That is what enables passwordless login. Without UV, the key is a strong second factor after a password.

Set a FIDO2 PIN on every key, even if you only plan to use it as a second factor. Many services request UV for sensitive operations, and a key without a PIN cannot satisfy that request.

Passkeys: discoverable credentials, device-bound or synced

"Passkey" is the consumer name for a FIDO2 discoverable credential (also called a resident key). A discoverable credential stores the user handle on the authenticator, so the site does not need you to type a username first. There are two families:

NIST's digital identity guidelines (SP 800-63B, revision 4) accept syncable authenticators at AAL2 and reserve AAL3 for authenticators whose keys are non-exportable. In practice: synced passkeys for everyone, hardware keys for anyone who can change production systems, approve payments or administer identity.

Hardware keys have a limited number of slots for discoverable credentials, and older firmware generations offered fewer than current ones. If you plan to store dozens of passkeys on one key, check the published slot count for the exact model and firmware version. Non-discoverable credentials (classic second-factor registrations) do not consume slots.

Inspecting a key from the command line

Before issuing keys, look at what they report. With libfido2 installed (packaged on most Linux distributions and on Homebrew):

# List connected FIDO devices
fido2-token -L

# Show supported versions, extensions, options (rk, uv, clientPin) and AAGUID
fido2-token -I /dev/hidraw4

Yubico keys can also be inspected with ykman:

ykman info                 # model, firmware version, enabled interfaces
ykman fido info            # PIN status, remaining PIN retries
ykman fido access change-pin
ykman fido credentials list   # discoverable credentials (requires the PIN)

The AAGUID is a 128-bit identifier of the authenticator model. Relying parties can compare it, together with the attestation certificate, against the FIDO Metadata Service to decide which models they accept. Enterprise identity providers use this to allow only approved keys.

Using the same key beyond the browser

A FIDO2 key is not limited to websites.

SSH (OpenSSH 8.2 and later) can create keys whose private half is protected by the security key:

# Discoverable key that also requires the FIDO2 PIN on every use
ssh-keygen -t ed25519-sk -O resident -O verify-required -C "admin@laptop"

# On a new machine, pull resident key handles back from the token
ssh-keygen -K

Use ecdsa-sk instead of ed25519-sk if an older key does not support Ed25519.

Linux local login and sudo can use pam_u2f:

mkdir -p ~/.config/Yubico
pamu2fcfg > ~/.config/Yubico/u2f_keys          # first key
pamu2fcfg -n >> ~/.config/Yubico/u2f_keys      # append the backup key

Then add auth required pam_u2f.so (or sufficient, depending on your policy) to the relevant file in /etc/pam.d/. Always keep a root shell open while testing PAM changes.

Windows and Microsoft Entra ID support FIDO2 keys for passwordless sign-in once the method is enabled in the authentication methods policy, optionally restricted to specific AAGUIDs.

Other applets on the same device

Many keys bundle more than FIDO2. These are separate applets with separate PINs and separate security properties:

• PIV (smart card). X.509 certificates for Windows smart card logon, VPNs, S/MIME and code signing. Managed with the vendor tool or OpenSC.
• OpenPGP card. Signing, encryption and authentication subkeys for GnuPG.
• OATH (TOTP/HOTP). Stores one-time-password seeds; the codes are still phishable, so treat this as a convenience, not as phishing resistance.
• Yubico OTP / static password. Legacy features; disable interfaces you do not use to reduce attack surface.

Selection criteria

When comparing models, the questions below matter far more than brand:

Buy directly from the manufacturer or an authorized distributor. A key from an unknown marketplace seller could be a counterfeit with a pre-generated or logged key. On first use, reset the FIDO2 applet and check the attestation or model identifier with the tools above.

Rolling keys out to a team

1. Start with administrators. Identity, cloud and email admins first, then finance and executives, then everyone else.
2. Issue two keys per person and register both during the same session.
3. Enforce phishing-resistant methods for privileged roles with conditional access or equivalent policy, and remove weaker fallback methods (SMS, voice, OTP) for those roles once enrolment is complete.
4. Write the recovery process down. Who can issue a temporary access pass, how identity is verified and how the lost key is revoked.
5. Track keys as assets. Serial number, owner, registration date and revocation date.

Hardware keys do not protect against a compromised endpoint that hijacks an already-authenticated session, and they do not stop an attacker who can convince a help desk to register a new authenticator. Pair them with session protection and a strict recovery procedure.