Hardware security keys can make important accounts much harder to phish. They can also create a new problem if you only register one key and then lose it.
A security key backup plan is the boring part that makes stronger MFA usable. It answers where keys are registered, where spares are stored, how recovery codes are handled, and what to do if a key is lost, stolen, or damaged.
This guide is for freelancers, solo founders, developer-consultants, and small technical teams that want stronger account protection without creating lockout risk.
The short version
Do not use one hardware security key as your only way into critical accounts. Register at least two keys where possible: one daily key and one backup key. Store the backup somewhere protected but reachable, save account recovery codes, and document which accounts each key protects.
For the highest-impact accounts, test the backup key before you need it. A spare key that was never enrolled is not a backup.
What a security key is good at
Security keys are strongest when the main threat is phishing. Instead of typing a code that can be copied into a fake site, you physically use the key with the legitimate service. This makes ordinary credential phishing much harder.
That is valuable for accounts like primary email, password manager, GitHub, domain registrar, cloud storage, payment tools, and admin consoles.
Security keys do not remove every risk. You still need recovery codes, safe device practices, account monitoring, and a plan for lost hardware.
The minimum viable backup plan
For a solo operator, the minimum plan is:
| Item | Purpose |
|---|---|
| Daily key | The key you carry or keep near your workstation. |
| Backup key | A second enrolled key stored separately. |
| Recovery codes | Last-resort account access. |
| Recovery note | A map of which keys protect which accounts. |
| Review schedule | A reminder to test and update the setup. |
The most important word is enrolled. Buying a spare key is not enough. It must be added to each critical account before the daily key is lost.
Which accounts should get security keys first
Start with accounts that can recover or damage other accounts:
- primary email
- password manager
- domain registrar
- GitHub or source-code hosting
- cloud storage
- payment and banking-related tools
- client admin accounts
Do not spend your first hour adding keys to low-impact accounts while primary email still depends on one phone.
How many security keys do you need?
Most solo operators should think in pairs:
| Setup | Use case |
|---|---|
| Two keys | One daily key and one backup key. Good starting point. |
| Three keys | Daily key, local backup, and offsite backup. Useful for travel or high-value accounts. |
| Team-managed keys | Needed when multiple people need break-glass access. Requires more process. |
If you travel frequently, keep the backup location in mind. A spare key locked at home does not help during international travel, but carrying every key in one bag defeats separation.
Where to store backup keys
Store backup keys separately from the daily key. Practical options include a locked drawer, safe, trusted office location, bank safe deposit box, or another controlled physical location.
Do not label a key with the account names in plain language. If you need labels, use a neutral label that only makes sense with your recovery note, such as Key B or Backup key 2026.
The recovery note should say which accounts are enrolled with which key. The key itself should not advertise what it unlocks.
Do not skip recovery codes
Security keys are strong, but they are hardware. Hardware can be lost, broken, stolen, or unavailable.
For each critical account, save recovery codes after enrolling security keys. Store them outside the account they recover and update them when used or regenerated.
See Backup Codes vs Recovery Keys if the terminology is unclear.
Test the backup key
After enrolling a backup key, test it. Use a private browser window or another trusted browser, sign in, and confirm the backup key works before you put it away.
Also test after major changes: new laptop, new phone, account recovery update, passkey migration, travel preparation, or password manager changes.
Do not remove older methods until the new setup has been tested.
What to document
Keep the note short and useful:
| Field | Example |
|---|---|
| Key label | Daily key, Backup key B |
| Storage location | Office drawer, home safe, travel pouch |
| Accounts enrolled | Email, password manager, GitHub, registrar |
| Backup codes location | Printed recovery folder, password manager note |
| Last tested | 2026-06-20 |
| Lost-key action | Remove key from accounts, rotate affected methods |
Do not write PINs, passwords, or raw recovery codes directly into the map unless the document is intentionally stored as sensitive emergency material.
What to do if a security key is lost
If a key is lost, do not assume disaster. Use another enrolled method to sign in, then remove the lost key from critical accounts.
Work in priority order:
- primary email
- password manager
- domain registrar
- GitHub and deployment accounts
- cloud storage
- payment tools
If the key may have been stolen with a laptop, bag, or written notes, treat the situation more seriously. Review sessions, rotate exposed credentials, and check account activity.
For a broader lost-device process, read What To Do If You Lose Your 2FA Device.
Security keys and passkeys
Some security keys can store passkeys. Some passkeys sync through platform accounts. Some passkeys are device-bound. The user experience may look similar, but the recovery model can differ.
Before relying on a passkey or hardware key, understand where the credential lives and how you would recover if the daily device is unavailable.
For tradeoffs, see Passkeys vs Authenticator Apps.
Common mistakes
The most common mistake is buying one key, enrolling it everywhere, and calling the job done. That creates a single point of failure.
The second mistake is owning a spare key but never enrolling it. A key in a drawer is not a backup unless the accounts already trust it.
The third mistake is storing every key, recovery code, and device in the same bag. Theft, fire, or simple loss can remove every recovery option at once.
Good next step
Choose two critical accounts, such as primary email and GitHub. Enroll your daily security key and backup security key in both, save fresh recovery codes, and test the backup key before storing it.
Related guides:
- How To Secure Your GitHub Account
- How To Avoid Account Lockout When Using MFA
- Where To Store Backup Codes And Recovery Keys