Hardware Security Keys Guide: FIDO2 Keys, YubiKeys and eTokens

Hardware security keys are the strongest widely available defence against credential phishing, but most programmes that buy them still leave a phishable path open through weak enrolment, lost-key recovery or fallback methods. This guide covers the main families of hardware authenticator: FIDO2 security keys, multi-protocol keys such as the YubiKey 5 series, and PKI tokens such as the SafeNet eToken range. It explains the protocols underneath (WebAuthn, CTAP2 and the older FIDO U2F), what attestation and AAGUIDs give you, PIN and lockout behaviour, and how to run issuance, backup keys and the lost key process. It is written for identity, security and end-user computing teams planning or fixing a hardware key deployment, and for architects deciding where keys fit next to passkeys and smart cards.

Key takeaways

• Origin binding is what you are paying for. A FIDO2 key signs a challenge scoped to the real site, so a relayed phishing page gets nothing usable; OTP codes from the same key do not have this property.
• Not every hardware token is phishing-resistant. FIDO2, U2F and PKI smart card functions are; Yubico OTP, OATH TOTP and HOTP functions on the same device are not, and should not count towards phishing-resistant coverage.
• Attestation and AAGUIDs let you control which keys are accepted. Enforce attestation at registration and restrict to approved models where your risk justifies the support overhead.
• Issue two keys, not one. NIST SP 800-63B-4 says verifiers should encourage at least two separate means of authentication; a registered backup key removes most risky help-desk recoveries.
• The key is only as strong as the weakest remaining path. Remove SMS, voice and push fallbacks for key holders, and make lost-key recovery at least as hard as the original enrolment.

What counts as a hardware security key

"Hardware security key" covers several device families with different protections and management needs.

CISA's phishing-resistant MFA fact sheet puts FIDO/WebAuthn and PKI-based authentication in the top tier and token-based OTP a tier lower, with app-based codes. This matters for multi-protocol keys: a YubiKey 5 ships with a Yubico OTP credential in slot 1, and an OTP typed into a phishing page can be relayed like any other code.

How FIDO2 keys work: WebAuthn, CTAP2 and U2F

FIDO2 is two specifications. W3C WebAuthn is the API between the website (the relying party) and the browser or platform. The FIDO Alliance Client to Authenticator Protocol (CTAP) is how the browser or operating system talks to the key. CTAP1 is the original FIDO U2F protocol; CTAP2 adds PIN-protected, discoverable credentials, and the CTAP specification says CTAP2 authenticators should also implement CTAP1/U2F, which is why most keys still work with older U2F integrations.

• Origin and RP ID binding: each credential is scoped to the relying party ID it was registered with, and the origin is part of the signed data. WebAuthn states that operations "cannot be replayed against a different origin". This is the property that defeated the 2022 real-time phishing campaign against Cloudflare, where three employees entered credentials but the attacker could not log in because every employee used a FIDO2 key.
• Transports: CTAP runs over USB HID, NFC and Bluetooth Low Energy, with a hybrid transport for using a phone as a roaming authenticator. An "NFC security key" is a standard FIDO2 key that also speaks CTAP over NFC.
• Roaming authenticators: WebAuthn calls on-device authenticators "platform" and off-device ones "cross-platform". A security key is a roaming (cross-platform) authenticator, which is why one key can be used across several laptops and phones.
• Discoverable credentials (resident keys): when the relying party asks for residentKey: required, the key stores the credential and user handle so the user can sign in without typing a username. Storage is finite: the YubiKey 5 technical manual quotes up to 25 resident keys for the 5 series, so check capacity on any model before using it for many usernameless accounts. Credentials can be listed and deleted with the CTAP authenticatorCredentialManagement command.
• User presence and user verification: a touch proves presence; a PIN or fingerprint provides user verification and makes the key a multi-factor cryptographic authenticator. Set userVerification: required for workforce sign-in. Microsoft Entra ID requires user verification for all FIDO2 authentication.
• credProtect: CTAP defines three protection policies for credentials: userVerificationOptional (0x01, the default), userVerificationOptionalWithCredentialIDList (0x02) and userVerificationRequired (0x03). Level 3 stops anyone with the key but without the PIN from even discovering which accounts it holds.
• Backup flags: WebAuthn authenticator data carries backup eligibility (BE) and backup state (BS) flags. A hardware key credential is device-bound and should report BE as false; a synced passkey reports it as eligible. Relying parties can use these flags to tell the two apart where attestation is not available.

PINs, lockout and reset

The FIDO2 PIN is local to the key: it never goes to the server, and it is checked on the device. That makes it an activation secret in NIST SP 800-63B-4 terms, not a password the IdP stores.

Two consequences follow. With no FIDO2 PIN set at manufacture, whoever holds an unconfigured key first can enrol it, so set or force a PIN at issuance. The PIV defaults are public, so change the PIV PIN, PUK and management key before issuing any key used for smart card logon.

Attestation, AAGUIDs and the FIDO Metadata Service

At registration a key can return an attestation statement signed by a certificate from its manufacturer. The attested data includes the AAGUID, which CTAP defines as identifying the authenticator model (not the individual key). Relying parties use the pair to answer "is this a genuine, certified model we allow?".

• Attestation conveyance: WebAuthn lets the relying party ask for none (the client strips identifying information), indirect, direct (AAGUID and attestation passed through unchanged) or enterprise. Workforce deployments that want model control need direct.
• FIDO Metadata Service (MDS): the FIDO Alliance publishes a signed BLOB at mds3.fidoalliance.org with metadata statements for listed authenticators. The Alliance describes MDS as a repository to "validate authenticator attestation and prove device model genuineness", and suggests downloading the BLOB monthly, verifying its signature and caching it. Policy can then require a certification level (FIDO uses L1, L1+, L2, L3 and L3+).
• IdP enforcement: in Microsoft Entra ID, passkey profiles under Authentication methods > Passkey (FIDO2) offer Enforce attestation, Passkey type (device-bound or synced) and Enforce key restrictions with a Behavior of Allow or Block against a list of AAGUIDs. Enforced attestation needs a packed attestation statement chaining to roots in MDS, and Microsoft ingests MDS monthly, so a new model can take up to four weeks to be recognised. Attestation is checked only at registration: keys registered before you turned it on keep working until you remove them.
• Enterprise attestation: a CTAP 2.1 feature, advertised by the ep option, that lets pre-defined relying parties receive a uniquely identifying attestation such as the key's serial number. Yubico notes few relying parties support it yet.

Example AAGUIDs from Microsoft's eligible-key list show how model-level restriction works: YubiKey 5 Series with NFC is 2fc0579f-8113-47ea-b116-bb5a8db9202a and Google Titan Security Key v2 is 42b4fb4a-2866-43b2-9bf7-6c6669c2e5d3. Removing an AAGUID from an allow list stops every key of that model registered under the policy, so test changes on a pilot group.

Choosing between keys, passkeys and smart cards

• Device-bound FIDO2 keys: choose these for administrators, help-desk staff, finance and anyone whose account would give an attacker broad reach. NIST SP 800-63B-4 requires a non-exportable private key at AAL3 and says syncable authenticators SHALL NOT be used at AAL3; a hardware key meets that, a synced passkey does not.
• Synced passkeys and platform authenticators: better for the general workforce where cost and logistics of physical keys are the barrier. Entra ID treats synced passkeys as phishing-resistant but, because they cannot be attested, with the same posture as other unattested authenticators.
• PKI tokens and PIV: choose these where you already run a PKI and need certificates for Windows smart card logon, VPN, S/MIME or document signing. CISA notes PKI-based MFA "requires highly mature identity management practices". In Entra ID, certificate-based authentication lets certificates on such tokens sign in directly without AD FS, with issuer and policy OID rules deciding single-factor or multifactor strength.
• Hybrid devices: multi-protocol keys and FIDO-plus-PKI tokens let you migrate without issuing two devices. The cost is a larger attack and support surface: more PINs, more defaults to change, more applications to disable if unused.
• Form factor and certification: match connectors to the estate (USB-A, USB-C, NFC for phones). Where FIPS 140 validation or a FIDO certification level is required, confirm the certificate for the exact model and firmware, not the product family.

Small organisations can usually skip model allow lists and enterprise attestation: issue two FIDO2 keys per administrator, enforce phishing-resistant MFA for admin roles and remove SMS. Large organisations need attestation enforcement, an approved-model list, an inventory linking key serial or credential ID to a person, stock management across sites, and a self-service portal or Graph-based provisioning (Entra ID offers FIDO2 provisioning through Microsoft Graph in preview) so the help desk does not register keys by hand.

Issuance, backup keys and the lost key process

1. Bind enrolment to identity proofing. First registration should happen in person, on a supervised video call or from an existing phishing-resistant session, never from a password plus SMS. Entra ID requires MFA in the last five minutes before a passkey can be registered; that is a floor, not a proofing step.
2. Set the PIN at issuance and, where supported, force a PIN change on first use so the issuer never knows it.
3. Register a second key to every account that matters, and record which credential is the backup. Store the backup somewhere separate from the primary, not on the same keyring.
4. Record the binding. NIST SP 800-63B-4 says the CSP record "SHALL contain the date and time of significant authenticator life cycle events". Keep key model, serial or credential ID, owner and issue date.
5. Lost or stolen key: the user signs in with the backup key and removes the lost credential themselves. NIST requires a mechanism to invalidate an authenticator immediately on notification. If no backup exists, treat recovery as a fresh enrolment with the same proofing as step 1, with manager approval for privileged roles.
6. Leavers and returns: remove credentials from the IdP at offboarding. A returned key should be FIDO2 reset before reissue, which also wipes any credentials the leaver registered with personal accounts.

Help-desk recovery is the place attackers go once keys are in. The social engineering of IT service desks in the MGM Resorts breach is the pattern to design against. See the Account Recovery and Help Desk Security Guide.

Rolling out hardware keys

1. Inventory sign-in paths first. List every application, VPN and admin console, and record whether it supports WebAuthn directly, through your IdP, or only through certificates. CISA suggests starting with services that already support FIDO, typically hosted email and SSO.
2. Pilot with IT administrators and the help desk. CISA names these groups as a sensible first phase. They hit edge cases (RDP, jump hosts, older browsers) early and then support everyone else.
3. Configure the IdP in report or optional mode. Enable the FIDO2 method for the pilot group, leave other methods available, and set attestation and key restrictions on a pilot profile rather than the default profile.
4. Test before enforcing: registration with attestation, PIN lockout and reset, lost-key recovery with and without a backup, NFC on supported phones, offline Windows unlock (Entra ID needs the hmac-secret or PRF extension for this), and RDP or virtual desktop sign-in.
5. Enforce for the pilot with a Conditional Access authentication strength (or equivalent) that requires phishing-resistant MFA for privileged roles and admin portals.
6. Expand by risk: finance, HR, executives, developers with production access, then everyone in scope.
7. Remove fallbacks for enforced groups: SMS, voice, push and OTP methods. CISA describes SMS and voice as a last resort.
8. Rollback plan: keep enforcement in group-scoped policies so you can remove a group from the authentication strength without touching others, keep break-glass accounts excluded and monitored, and keep a stock of pre-issued spare keys at each site for outages caused by lost or faulty keys.

Where identity fits

• SSH and infrastructure access: OpenSSH 8.2 added ecdsa-sk and ed25519-sk key types backed by FIDO keys. The private key file on disk is only a key handle; the per-device secret stays on the token. OpenSSH 8.4 added verify-required to demand a PIN per use. See the SSH Key Management Guide.
• Break-glass accounts: emergency access accounts are a strong fit for two FIDO2 keys held in separate secure locations, with alerting on every use. See the Break-Glass Account Guide.
• Non-human identities: service accounts, CI pipelines and AI agents cannot touch a key. Do not let MFA exemptions for them become unmanaged shared accounts; give workloads federated, short-lived credentials. See the NHI Authentication Guide.

Detection and measurement

Once phishing stops working, attackers move to enrolment and recovery, to session tokens stolen after sign-in, and to accounts outside enforcement. Monitor those paths.

• Registration events: alert on a new security key or passkey registered to a privileged account, especially when followed by sign-in from a new location or device, and on any registration that fails attestation or key restrictions.
• Method removal and reset: alert on deletion of all phishing-resistant methods from an account, or on a temporary access pass issued to a key holder.
• Fallback use: report sign-ins by key holders that used SMS, voice, push or OTP. In an enforced group the number should be zero.
• Push spam and AiTM signals: repeated MFA prompts (MITRE ATT&CK T1621) and sign-ins via adversary-in-the-middle proxies (T1557) against accounts not yet on keys show where to roll out next.

Framework mapping

Common failure patterns

• Keys issued, push and SMS left on: attackers choose the weakest method still allowed. MFA fatigue against a contractor's account led to the Uber breach; a key-holding account with push still enabled is exposed to the same attack.
• Counting OTP mode as phishing-resistant: a multi-protocol key used only for Yubico OTP or TOTP gives a code an AiTM proxy can relay. The SMS phishing campaign behind the Twilio breach also hit Cloudflare, which reports that the attacker relayed passwords and TOTP codes in real time and failed only because its staff used FIDO2 keys.
• Single key per user: every loss becomes a help-desk recovery, and help-desk recovery becomes the attack path.
• No PIN set at issue, or PIV defaults unchanged: the key ships with no FIDO2 PIN and published PIV credentials, so possession alone may be enough.
• Attestation switched on after rollout: enforcement applies only to new registrations, so unapproved or personal keys registered earlier stay trusted until someone audits and removes them.
• Treating keys as session protection: keys protect the sign-in ceremony. Session tokens stolen afterwards need short lifetimes and token binding controls. See the Token and Session Security Guide.

Practitioner checklist

• Classify every device you issue by function, and count only FIDO2, U2F and PKI functions as phishing-resistant.
• Require userVerification: required and a PIN set or forced at issue; change PIV PIN, PUK and management key defaults.
• Enforce attestation and an approved AAGUID list for privileged users, and audit credentials registered before enforcement.
• Issue and register two keys per privileged user, stored separately.
• Bind first enrolment and lost-key recovery to identity proofing equal to or stronger than the key itself.
• Enforce phishing-resistant authentication strength for admin roles and portals, then remove SMS, voice, push and OTP fallbacks for those users.
• Alert on new key registration, method removal and temporary access passes for privileged accounts.
• Move engineers' SSH keys to ed25519-sk or ecdsa-sk with verify-required where infrastructure supports it.
• Reset returned keys before reissue, and report coverage, backup-key rate and fallback sign-ins monthly.

Standards and references

• NIST: SP 800-63B-4 Authentication and Authenticator Management
• FIDO Alliance: Client to Authenticator Protocol (CTAP) 2.2
• W3C: Web Authentication Level 3
• FIDO Alliance: FIDO Metadata Service
• CISA: Implementing Phishing-Resistant MFA
• Microsoft Learn: Enable passkeys (FIDO2) in Microsoft Entra ID
• Yubico: YubiKey 5 Series technical manual, applications
• Cloudflare: The mechanics of a sophisticated phishing scam and how we stopped it

Related NHI Mgmt Group resources: Passwordless and Passkeys Guide · MFA Guide · Account Recovery and Help Desk Security Guide · Privileged Access Management Guide