A note from the workshop
Somewhere safe is not a filing system.
Knowing that backup codes exist is different from being able to find a usable one. Today’s check is about location and dependencies. Keep the codes private, keep a working session open, and avoid replacing a valid set just because you are conducting an inventory.
Three useful checks
- Find the supported method: Read your service’s backup-code instructions and exceptions.
- Check the private location: Can you reach the protected copy without the device you might lose?
- Record only a reference: Write a location label, never the actual code, in your planning notes.
Put it into practice
Choose one important personal account and open its settings directly. Google’s documentation says its backup codes are single-use and that creating a new set invalidates the previous one. Other providers have different recovery models. Record the rule for your actual service.
A code saved in a locked phone may not help when that phone is unavailable. A code stored with its own inaccessible decryption key can create the same circle. Review the route to the protected copy without exposing it on a shared screen or moving it into an unprotected note.
If you deliberately test a single-use code, mark it consumed and keep track of which copy is current. Stop rather than signing out everywhere. When a new set is truly needed, follow the service’s process and retire the superseded copies deliberately. Never send a code to someone claiming to be support.
The location must survive the problem it solves
A recovery code stored only inside the account it helps unlock can create a circular dependency. A code on a missing phone is not reachable merely because you remember saving it. Before choosing a location, name the scenario: lost phone, unavailable authenticator, damaged laptop, or another specific problem. Then ask whether the proposed storage remains reachable in that scenario.
Google’s backup-code instructions describe single-use codes, invalidation of the previous set when a new set is created, and account-program limitations. Do not transfer those details blindly to every provider. Your record should say which service’s rules you checked, while the secret itself stays in the protected location you selected.
Create a location inventory without creating a secret inventory
Use a private label such as primary-email and a reference such as sealed envelope in the chosen secure storage. On the ordinary worksheet, record only the location reference, provider instructions, and date reviewed. Do not copy a code into a browser note, a support chat, or a screenshot for this exercise.
An invented example: the code is kept in a locked location at home, but the only way to open that location is an app on the missing phone. That arrangement may be secure against casual access while failing the availability scenario you chose. Change the dependency plan before you need it, without publishing the details of the storage.
- Open the account’s own recovery documentation and note eligibility and code-use rules.
- Check whether a current code set exists without unnecessarily regenerating it.
- Choose protected storage that remains accessible in the loss scenario you are planning for.
- Record a location reference separately from the code itself.
- If you deliberately replace codes, reconcile obsolete copies according to the provider’s rules.
Avoid “testing” away your only route
Do not invalidate a working code set simply to make a worksheet look current. Do not sign out of every device or remove other methods to prove that recovery will be exciting. A location review can be completed without consuming a code. If you decide to rehearse actual use, first read the provider’s instructions and retain your working access.
Treat an old printed set and a new downloaded set as a version-control problem. If the provider invalidates previous codes, keeping an unlabeled obsolete copy creates a misleading emergency option. Make the record clear enough that you can identify which material is current without exposing its contents.
The output is a reachable, current reference
You should finish knowing which recovery mechanism the service supports, where the current material is kept, and whether you can reach it without the missing device. Note any unresolved dependency instead of writing ready. Review after replacing authentication methods or regenerating recovery material. A well-filed secret is useful; a secret whose only address is somewhere safe is a future search party.
Know the limits
A location inventory is not an account-recovery guarantee. Managed accounts and special protection programs may not support the same backup-code route.
Confirm one protected, reachable code location without putting the secret on the worksheet.
Print the private field sheet. Record actions and observations, not passwords, recovery codes, or private documents.
Keep exploring: the offline AI experiment, lost-phone recovery, or the Recovery Drill.
About this field note
Original CRYPT1K editorial guidance. Sources reviewed October 21, 2026. Procedures are reader exercises; no unperformed hardware, account, or AI test results are claimed. Character and artwork are fictional and AI-assisted.