Your Recovery Codes Need a Better Home

Imagine a very bad Tuesday.

Your phone is dead. Your laptop was stolen. You try to open your email on another computer, but it asks for a code from the authenticator app that was on the phone. Fine, you think, the recovery codes are in the password manager. Then the password manager asks for the same missing second factor.

The backup file was on the laptop.

Its second copy was in cloud storage connected to the email account you can't open.

Nobody hacked you. You're still locked out.

This is the stupid side of good security. We spend time protecting accounts from strangers and then build a recovery process that depends on every device and service working normally. Of course it looks safe on an ordinary day. Recovery codes exist for the day that isn't ordinary.

The question seems simple: where should I keep these codes?

The honest answer is more annoying. There isn't one perfect place. You need a few places that fail differently, and the arrangement has to remain understandable when you're tired, worried, using an unfamiliar computer, or explaining it to someone who doesn't care about your beautiful security system.

That last part matters.

Recovery material is a key

A recovery code isn't a harmless note. Whoever has it may have a way into the account, sometimes with only one other piece of information. Treating it like a receipt in the Downloads folder is strange when you think about what it can do.

Services also use similar names for different things. Google gives you a set of single-use backup codes. Microsoft uses a 25-digit recovery code and replaces the old one when a new code is generated. Apple's recovery key is a 28-character secret with much heavier consequences. If you enable it and later lose the key along with access to a trusted device, Apple says you can be locked out permanently.

Then there are TOTP seeds, Emergency Kits, passkeys, spare security keys, and provider-specific recovery contacts. They don't behave in the same way. A one-time code can be crossed out after use. A TOTP seed can reproduce authenticator codes again and again. A hardware key sitting in a drawer is useless unless it was already registered with the account.

So the first job is identification. Write down what the item actually is, which account it belongs to, when it was created, and whether using it invalidates anything else.

Plain names help. Mysteries don't.

Look for the circle

Before buying a safe or making an encrypted container, test the dependency.

If the account disappears from your life for one hour, can you still reach its recovery material without using that account?

Google codes stored only in Google Drive fail this test. An Apple recovery key kept only in iCloud Notes fails it too. The Emergency Kit for a password manager can't live exclusively inside that password manager. An encrypted file isn't very impressive when its only passphrase is stored inside the file.

These arrangements can survive for years without showing the problem. That's why they're dangerous. The trap becomes visible at the exact moment you need the exit.

Apple tells users to print or write down the recovery key, keep it somewhere safe, and consider more than one location. The company specifically warns against leaving the only copy in Apple Passwords, iCloud Photos, Notes, or iCloud Drive. NIST's current authentication guidance also describes saved recovery codes as secrets intended to be kept offline and stored securely.

Paper, apparently, is still alive.

The paper envelope is boring and excellent

Print the critical codes or write them very clearly. Put them in an opaque envelope. Add the date, seal it, sign across the seal, and store it with documents that already deserve protection.

That signature won't stop a determined person. It can tell you that the envelope was opened, which is useful. If the seal looks wrong, enter the accounts through a normal method and regenerate the exposed codes.

The paper inside should be understandable without a tutorial. It needs the service name, account identifier, official recovery address, generation date, number of available codes, primary MFA method, and the location of another valid route. Avoid screenshots when plain text will do. Interfaces age. Text survives.

A small notice on the envelope is enough:

EMERGENCY DIGITAL ACCESS
Prepared: YYYY-MM-DD
Review after: YYYY-MM-DD
If this seal is broken unexpectedly, replace every code.

Don't write every secret you own on the same unprotected page. A password, its TOTP seed, and the recovery codes together can become a complete account takeover kit. Some family or succession plans may need all the pieces, but then the physical protection and the person holding the package become far more serious decisions.

And check the box itself. A thin metal box isn't magically fireproof because a store put the word “safe” on it. Look at its real document rating, including time, temperature, and water protection.

Paper can burn. It can get wet, become outdated, or be photographed. This is why the envelope is a fallback, not the entire plan.

The encrypted capsule

Alex Chan wrote about keeping his recovery material in a small, encrypted disk image, with offsite backups and a paper copy planned for a fire safe. The useful part of that solution is that the encrypted container can travel while the files inside remain simple.

The container might be a protected disk image, an encrypted virtual disk, or a small VeraCrypt volume. Inside it, use files that should still open years from now: Markdown, plain text, a self-contained HTML page, perhaps the original PDF supplied by a service.

No custom app. No database that requires an abandoned framework. No personal cipher based on a poem you expect your future self to remember.

Keep the container small and copy it to more than one medium. One copy can stay on the computer, another on disconnected storage, and an encrypted copy can live outside the house. Cloud storage is acceptable for the already encrypted file, provided the passphrase doesn't depend entirely on that same cloud account.

The passphrase needs its own exit. A sealed copy at home can work. A password manager plus an independent physical record can work. Hiding four characters in a photograph from 2009 is how a practical plan turns into folklore.

An encrypted USB drive is still a USB drive. It can fail quietly, disappear in a pocket, or sit unread for years. The encryption protects the contents from whoever finds it. It doesn't make the device immortal.

The password manager problem

Keeping ordinary recovery codes in a password manager is convenient. Search works. Updates are easy. It is vastly better than forgetting them in Downloads.

The problem begins when the manager contains the only recovery route for itself, the primary email account, the phone ecosystem, and every other account capable of resetting the rest. What appears to be a collection of separate protections can collapse as one object.

Password managers with emergency features can help. Bitwarden Emergency Access lets a designated contact request access after a waiting period. The 1Password Emergency Kit contains information needed to set up the account on a new device and is meant to be stored safely.

But a feature nobody configured is decoration.

The contact has to accept. They need to understand when access is allowed, where the instructions are, and what they should never send through chat or email. The password manager itself still needs a route that doesn't depend on opening the password manager.

The setup that makes sense

For someone with personal accounts, domains, self-hosted services, and a reasonable tolerance for technical work, a layered setup is the sensible choice.

The working copy is the one available quickly. Ordinary account codes can stay in the password manager. Critical material can also live in the encrypted capsule on the computer, opened only when something needs to be read or changed.

The local physical copy is the sealed envelope in a safe or protected document box. It needs no internet connection, subscription, operating system, or healthy SSD. That's a surprisingly useful list of properties.

The offsite copy lives at another address. It may be another sealed envelope with a trusted person, or an encrypted container whose passphrase travels through a separate route. Another drawer in the same house doesn't count. Neither does a second disk permanently connected to the same machine.

Then add another authenticator where the service allows it. A spare security key is a cleaner first fallback than consuming a recovery code, but only when it was registered in advance. Yubico recommends enrolling the spare at the same time as the primary key and storing it somewhere safe and accessible.

This arrangement covers different failures without becoming a small religion. The digital copy handles routine device loss. Paper remains readable after computer trouble. The offsite copy survives the event that takes the whole house. A second authenticator may avoid the recovery process completely.

Neglect can still ruin it. An envelope full of invalid codes is a very organized way to remain locked out.

Start with the accounts that control the others

Primary email comes first. Then the password manager, phone or operating-system account, domain registrar, cloud storage, code repository, and infrastructure providers. Financial accounts follow their own official recovery rules and deserve the same attention.

These are root accounts. If one of them falls, several others may follow. Protecting a hundred minor logins while the primary email has one fragile recovery route is excellent filing and bad prioritization.

People who run servers have more roots than they think. The domain and DNS provider matter. So do the VPS panel, Tailscale or another administrative network, external backups, the source forge, transactional email, and any control panel that can reset access or destroy machines.

Don't store the only recovery vault on the server it is supposed to help recover. This sentence sounds obvious. Plenty of backup systems contain an equally obvious joke.

Recovery codes don't replace SSH key management, configuration backups, restore notes, or access procedures. Keep those systems connected in the inventory, but don't throw every secret into one convenient package.

A plain inventory is enough:

Service:
Account identifier:
Official recovery page:
Primary MFA method:
Registered alternate method:
Recovery material created:
Codes remaining:
Last checked:
Working copy:
Local physical copy:
Offsite copy:
Next review:
Notes:

The inventory can stay separate from the secrets. Its job is to tell you what exists and where, including which items were deliberately kept elsewhere.

Test while the door is still open

Don't begin with the account that controls your entire digital life.

Choose a low-risk service that provides several recovery codes. Confirm the password and another MFA method first. Open a private browser window, retrieve one code through the route you designed, use it, and mark it as consumed immediately. Then check every copy that contains the individual codes.

For a critical account, you can rehearse without entering a code. Pretend the phone and computer are gone. Can you locate the instructions? Can you obtain the container passphrase? Is the spare key actually registered? Does the official recovery page still exist?

GitHub warns that support can't restore access when two-factor credentials and every recovery method are gone. If no recovery option works, the account may be permanently lost. That's the sort of policy worth discovering during a test, with a normal session still open.

Review the system after a move, a compromised computer, a broken seal, a changed custodian, or any provider change that replaces old codes. Google and Microsoft invalidate previous sets when new ones are generated, so keeping several generations “in case” creates confusion instead of safety.

An annual check is reasonable for the whole kit. A lighter check every few months makes sense for the root accounts. Weekly maintenance would turn this into a chore, and chores have a way of being abandoned.

The first version doesn't need to be elaborate. Identify the accounts that can recover the others. Generate fresh codes through their official pages. Print and date them. Put one protected copy at home and another at a genuinely different location. Register the spare factor now, while you can still sign in normally.

Then test one unimportant account.

That's enough work for one afternoon, and the result should still make sense on the next bad Tuesday.

Sources

• Alex Chan, Where I store my multi-factor recovery codes
• NIST SP 800-63B, Authentication and Authenticator Management
• OWASP, Multifactor Authentication Cheat Sheet
• Google, Sign in with backup codes
• Microsoft, How to get a Microsoft account recovery code
• Apple, Set up a recovery key for your Apple Account
• GitHub, Recovering your account if you lose your 2FA credentials
• 1Password, Get to know your Emergency Kit
• Bitwarden, Emergency Access
• VeraCrypt, Creating new volumes
• Yubico, Spare YubiKeys