Hardware security keys implement the FIDO2 and WebAuthn standards, and the core design decision behind them is that the private key never leaves the device. When you register a key with a service, the hardware generates a unique key pair for that specific site, keeps the private half locked inside its own secure element, and hands the service only the public half. There is no export function, no recovery file, no seed phrase to write down, because a portable private key would undermine the exact property that makes the hardware model stronger than a password or a software-based authenticator app.
There Is No Backup, By Design
This is a deliberate trade-off, not a missing feature. A password can be written down. A TOTP secret can be exported as a QR code and re-scanned elsewhere. A hardware key's private key cannot, and that's the mechanism that makes the key resistant to phishing and remote credential theft in the first place: there is nothing that a remote attacker, or you, can copy off the device. The cost of that guarantee is that physical loss is unrecoverable at the device level. You are not getting the same key back. You are, at best, replacing it with a new one and re-registering everywhere.
Recovery after loss doesn't mean recovering the lost key's private material. It means the account having a path back in that doesn't depend on that specific device. Those are separate problems, and only one of them is solvable.
Why a Single Key Is a Single Point of Failure
Most services that support hardware keys let you register more than one per account, and this is the entire practical answer to the loss problem. Register a primary key you carry daily and a second key stored somewhere separate, a home safe, a drawer at a different location, anywhere that isn't traveling with the first one. Each key generates its own independent credential per site during registration, so losing one doesn't compromise or invalidate the other. If the primary key is lost, the backup key logs you in immediately, and from there you can deregister the lost key and register a replacement as the new backup.
The habit that undermines this in practice is registering only one key because a second one feels redundant, then discovering during an actual loss that the only path back in runs through whatever fallback the service offers, which is often meaningfully weaker than the hardware key was.
What the Fallback Actually Looks Like
Services vary widely in what happens if you have no backup key registered. Some offer one-time backup codes generated at setup, meant to be printed or stored offline, which work but depend entirely on whether you actually saved them somewhere retrievable. Others fall back to account recovery flows built around email or an authenticator app, which reintroduces exactly the weaker security model the hardware key was meant to replace. A smaller number of services have no graceful fallback at all if every registered factor is lost, which is a real risk worth checking before you rely on hardware-only authentication for an account you can't afford to be locked out of.
The most common mistake with backup codes isn't forgetting to generate them, it's where they end up stored. A screenshot of the codes saved to the same phone that also holds an authenticator app defeats the purpose of having a separate recovery path: one lost or stolen device now takes out both factors at once. The same problem applies to a text file sitting in the same cloud drive that also stores your password manager's export. Backup codes are only a genuine second path if they live somewhere with a different failure mode than your primary devices, a physical printout in a drawer, a sealed envelope, anywhere that a single lost phone or a single compromised cloud account doesn't reach.
| Situation | What actually happens |
|---|---|
| Primary key lost, backup key registered | Sign in with the backup key, deregister the lost one, register a new backup |
| Only key lost, backup codes saved | Use a backup code, then register a new key immediately |
| Only key lost, no backup of any kind | Account recovery flow, which may take days and may not fully succeed |
| Key stolen (not just lost) | Deregister it immediately from every service, don't wait to see if it turns up |
Passkeys Solve a Different Problem, Not This One
It's worth separating hardware security keys from synced passkeys, which are often discussed in the same breath but behave differently on exactly this question. A passkey stored in a platform credential manager, iCloud Keychain or a password manager's synced vault, replicates across your enrolled devices, so losing one device doesn't strand the credential the way losing a hardware key does. That convenience comes from the credential existing in more than one place, protected by the platform's own encryption and your account recovery for that platform. A roaming hardware key deliberately doesn't do this. Which model fits depends on whether you're optimizing for convenience across devices or for a credential that provably exists in exactly one place at a time.
This also means the two models fail differently. Lose every device enrolled in a synced passkey vault and recovery runs through the platform account behind it, which is only as strong as that account's own recovery process. Lose a hardware key and there's nothing to recover on the key itself, only the account-side registration to undo and replace. Neither is strictly better in the abstract; a synced passkey trades a hardware key's clean loss story for convenience and cross-device availability, and picking between them for a given account is really a question of which failure mode you'd rather manage.
The Setup That Actually Prevents a Lockout
Register at least two physical keys on every account that supports it, from the start, not after a scare. Store the backup somewhere genuinely separate from your daily-carry key, not in the same bag. Where the service also offers backup codes, generate and store them somewhere durable and offline. If a key is stolen rather than simply lost, treat it as a live compromise: deregister it from every account immediately, because a stolen key that still works on a service is the one scenario where the physical unclonability of the hardware doesn't help you at all.
None of this is complicated once it's set up. The failure mode is almost always the same: a single key registered because it felt sufficient at the time, and a loss that turns into a multi-day recovery process instead of a five-minute swap.