Recovery codes deserve a different storage decision from an ordinary note. They may let someone enter an account when the usual second factor is unavailable. A code can therefore be both a rescue route and a secret worth stealing. The useful question is not simply where to save the file. It is whether an authorized person could reach the current codes after losing the device or account that normally holds them, without making those codes available to everyone else.
Identify what the codes actually recover
Read the provider's instructions before making a storage plan. Recovery mechanisms are not interchangeable. A service may offer one-time backup codes for the second authentication step, a recovery key with different consequences, an account recovery process, or several alternatives. Record which account and mechanism you are dealing with. Do not assume a code also replaces a forgotten password unless the provider explicitly documents that route.
Google describes its backup codes as an alternative second step and says each used code becomes inactive. GitHub similarly documents single-use recovery codes and recommends configuring additional authentication methods. These examples establish why a recovery file should be managed as an account-specific credential. They do not establish that every provider offers the same format, number of codes or eligibility. Use the current help page for the actual account instead of copying instructions from a different service.
Look for a circular dependency
Draw a small dependency map with the account in the center. Add your phone, authenticator, password manager, recovery email and each proposed code location. Then imagine losing the phone. Which arrows still work? Repeat the exercise for losing access to the main email account or the password manager. You are looking for a route that depends on the very thing it is supposed to recover.
For example, a code stored only in a cloud drive behind the locked account offers little help with that account's lockout. A screenshot on the lost phone has the same problem. This does not mean cloud storage or password managers are inherently unsuitable. It means the storage choice must be evaluated alongside its own authentication and recovery requirements. Record those dependencies without writing the actual secrets on an ordinary diagram that might later be shared with a colleague.
Separate everyday access from the emergency copy
A protected password-manager entry can make codes easy to find, while an independently protected offline copy can address a different failure. The offline location must suit the household or organization: a secured document store, for instance, is different from a loose sheet on a desk. Consider fire, theft, unauthorized visitors and whether the intended person can actually retrieve it when needed.
Label the record with the service, an account identifier sufficient to distinguish it, and the date the set was created. Avoid including unnecessary personal data. If a printed copy is appropriate, make sure the printing and handling arrangements do not leave a shared-printer copy or an exposed scan. Two copies synchronized through the same account can still share one point of failure.
Replace a set as a controlled change
Google and GitHub both document that generating a fresh set invalidates the previous set. A replacement is therefore not just another download. Save the new set in the intended protected locations, update its date, and remove or clearly retire obsolete copies. Otherwise an emergency search may find a plausible-looking file that can no longer work.
Keep your ordinary authenticated session and another verified sign-in method available while following the provider's supported process. Do not deliberately disable working factors to make a recovery exercise more dramatic. If you suspect the previous codes were exposed, use the provider's documented replacement and account-security controls promptly. Do not paste old or new codes into a support chat to ask whether they remain valid. A support message is another copy, and a person requesting the codes may not be entitled to them.
Rehearse discovery without staging a lockout
An initial rehearsal can be a retrieval exercise: from a second trusted device, locate the official sign-in instructions and confirm that you can reach the protected record without the missing device. Verify account labels and the creation date. This checks availability, not whether an unused secret will be accepted by the service. Be explicit about that limitation in your notes.
If a provider supports and you choose an actual recovery-code sign-in test, follow its instructions while retaining another working method. A successful single-use test consumes the code; mark it as used in every relevant record. Do not circulate the result with the code visible. The useful evidence is that the documented route worked for a named account at a recorded time. It is not a promise that future account-risk checks or a changed provider policy cannot affect access.
Keep recovery authority narrower than convenience
Giving someone a recovery code may grant more access than helping with one subscription or finding one document. Use the service's delegation or family-sharing features where those fit the task. Do not treat an emergency contact, estate arrangement or workplace administrator as permission to browse another person's account.
Review this arrangement after replacing a phone, changing the password manager or updating the account's recovery settings. Destroy exposed or superseded copies through an appropriate method. A dependable recovery record consists of the current secret, a genuinely reachable protected location, and accurate instructions for its limited use.
REFERENCES
Sources and further reading
Sources reviewed October 20, 2026. Provider instructions and product terms can change. Examples identified as fictional are editorial illustrations, not reported events or product tests.