How Do You Back Up FIDO2 Keys Without Creating a Security Risk?

The Short Answer: Back Up Access, Not Private Keys

A FIDO2 security key generally cannot be “backed up” by copying its secret credential. The private key is created inside the authenticator and normally cannot be exported, even by the account to which it is registered. Attempting to bypass that protection with software, a spreadsheet, an email attachment, or a password-manager note can leave you with a secret that attackers can steal more easily than they can steal the key itself. The safer approach is to create a recovery path: register at least 2 keys, keep them in separate physical locations, enable at least 1 independent account-recovery method, and test that recovery method before you need it.

Also worth reading: How Do You Review a HIPAA Transcription Vendor Without Missing Security, Privacy, or Accuracy Risks? · How Do You Test Voice Agent Security Without Real Customer Data? · How Does FIDO2 Backup Security Protect Your Credentials and What Should You Know in 2026?

This guidance applies as of October 1, 2026, to USB and NFC FIDO2 keys, passkeys stored on compatible phones or computers, and services using WebAuthn, FIDO2, or related passkey authentication. The terminology is not always consistent. Some organizations call a physical authenticator a “security key,” while others use “passkey” for credentials synchronized through a platform account. A hardware security key is still a hardware authenticator even when the website labels its login credential a passkey. The operational question is not “Where did I save a copy of this key?” but “How will I authenticate after losing, breaking, or replacing this authenticator?”

Why FIDO2 Keys Are Not Normally Exportable

FIDO2 relies on public-key cryptography. When you register a key, your device creates a private key that remains inside the authenticator and a public key that the service can store. During authentication, the service sends a challenge to the key, the key signs that challenge, and the service verifies the signature. The private key is never sent to the website. Even if someone steals the public key, that public key does not let them generate valid signatures on their own.

That design is one of the main reasons FIDO2 authentication is resistant to phishing. A password can be entered into a convincing fake login page, but a USB security key will normally communicate only with the legitimate site or with a browser that has verified the site’s origin. A passkey stored in a synchronized platform ecosystem may be handled differently because the credential can be restored through that platform’s encrypted account system, but the underlying private credential should still not be copied into an ordinary document or password database.

The phrase “back up my FIDO2 key” therefore needs clarification. You can back up the account access plan, the registration information, the recovery codes, the device identifiers, and the location of a spare key. You usually cannot export the private key itself. If a vendor claims to offer a file-based export of a FIDO2 private key, treat that as a separate product and investigate its threat model carefully; it may be an emulator, a software credential, or a deliberately weakened system rather than a normal hardware key.

Recommended Recovery Architecture

A practical setup includes at least 2 independently usable FIDO2 credentials. Register the first key as the primary authenticator and the second as a backup, preferably with a different manufacturer or ecosystem when practical. If both keys are stored in the same drawer, the same bag, or the same cloud account, a fire, theft, flood, or account compromise can eliminate both at once. Keep one key at home and another at work, with a family member, or in a secure location away from your primary device. Record where each key is stored in a way that does not reveal its PIN, serial number, or other sensitive information to an unauthorized person.

For a high-value account, consider 3 authentication methods rather than 2: a primary hardware key, a backup hardware key, and a carefully protected recovery option such as a printed recovery code, a hardware-backed device credential, or a second trusted passkey. Recovery methods have different risks. Recovery codes can be stolen if photographed or copied, while an email-based reset process can be defeated through compromised email. A second key stored in another location is often more reliable than several copies of the same recovery code.

Before enabling security keys, inspect the service’s recovery policy. Find out whether it requires 2 registered keys, whether it offers one-time recovery codes, whether recovery is available by SMS or email, and whether support can bypass the key requirement after identity verification. The best service is not merely the one that supports security keys; it is the one that provides a recovery process you understand and have tested while you still have uninterrupted access.

Practical Setup Procedure

Start by choosing at least 2 authenticators that support the protocols required by your important services. USB-A, USB-C, NFC, and Bluetooth capabilities vary, and some older services support only traditional U2F security keys. A key advertised as FIDO2-compatible may not work with every account, especially if the service requires a particular form factor, resident credentials, or a specific browser. Check the service’s help documentation and confirm that the key supports both registration and authentication before relying on it for your only access route.

Add the first key to each important account, then add the second key using the account’s “add another security key” or equivalent function. Do not remove the existing authentication method until both keys have been tested. Open a private browser window, sign out, and authenticate with the first key. Repeat the process with the second. Test a failed attempt as well, if the service permits it, to confirm that the backup is genuinely registered and not merely saved in the account interface.

Next, record the recovery information according to the service’s instructions. Some services display one-time recovery codes once; others send them to an email address or store them in a secure settings page. Store codes in a secure offline location, not in a note whose synchronization is automatic. A password manager can be appropriate for encrypted storage of recovery information, but it should not be used to store a fake “exported FIDO2 private key.” Use a strong, unique master password and hardware-backed or otherwise well-protected account access.

Finally, perform a scheduled review. At least twice per year, verify that both keys still authenticate, inspect the account’s recovery settings, confirm that recovery codes have not expired, and replace a key that is physically damaged or no longer supported. A key that has been sitting unused for 18 months may have lost firmware trust, may belong to an old account, or may no longer be recognized after a device reset.

Comparing Backup and Recovery Options

No method is perfect, so compare recovery options by resistance to theft, phishing, loss, and account compromise. A second hardware key provides excellent phishing resistance but depends on physical custody. A platform passkey may be convenient and recoverable across devices, but its security can depend on the strength of the platform account and its synchronization controls. Recovery codes are useful during an emergency, yet they function like bearer secrets: whoever obtains one may be able to sign in.

The table shows why “multiple methods” is better than “multiple copies.” Two identical files in two folders provide little additional security if one compromised service can access both. Two independently protected credentials provide more meaningful separation. For example, a hardware key in a home safe and another key in a work safe are better than a recovery code stored in both a phone note and a desktop document.

Common Mistakes That Create Security Risk

The most damaging mistake is believing that a photograph, PDF, CSV file, or text message is a safe backup of a FIDO2 credential. A normal backup file may be synchronized to a cloud provider, indexed by a search engine, copied into a support chat, or exposed through malware. If the file contains a usable private key or bearer secret, its presence in an ordinary storage system can turn a physical security problem into a direct account-takeover problem.

Another mistake is registering 2 keys but keeping them together. The backup should survive the same event as the primary. A house fire, flooded office, stolen laptop bag, or compromised home network can affect both keys if they share a location. It is also a mistake to use a key as both the primary authenticator and the only record of where the backup is. Write a simple location record, such as “backup key: secure location B,” without recording secrets or detailed identifiers that would help an attacker find it.

Do not disable the password or other recovery method until the alternative has been tested. Conversely, do not assume an SMS fallback is harmless. If an attacker can take over the phone number associated with the account, they may reset the password, add their own security key, and remove yours. Review the service’s notification settings, use alerts for new-device registrations and password changes, and ensure that the recovery email account has its own strong FIDO2 protection where possible.

What to Do When a Key Is Lost or Replaced

If a key is lost, act quickly but deliberately. From a trusted device, inspect the account’s security settings and revoke the missing key. If another key is registered, use it to sign in and remove the lost credential. If the account supports one-time recovery codes, use a code only after confirming that the request came from the legitimate service and not a phishing message. Do not send a recovery code to a caller, support chat, or email address merely because someone claims to represent the service.

If no backup method works, use the service’s documented account-recovery process. This may involve verifying identity through a trusted device, a previous passkey, an official support channel, or a combination of factors. Be especially cautious if the service asks you to disable security-key enforcement or install remote-access software. Legitimate recovery should not require you to give a stranger your private key, your PIN, your one-time code, or unrestricted control of your computer.

After access is restored, treat the incident as a credential exposure. Add a new backup key, generate new recovery codes, review recent sign-ins, remove unknown devices, and check whether forwarding rules or application passwords were created. If the missing key may have been stolen, contact the service immediately. A key protected by a PIN offers some resistance, but a key without a PIN can be usable by anyone who obtains it, so a lost key is not equivalent to a forgotten key.

Passkeys, Security Keys, and Platform Accounts

Passkeys and hardware security keys are related but not identical. A hardware security key is a dedicated physical authenticator. Its credential generally remains on the device. A passkey may also use public-key cryptography, but it may be stored in a phone, computer, password manager, or platform account and synchronized through a vendor-controlled service. That synchronization can provide convenient backup, but it also creates a dependency on the vendor’s account security, device management, and recovery process.

A synchronized passkey can be a good recovery option when the provider has strong account protections, trusted-device controls, and a clear recovery policy. It is less attractive when the passkey is stored in an account protected only by a weak password, when the platform can restore credentials without sufficient identity checks, or when the user cannot distinguish a platform passkey from a hardware key in the account interface. Label your own records clearly: “USB FIDO2 key A,” “USB FIDO2 key B,” and “platform passkey C” are more useful than several items all called “passkey.”

Do not use a cloud document to store a private key, even if the document is described as an encrypted backup. First verify what is actually encrypted, who can decrypt it, whether the key can be exported, and whether the system permits offline recovery. For a hardware security key, there is usually no legitimate private-key export to protect in the first place. The correct backup plan centers on enrollment and recovery, not on defeating the authenticator’s design.

When to Act and How Often to Review

Act immediately if an important account currently depends on one hardware key, one phone, or one synchronized passkey. Begin by adding a second authenticator, but do it while you can still sign in normally. Accounts that can trigger financial transactions, change email passwords, alter domain records, or administer cloud infrastructure deserve priority over low-value subscriptions. In a small organization, the owner’s email, identity provider, registrar, and code-hosting account should be treated as critical recovery targets.

Review the setup at least every 6 months and after any major device replacement, operating-system migration, phone-number change, email compromise, or change of home or work location. During each review, test both keys, confirm that recovery codes still work, check for unknown credentials, and verify that the backup key is physically present. A 15-minute review is usually enough for a personal account; a documented, tested process is more appropriate for administrators.

A reasonable target is to have at least 2 hardware-capable paths for each critical account, with the paths separated physically or cryptographically. Add a third method when the account is especially important or when losing access would cause substantial financial or operational harm. The precise percentage of accounts that will be attacked cannot be predicted, but maintaining redundancy is inexpensive compared with emergency account recovery, lost data, business interruption, or a successful takeover. The safest FIDO2 backup is not a copy of the key; it is a tested plan to regain access without ever exposing the private credential.