Where to keep your recovery codes: five plans that actually work

Picture a particularly bad Tuesday. Your phone has died, your laptop has been stolen, and the email provider you are trying to reach on a new computer wants a code from the authenticator app that was on your phone. You open your password manager, only to find that it wants the same missing second factor. The emergency codes were on the laptop. Their backup was in cloud storage accessed through that email account.

Nobody hacked you. You are still locked out.

That circular failure is what caught my attention in Alex Chan’s article about where he keeps his multi-factor recovery codes. His arrangement is intentionally straightforward: a human-readable file inside an encrypted disk image, backed up offsite, with a paper copy planned for a fire safe. The valuable lesson is not that everybody should reproduce his exact tools. It is that recovery codes deserve a small system of their own, one that remains understandable and testable after the devices you normally use are gone.

This article develops five strong ways to store recovery codes, from the simplest paper arrangement to a layered recovery plan. The final design is resilient enough for important accounts but ordinary enough that a real person can maintain it.

The central idea: a recovery code is an emergency key. It must be hidden from an intruder, yet available to you at exactly the moment when your usual devices, memory, and services have failed.

Executive summary

There is no perfect hiding place. There is a sensible combination for your risks, habits, and most important accounts.

The five approaches are:

1. A break-glass envelope in a home safe: cheap, offline, readable, and an excellent physical fallback.
2. A portable encrypted capsule: a small container that can be copied widely without exposing its contents.
3. A separate emergency vault: fast access through a password manager without making that same account the only route to its own recovery.
4. Offsite human or institutional custody: a sealed copy with a trusted person, safe-deposit box, or genuinely separate location.
5. A three-layer recovery system: one working copy, one local physical copy, and one offsite copy, supported by an inventory and periodic drills.

For most people, the fifth plan is the best answer. It combines convenience and disaster resistance without requiring exotic technology.

The most important rules are:

• never keep the only copy on the device used to sign in;
• never keep a service’s recovery key only inside that same service;
• treat recovery as an alternative form of authentication, not as a harmless note;
• record the account, date, number of codes, and usage status;
• regenerate codes after suspected exposure;
• test the route without destroying your only working access path.

Methodology and criteria

This research began with Alex Chan’s practical account and compared it with primary guidance from NIST, OWASP, Google, Microsoft, Apple, GitHub, 1Password, Bitwarden, VeraCrypt, Yubico, and the UK National Cyber Security Centre.

Each design was considered against six plausible failures:

• a lost or broken phone;
• a stolen computer;
• malware or ransomware;
• fire, flooding, or the loss of a home;
• lockout from email or cloud storage;
• the owner’s temporary incapacity or death.

I also judged confidentiality, availability, simplicity, and ease of maintenance. The goal is not the most secret arrangement imaginable. It is a plan that still works under pressure and still makes sense to you five years from now.

First, what counts as a recovery code?

Services use overlapping names for different objects, and those objects do not all deserve identical handling.

Google, for example, issues a set of single-use codes and invalidates the old set when a new one is created. Microsoft uses a 25-digit recovery code and likewise retires the previous one when you generate a replacement. Apple offers a 28-character recovery key whose loss can have much more lasting consequences.

They are not interchangeable, but they all answer the same question: what can still let me in after my normal method has failed?

The circular-dependency test

Before choosing a storage method, ask:

If I lose access to service X, can I retrieve its recovery material without using service X?

Common bad loops include:

• Google backup codes stored only in Google Drive;
• an Apple recovery key saved only in iCloud Notes;
• a password manager’s Emergency Kit stored only inside that password manager;
• an authenticator backup protected by the same email account that requires that authenticator;
• an encrypted file whose only password is stored inside the file itself.

Apple explicitly warns users not to keep their only recovery key in Apple Passwords, iCloud Drive, Photos, or Notes. Microsoft advises keeping the recovery code away from a device used to sign in. The products differ, but the design principle is universal: the emergency exit cannot sit behind the door it is meant to open.

Idea 1: the break-glass envelope

The most underestimated method is also one of the most durable: paper.

Print the codes or write them in unambiguous handwriting. Put them in an opaque envelope, seal it, and store it with important documents, ideally inside a document box with meaningful fire and water protection. Do not assume that every metal box is “fireproof.” Look for an actual document-protection rating and understand its stated time and temperature.

NIST SP 800-63B describes saved recovery codes as secrets intended to be kept offline, printed or written down, and stored securely. Google suggests printing backup codes and keeping them where you store a passport or other important papers. 1Password gives similar advice for its Emergency Kit.

Building the envelope

Put a restrained but comprehensible notice on the front:

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

Use one page per account inside. Avoid unnecessary screenshots. Plain text is easier to read, takes less space, and does not preserve distracting interface details that will age badly.

Each page should contain:

• service name;
• account identifier, such as an email address or username;
• the official recovery page;
• date the codes were generated;
• original number of codes;
• unused codes;
• primary MFA method;
• location of another copy or alternate factor;
• a short instruction for what to do after a code is used.

You do not have to store the account password beside the codes in every case. Separating the password and second factor limits the damage caused by a single theft. A family succession kit may need to assemble more information, but that makes physical control and the choice of custodian considerably more important.

The small detail that makes paper better

Use a tamper-evident envelope, sign across the seal, and date it. That will not stop a determined person from reading the contents, but it turns silent access into detectable access. If the seal is unexpectedly broken, enter through a normal method and generate new codes.

Paper still burns, gets wet, can be photographed, and becomes stale. It is an excellent fallback copy, not a complete system.

Best for: nearly everyone, particularly families and people who want an operating-system-independent recovery method.

Does not solve by itself: loss of the entire home, theft of the safe, or stale codes after a rotation.

Idea 2: a portable encrypted capsule

This is the design closest to Alex Chan’s setup: a small encrypted container that is opened only when its contents must be maintained or used.

Inside it, favor plain and durable formats:

• a Markdown or text file;
• a self-contained HTML page;
• a PDF intended for printing;
• official Emergency Kit documents;
• a dated inventory with no elaborate automation.

The outer container might be an encrypted disk image on macOS, a protected virtual disk on Windows, or a cross-platform file-hosted volume built with VeraCrypt. The exact product matters less than five properties:

1. established, strong encryption;
2. a long, unique, recoverable passphrase;
3. a format you will know how to open later;
4. verified copies on more than one medium;
5. human-readable files once the container is mounted.

Avoiding a new trap

Keep the capsule small. A few megabytes can hold thousands of codes and documents. Give the outer file a neutral name, but not one so mysterious that your future self deletes it. Mount it only to add, remove, or read material, then unmount it promptly.

Maintain at least:

• one copy on your main computer;
• one copy on normally disconnected external media;
• one encrypted copy outside your home.

Cloud storage can hold the already encrypted capsule as long as the passphrase needed to open it does not depend solely on that cloud account. Encryption reduces disclosure risk, but it does not eliminate deletion, corruption, old versions, or provider lockout.

The capsule passphrase needs its own independent route. It might be:

• memorized and also sealed in the home safe;
• held in a password manager with an independent paper copy;
• divided between something you know and a physical record, provided that the method remains obvious.

Do not invent personal cryptography. Do not hide characters in poems, coordinates, or family photographs. Clever systems are remarkably easy to forget.

Why boring internal files are a feature

The content does not need to be an app. Plain text and HTML are much more likely to remain readable over decades. Alex chose hand-written HTML; Markdown and text serve the same purpose. Encryption belongs at the container boundary. Inside, optimize for longevity and clarity.

Best for: people who already maintain backups and want speed, portability, and control.

Does not solve by itself: a forgotten capsule passphrase, malware watching while the volume is open, or simultaneous loss of every copy.

Idea 3: an emergency vault separate from everyday access

Keeping codes in a password manager is convenient, searchable, and far better than leaving them in Downloads. It becomes dangerous when that manager is the only route to recover itself, your primary email, and everything else.

The OWASP MFA Cheat Sheet emphasizes independence between authentication factors. If the password, TOTP token, recovery code, and vault key all vanish in one event, the system appeared to have several layers but actually had one failure domain.

The answer is an emergency vault with an independent path. Depending on your tools, that might mean:

• a separate vault or collection with different recovery credentials;
• an emergency account controlled by a trusted person;
• a local vault with an encrypted export and an offline key copy;
• the provider’s formal emergency-access feature.

Bitwarden Emergency Access can let a designated contact request vault access after a configurable waiting period. The 1Password Emergency Kit records the information needed to configure the account on a new device and is meant to be kept safely. These features are valuable only after preparation: the contact must accept the role, understand it, and know where the instructions live.

What belongs in the emergency vault

• recovery codes for ordinary accounts;
• official recovery URLs;
• generation and review dates;
• instructions for a family member;
• an inventory of enrolled hardware keys;
• locations of physical copies;
• a note describing which secrets deliberately are not stored there.

What should never depend on it alone

• the vault’s own Emergency Kit;
• the only copy of the master password;
• the only route into the email account that recovers the vault;
• every passkey and every factor for every critical account;
• the key for the only backup of the vault.

A practical compromise is to keep ordinary-account codes in the manager for convenience while giving the manager itself, primary email, Apple/Google/Microsoft identity, financial services, and domain registrar an additional physical or offsite copy.

Best for: everyday access, large account collections, and families already using a password manager.

Does not solve by itself: provider lockout, lost master credentials, a failed emergency-contact process, or compromise of both vault and device.

Idea 4: offsite custody with a trusted person or institution

An offsite copy protects against the single event that destroys every local copy. It might be a sealed envelope:

• in a trusted relative’s safe;
• with the executor of your will or a lawyer;
• in a safe-deposit box;
• at a truly separate office or property;
• on encrypted media held by another person.

Another drawer in the same house is not offsite. Another disk permanently connected to the same computer is not independent.

Three trust models

Complete custody: the person receives an envelope containing everything needed. This is easy to use, but the custodian could access the accounts before an emergency.

Encrypted custody: the person keeps an encrypted drive or file while its passphrase travels through a separate channel. This offers stronger privacy, but both components must remain retrievable.

Split custody: one person holds the media while another holds the passphrase or instructions. It reduces the authority of any single custodian, but raises the chances of confusion, conflict, or absence. For most families, two parts are complicated enough. Formal secret-sharing schemes are worthwhile only when everybody can operate and rehearse them.

The custodian does not need a cryptography lesson. They need a clear page that says:

1. when to open the package;
2. who may authorize access;
3. where the other component is;
4. which device can open the file;
5. whom to contact if it fails;
6. what must never be sent through chat or email.

1Password suggests giving an Emergency Kit copy to someone you trust. Apple supports account recovery contacts, who can help restore access without receiving direct access to the account. These are different models, but both acknowledge a human truth: the safest person to preserve your emergency route may not be you on the worst day of your life.

Best for: house-level disasters, families, digital estates, and succession planning.

Does not solve by itself: an unavailable custodian, changed relationships, restricted bank-box hours, or material that was never updated.

Idea 5: the three-layer system

The first four ideas become much stronger when they cooperate.

The recommended plan is:

Layer A: the working copy

This is the copy you can retrieve quickly:

• an emergency vault;
• an encrypted capsule on your computer;
• ordinary-account codes inside your password manager.

It handles a dead phone or routine device migration. It is protected but accessible.

Layer B: the local physical copy

This is the sealed envelope in a safe or document box. It requires no electricity, internet connection, operating system, or subscription. It handles computer failure, file corruption, and the day when you no longer remember how your digital routine worked.

Layer C: the offsite copy

This is a sealed envelope or encrypted container at another address. It handles fire, flood, total theft, and prolonged loss of access to your home.

A parallel path: the second authenticator

Recovery codes do not have to be your first fallback. Enroll a second hardware key or another strong factor wherever the service allows it. Yubico’s spare-key guidance recommends registering the spare when you register the primary and keeping it in a safe location. A key that was never enrolled is not a backup; it is merely an object.

The principle is vendor-neutral: register the backup authenticator with every critical service and verify that the service actually lists it as valid.

Why three layers?

This is not a cryptographic law. It is an adaptation of sound backup reasoning: different copies, different media, and at least one physical separation. The NCSC’s offline-backup guidance stresses separation and restore testing. For recovery codes, a “restore” means locating, reading, and following the emergency route before a crisis makes it necessary.

Best for: almost everyone, with lighter or stricter controls depending on account value.

Does not solve by itself: neglect. An unreviewed recovery kit slowly turns into a museum of invalid codes.

Comparing the five designs

These ratings are not absolute. A flimsy document box may be worse than a carefully protected file. An encrypted capsule with a forgotten passphrase is worth nothing. An unprepared emergency contact is not a reliable route.

The arrangement I would use

For someone with personal accounts, self-hosted servers, and moderate technical confidence, I would build this:

1. Password manager: codes for ordinary accounts, recovery URLs, and operational notes.
2. VeraCrypt or equivalent container: complete text/HTML copies, official kits, and inventory.
3. Home safe: an envelope containing root-account codes, the container passphrase, and short instructions.
4. Offsite: a current encrypted-container copy and a succession envelope.
5. Two hardware security keys: both enrolled with critical accounts, one carried and one stored.

“Root accounts” are the services capable of recovering many others:

• primary email;
• password manager;
• operating-system or mobile-ecosystem account;
• domain registrar;
• identity provider;
• cloud storage;
• code repository and infrastructure providers;
• banks and brokerages, following each institution’s official recovery process.

Start there. Protecting 150 forum codes while neglecting primary email is organization without priorities.

Organizing the material

A plain inventory prevents mistakes and does not need to include the secrets themselves. You can keep this control list separately:

Service:
Account identifier:
Official recovery page:
Primary MFA:
Enrolled alternate method:
Code generation date:
Original quantity:
Remaining quantity:
Last verified:
Location A:
Location B:
Location C:
Next review:
Notes:

Clear names beat puzzles

Avoid files named only final.txt, new-final.pdf, or personal ciphers nobody understands. Inside the encrypted volume, prefer a structure such as:

00-READ-ME-FIRST.md
01-inventory.md
root-accounts/
ordinary-accounts/
official-kits/
rotation-history.md

The outer container can have a neutral name because its metadata remains visible. Inside the encrypted boundary, clarity is a security property.

Testing without locking yourself out

A drill should increase confidence, not consume your only path back in.

The fifteen-minute test

Choose a low-risk account that issues several codes.

1. Verify that your normal password works.
2. Verify that another MFA method is available.
3. Open a private window or clean browser profile.
4. Retrieve one code through the planned route.
5. Use only that code.
6. Mark it as consumed immediately.
7. Confirm how many codes remain.
8. Update every copy that lists individual codes.

For critical accounts, rehearse without consuming a code: pretend that your phone and computer are gone, then verify that you can locate the instructions, container passphrase, and alternate method.

GitHub’s account-recovery documentation warns that support may be unable to restore access when every 2FA recovery method is gone. Test while access still exists.

Rotation and maintenance

Weekly reviews create fatigue. No reviews create archaeology. A reasonable rhythm is:

• a light check every three to six months;
• a complete annual review;
• an immediate review after a relevant event.

Regenerate codes when:

• a copy disappears;
• a seal is unexpectedly broken;
• an untrusted person may have photographed the page;
• a computer was compromised while the container was mounted;
• a custodian is no longer appropriate;
• a service changes its recovery mechanism;
• you create a new set that retires the previous one.

Update every copy in the same session. Destroy obsolete paper appropriately and record only that it was superseded. Do not retain five generations “just in case.” Providers such as Google and Microsoft invalidate older sets, so stale copies create confusion without adding access.

The mistakes people make

Taking a picture and leaving it in the camera roll

That picture may synchronize into clouds, backups, televisions, computers, and shared albums. A forgotten image can multiply without an inventory.

Emailing the codes to yourself

If email is the locked account or the recovery root for other accounts, this creates both a circular dependency and a searchable copy for anyone who compromises the mailbox.

Leaving the download where it landed

Downloads is the default destination for many services. It is also a predictable place for malware, synchronization software, and cleanup jobs to inspect.

Keeping everything only in the password manager

This is reasonable for convenience, but weak as the only strategy. The manager needs an independent exit.

Putting password, TOTP seed, and recovery code in one unprotected package

A stolen page then becomes complete access. If succession requires combining them, compensate with physical control, a detectable seal, appropriate custody, and explicit instructions.

Trusting an unencrypted USB drive

Flash drives are easy to lose and can fail silently. External media is transport, not protection. Encrypt it, duplicate it, and test it.

Making the system too clever

Secrets divided among six people, homemade ciphers, and clues based on personal memories sound impressive until someone needs the account at two in the morning. The best architecture is the simplest one that covers your actual risks.

Forgetting that a code was consumed

Mark it immediately. If synchronizing several code lists becomes unreliable, generate a fresh set and replace all copies.

Physical security without false reassurance

A safe helps, but it is not magic. Consider:

• documented fire and water performance;
• attachment or sufficient weight to resist easy removal;
• a location that is not obvious to visitors;
• authorized second-person access after incapacity;
• separation between local and offsite copies;
• a complete review after moving home.

A safe-deposit box adds geographic separation, but comes with access hours, contractual rules, and succession implications that vary by jurisdiction. It is a useful offsite copy, not the only route to an account you may need immediately.

Recovery for people who run servers

Self-hosters and administrators have additional root accounts. Include:

• domain registrar and DNS provider;
• VPS or bare-metal provider;
• Tailscale or administrative VPN;
• GitHub, GitLab, or a self-hosted forge;
• external backup provider;
• transactional email;
• encryption keys and panel MFA recovery codes;
• emergency datacenter contacts and procedures;
• location of SSH keys, without indiscriminately mixing them with recovery codes.

Recovery codes do not replace configuration backups, SSH-key management, runbooks, or restore documentation. They are one part of continuity planning.

For self-hosted systems, test infrastructure independence too. A recovery vault that exists only on the server it is supposed to help recover is another circular dependency.

Family recovery and digital legacy

A personal plan asks, “How do I get back in?” A family plan must also ask, “How does an authorized person proceed when I cannot explain it?”

Prepare one short page in ordinary language:

• which accounts are essential;
• where the material is;
• who has authority;
• which accounts should be preserved, closed, or transferred;
• which professionals should be contacted;
• where relevant legal documents are;
• what must never be published or sent through a message.

Technical access does not necessarily transfer legal ownership or authority. Wills, platform rules, and local law are separate matters. Your kit should point to the right documents and people, not attempt to replace them.

Practical recommendations

If you have thirty minutes

1. List your five root accounts.
2. Generate or refresh their official recovery codes.
3. Print two copies.
4. Seal one and place it with your protected documents.
5. Put the second at a different address with someone you trust.
6. Enroll a backup MFA method.
7. Schedule a review six months from now.

If you have an afternoon

1. Complete the thirty-minute plan.
2. Build the encrypted container.
3. Organize the inventory and official kits.
4. Copy the container to disconnected media and an offsite location.
5. Test one low-risk account.
6. Write a one-page “READ ME FIRST.”
7. Explain the arrangement to your emergency contact.

Final checklist

• I have identified my root accounts.
• Critical accounts have more than one access method.
• Codes are labeled and dated.
• At least one copy is offline.
• At least one copy is outside my home.
• A service’s only recovery key is not trapped inside that service.
• The encrypted-container passphrase has an independent route.
• My emergency contact accepted and understood the role.
• I know which codes are single-use.
• I know how to revoke and regenerate them.
• I have tested a low-risk recovery.
• The next review is scheduled.

Conclusion

Storing recovery codes is a small exercise in personal continuity planning. The goal is not to hide a page as though it were buried treasure. It is to preserve a route back when the objects and services you ordinarily depend on are unavailable.

The physical envelope is the best beginning. The encrypted capsule is the strongest digital tool. The emergency vault brings convenience. Offsite custody handles disasters. The three-layer system combines those strengths and is the best general recommendation.

The best plan is not the most paranoid. It is the plan that:

• avoids circular dependencies;
• survives more than one kind of failure;
• is simple enough to maintain;
• can be explained to another person;
• has been tested before the emergency.

If you do only one thing today, print the recovery codes for your root accounts, date the page, and put it in a protected physical location. Then create the second location. Those two modest steps already eliminate an enormous class of digital lockouts.

Sources consulted

• Alex Chan — Where I store my multi-factor recovery codes
• NIST SP 800-63B — Authentication and Authenticator Management
• OWASP — Multifactor Authentication Cheat Sheet
• OWASP — Authentication Cheat Sheet
• OWASP — Forgot Password Cheat Sheet
• Google — Sign in with backup codes
• Google — Fix common issues with two-step verification
• Microsoft — How to get a Microsoft account recovery code
• Apple — How to generate a recovery key
• Apple — Set up an account recovery contact
• 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
• NCSC — Offline backups in an online world

Note on currency

Research completed on 24 July 2026. Recovery flows, password-manager features, and support policies change frequently. Confirm procedures on official pages before relying on them, and never test a critical account without another valid access method.