YubiKey and FIDO2 keys: everything you weren't told

A security researcher loses his key in a taxi in Berlin, on a Sunday night. One key. Forty-seven accounts locked behind it. He spent three weeks recovering his access one by one, through recovery procedures that were all different, some of them impossible without calling a support line that only answers during the business hours of another time zone. “I thought one key was enough.” I hear that line roughly once a month. It is, by a wide margin, the most common failure I run into with hardware keys: you buy one, you register it on two or three accounts, and you never think about the loss scenario until it happens.

The usual trap

Buying a hardware key is not a security strategy. The key is a tool. The strategy is the deployment: how many keys, on which accounts, where the backup lives, how you handle loss, how you handle the lifecycle. The dominant advice stops at “get a YubiKeyYubico hardware authentication key supporting FIDO2/WebAuthn, OTP, PIV, OpenPGP.See glossary, it’s the best MFAMulti-factor authentication: combining two independent proofs of identity to log in.See glossary.” That’s true, and it’s not enough. It’s exactly like telling someone “get a fire extinguisher” without saying how many, where to put them, and who knows how to use one.

The configuration I see most often: a single key, registered on Google and GitHub, with every weak recovery method still active in parallel. Backup SMS on an ordinary mobile number, a recovery email with no second factor, security questions whose answers are sitting on LinkedIn. In that configuration, the key does not change your exposure in any meaningful way: it adds an armored door next to an open window. An attacker who wants in does not force the armored door. He triggers a SIM swapAttack where a fraudster convinces your carrier to port your number to their SIM.See glossary, intercepts the backup SMS, and resets your access without ever meeting your key.

The other trap is more subtle and more painful: the key does its job too well. FIDO2Strong authentication standard using hardware cryptographic keys, phishing-resistant.See glossary is designed so that no copy of the credential ever leaves the key. That is precisely what makes it immune to phishing — and it is also what locks you out the day the key falls down a storm drain. There is no “forgot my password” for a lost physical object. The only countermeasure is redundancy: having a second key in place before the incident. The baseline rule fits in one sentence: every critical account must have two keys registered, and the alternative recovery methods must be at least as strong as the key itself. Everything else follows from that.

Real inventory: what a key actually does, and against what

A hardware key is not a single-purpose object. Depending on the protocol it speaks with the service, it protects you against different things. Confusing those protocols means believing you’re covered where you are not.

The central protocol, the one that justifies the purchase on its own, is FIDO2Strong authentication standard using hardware cryptographic keys, phishing-resistant.See glossary and its browser interface WebAuthnBrowser API enabling FIDO2 authentication on websites.See glossary. Here is what it does that nothing else does: when you register a key on a site, it generates a cryptographic key pair bound to the exact domain of the service — accounts.google.com, for example. On every login, the key verifies that the domain requesting authentication matches the registration domain. A phishingSocial engineering attack pushing targets to disclose credentials or execute code.See glossary page hosted on accounts-google.com or google.secure-login.example does not match. The key refuses to sign. It doesn’t ask your opinion, it doesn’t trust you to catch the typo in the URL: it observes the domain mismatch and stops. No TOTP6-digit code generated every 30 seconds by an app (Google Authenticator, Authy, etc.).See glossary code, no SMS, no push notification does this — all of those factors can be typed into a fake page and replayed in real time by the attacker. It is the only anti-phishing defense that holds up against a competent human operator on the other side.

The other protocols are useful bonuses, not the core. OTP: the key can generate a one-time code for sites that don’t yet support FIDO2. PKISystem managing certificates and public keys to authenticate identities.See glossary via PIV (Personal Identity Verification): the key stores x.509 certificates for SSH authentication by certificate, smartcard login on Windows, document signing — the private key never leaves the hardware, so a compromised laptop cannot exfiltrate it. PGPEnd-to-end encryption and signature system, created by Phil Zimmermann in 1991.See glossary: the key signs your Git commits and decrypts your email without the private key ever touching the disk. In all of these cases, the principle is identical: the cryptographic operation happens on the chip, not on the host machine. That is what turns a “copyable” secret into an “unextractable” one.

One technical detail changes everything in practice, and nobody explains it to you at the point of purchase: the difference between resident and non-resident credentials. A non-resident credential (the historical form, called “server-side”) is not stored on the key — the service keeps an encrypted blob that it hands back to the key at authentication time. The key can therefore handle an unlimited number of them, but it “knows” nothing: it cannot list your accounts, and you always have to supply a username to start the login. A resident credential (discoverable, the kind that passkeysConsumer FIDO2 implementation: auth key stored and synced by Apple/Google/Microsoft.See glossary require) is stored inside the chip: the key becomes able to present itself alone, with no username, which is what enables “usernameless” login. The downside is harsh: memory is limited — on the order of 25 resident credentials on a YubiKey 5, more on recent generations — and above all, a resident credential cannot be copied or exported. If you build everything on resident passkeys and you lose the key, you don’t “recover” anything: you fall back to the service’s recovery procedure. This is exactly why the second key must also receive its own resident credential on every account concerned.

Now the honest threat model. What a hardware key does not protect you against. It does not protect an account on which a weak recovery method stays active: the attacker goes through the weak link, full stop. It does not protect against physical loss if you have no backup: you become your own adversary. It does not protect against a badly coded service that accepts a downgrade to a weaker factor “because you forgot your key” — and a lot of consumer services still do this, offering an SMS fallback the moment the key isn’t plugged in. And it does not protect against an attacker who has persistent root access to your machine while the key is plugged in — he doesn’t steal the key, he hijacks an already-authenticated session. The key secures authentication, not the session that follows. Understanding that perimeter means you stop believing that a 50-euro piece of plastic is an invincibility cloak.

That leaves the question of touch. On most keys, FIDO2 authentication requires a “presence check”: a physical contact on the gold disc. That gesture proves a human is present, which blocks remote use by malware that has access to the USB port. But a simple contact is not proof of identity: anyone holding the key can touch it. Biometric models add a local fingerprint check — the key only signs if the enrolled fingerprint matches. For a shared workstation, an open-plan office, or a profile worried about opportunistic theft of the plugged-in key, that nuance matters. For most uses, the physical contact is enough, because the attacker who already has your key in hand probably also has your laptop, and the problem is no longer the same one.

The right approach: the two-key rule, and deployment by criticality

The pragmatic shift fits in one word: redundancy before migration. You never activate a key on a critical account without registering a second one in the same session. Not “later,” not “once the second one arrives”: in the same session, or you don’t touch the account. It’s counterintuitive, because the instinct is to secure things fast. But a single key on a critical account is a delayed-action trap you set for yourself.

Concretely, I systematically apply the two-key rule, ideally with two different models. A primary key — on you at all times, keychain or inside pocket, the one you use daily. A backup key — in a physically distinct location: a safe at home, a bank vault, or with a trusted relative, never in the same bag as the primary. If you lose the bag, you must not lose both keys at once. Two different models is your insurance against a manufacturing defect or a recall: if a flaw hits one model, the other stays valid. For highly exposed profiles — executives, journalists, people under targeted threat — a third key with a trusted third party covers the extreme scenario: you are incapacitated, abroad without your bag, or the backup is unreachable.

The order of deployment is not trivial. You start with the account whose fall brings down all the others, then work down by decreasing criticality. The sequence I recommend: first the password manager, the keystone of your whole digital life; then the primary email, because it is the recovery vector for almost everything else; then the federated identity account (Google, Apple, Microsoft) that often serves as SSOMechanism allowing one authentication to access multiple applications.See glossary into a dozen third-party services; then GitHub/GitLab if you develop, and finally bank and crypto accounts. For each account: register the primary key, register the backup, download the offline recovery codes, keep the old MFA active for now, and disable it only after verifying that everything works on both keys. The migration spreads over two to three weeks, not over one irritated evening.

Last point, the only test that truly counts: log out of an account and log back in using the backup key alone, once, for real. Until you have run that flow, you don’t know if it works — you hope so. An untested recovery plan is a plan that fails on exactly the day you need it.

Choosing the right model without getting it wrong

The market looks complicated. It isn’t. Three questions are enough to decide: which connector, which protocols, and which level of physical verification. The rest is marketing.

The connector first, because it’s the dumbest trap: a USB-A key in a laptop that only has USB-C is a paperweight. Look at your ports before you buy. Most recent ultrabooks (MacBook, Dell XPS, Surface) are all USB-C; towers and a lot of corporate PCs keep USB-A. NFC, for its part, is not a luxury: it’s what lets you tap the key against the back of the phone to authenticate on mobile, with no adapter, no dongle. For anyone who uses their phone — that is, everyone — NFC is non-negotiable.

The reference model remains the YubiKey 5 NFC (USB-A + NFC) or its twin 5C NFC (USB-C + NFC). They speak every useful protocol: FIDO2Strong authentication standard using hardware cryptographic keys, phishing-resistant.See glossary/WebAuthn, OTP, PIVSystem managing certificates and public keys to authenticate identities.See glossary for certificates, OpenPGPEnd-to-end encryption and signature system, created by Phil Zimmermann in 1991.See glossary. It’s the right default for 90% of people and for a first enterprise deployment, because it covers every use case without having to re-buy hardware six months later. The Nano variants (5 Nano, 5C Nano) are miniature versions that stay permanently plugged into the port: handy at the desk so you never lose it, but it’s exactly what you forget in a laptop you lend out or get stolen. Reserve those for a fixed workstation that doesn’t move.

The biometric models (YubiKey Bio) add the fingerprint described above: the key only signs for the right person. The price goes up, the protocol coverage often narrows to FIDO2 only, but for an executive or a profile under threat, the assurance that a stolen plugged-in key isn’t enough is worth the premium. On the alternatives side, the Nitrokey, designed in Germany with open hardware, appeals to profiles who refuse to depend on a single vendor or want to audit the firmware — the management tooling is less polished, the FIDO2 and OpenPGP function equivalent. The Google Titan does reliable FIDO2 and nothing else: not programmable, simple, fine as a cheap backup next to a full YubiKey. Mixing brands is in fact a healthy strategy: a YubiKey 5 as a versatile primary, a second key from another brand or another model as backup, so you don’t depend on a single firmware lineage.

Lifecycle, reset and revocation

A key is not a one-off purchase, it’s an asset to manage over time — exactly like a ring of physical keys. Three moments matter: loss, erasure, and departure.

On the loss of the primary key, the scenario is comfortable if you did the work up front: you keep logging in with the backup, you order a replacement, you register it on all accounts, and only then do you remove the credential of the lost key, account by account. Watch the trap: on many services, “removing a key” deletes a credential on the server side, but the lost physical key, if found, stays technically valid for the accounts you didn’t clean up. Hence the inventory — knowing precisely which accounts each key is registered on. That’s what ykman tells you: ykman fido credentials list enumerates a key’s resident credentials, ykman info gives its general state. Without that tool, you’re managing blind.

Erasure (reset) is the operation you neglect until the day you need it under pressure. ykman fido reset wipes all resident FIDO2 credentials and resets the PIN; ykman piv reset starts over on the certificate side; the OpenPGP and OTP slots reset separately. The use cases: reselling a key, a key inherited from a departed colleague, or a key suspected of compromise that you wipe before reuse. The day you resell or recycle a key without resetting it, you potentially leave exploitable credentials and a certificate for the next buyer. Knowing these commands cold means not improvising under fire.

In an enterprise, revocation is the link people forget to wire up. A key must be tied to an identity in the IAMCentralized management of identities and access to resources.See glossary, and a departing employee must trigger the invalidation of their credentials the same way their email account is disabled. An orphaned FIDO2 credential — valid, attached to a still-active account, in the pocket of an ex-employee — is exactly the kind of invisible security debt that only shows up at the incident. The enterprise mode of the keys (attestation, locked configuration, enforced PIN) exists precisely to make that fleet auditable. The same logic applies to reset: it’s a documented procedure, not a gesture left to each individual’s initiative.

What this means concretely

Mistakes we see all the time

• One key, no backup. The reigning mistake. It works perfectly until the day the key falls into an airport toilet. It’s not a question of “if” but of “when.”
• The backup registered on some accounts only. You add it on Google and GitHub, you forget the password manager. Result: when you lose the primary, you keep access to the accessory and lose access to the central vault.
• Recovery codes never saved. They are the ultimate safety net. Lost at the same time as the key, recovery becomes an ordeal, sometimes a permanent dead end.
• Primary and backup in the same bag. Two keys, a single physical point of failure. One stolen bag and you’ve lost both at once — you might as well have had only one.
• Weak recovery methods left active. Backup SMS, a recovery email with no MFA, public security questions. The key becomes decorative: the attacker doesn’t attack it, he bypasses it.
• No test of the backup flow. You register the second key and never use it. On the day, you discover that a service required a forgotten step. The untested plan is not a plan.
• Confusing a hardware key with a synced passkey. A passkeyConsumer FIDO2 implementation: auth key stored and synced by Apple/Google/Microsoft.See glossary synced to a cloud (iCloud, Google) is convenient but does not live in an unextractable chip: its threat model differs. For higher-value accounts, the hardware key remains the notch above.

Actionable checklist

• N1 Buy two hardware keys, ideally two models (primary + backup)
• N1 Register both keys on the password manager first
• N1 Register both keys on the primary email and the federated identity account
• N1 Download and store offline the recovery codes for each critical account
• N2 Store the backup key in a location physically distinct from the primary
• N2 Test a full login with the backup key alone before disabling the old MFA
• N2 Disable weak recovery methods (SMS, unprotected email) after validation
• N3 Install ykman and inventory the credentials registered on each key
• N3 Deploy in the enterprise by circle of criticality (admin → executives → sensitive functions)
• N3 Register a third key with a trusted third party for highly exposed profiles

Further reading

The official Yubico documentation(opens in a new tab) covers ykman, PIV mode, and resident credential management in detail — read it before any serious deployment. The FIDO Alliance specifications(opens in a new tab) and the W3C WebAuthn Recommendation(opens in a new tab) explain why the domain-binding mechanism makes phishing inoperative: useful for arguing the case to a leadership that doubts the return on investment. Finally, NIST SP 800-63B(opens in a new tab) sets out the authenticator assurance levels expected on the enterprise side, in particular for privileged accounts.