Recovery codes: how to store and use them safely

Recovery codes are account keys

A valid recovery code can bypass the normal second factor. Treat it with the same care as a password or physical key. Do not paste it into chat, email it to yourself in plain text, or read it to a caller. A legitimate support agent should not need an unused recovery code.

Codes are often single-use, and generating a new set may invalidate the old set. Record the date and account when storing them, but do not add extra public labels that make a stolen copy easier to exploit.

Where to keep recovery codes

A printed copy in a secure physical location can be a strong offline backup. An encrypted password manager can also work if you can access it without depending on the same locked account. Some people use both: one protected digital copy and one separately stored physical copy.

Avoid keeping the only copy on the phone that generates the normal codes. Avoid saving the only copy inside the email or cloud drive protected by the same 2FA. The recovery route should fail independently from the primary route.

When to use one

Use a recovery code only on the service's verified official sign-in page and only when you intentionally selected a recovery or alternate-factor option. Confirm the entire domain before entering it. If a message provides a special recovery link, navigate to the service independently instead.

After a successful recovery, inspect the account. Add a replacement authenticator, remove missing devices, review recent sessions, and generate a new code set if the service does not replace the used code automatically.

When to rotate the set

Generate a new set if the stored copy may have been seen, a shared household or workplace arrangement changes, or the service indicates that old codes were not invalidated automatically. Replace stored copies and destroy outdated paper versions.

Do not rotate merely on a calendar if the process itself creates risky handling. The important events are exposure, account recovery, staff or device changes, and service guidance.

Recovery scams and unofficial help

Scammers claim they need a backup code to verify ownership, stop an attack, release a purchase, or restore a social profile. Providing the code usually completes their sign-in. End the conversation and use the official help center from a known domain.

Avoid people who promise to recover an account for a fee, especially if they request codes, remote access, cryptocurrency, or screenshots of security settings. login.com does not recover accounts; it only points to official service resources.

Practical checklist

How to put this into practice

1. Generate codes from the service's verified security settings.
2. Label the account and generation date without exposing extra public details.
3. Store a protected copy away from the normal authenticator.
4. Test that you can locate the codes without using the protected account.
5. Use a code only on the verified service domain.
6. After recovery, replace the authenticator and refresh the code set.

At a glance

Compare the options

Decision guidance

Choosing the right approach

Recovery codes belong in an emergency plan, not in the everyday sign-in routine. Store them where they remain reachable if the normal phone, laptop, mailbox, or password manager account is unavailable. A printed copy in a secure location can provide useful separation; an encrypted digital copy can be appropriate when its unlock path is independent.

Know whether the service issues a set of single-use codes or one rotating recovery code. Cross out a printed code after use and save the replacement set immediately when the service regenerates it. Regeneration usually invalidates the old set, so do not assume an earlier backup still works.

A recovery code can bypass a stronger daily factor and should be treated like a high-impact secret. Support should not ask you to read it aloud or send a screenshot. Enter it only on the verified service domain after you deliberately started recovery, then review sessions and replace the code.

Operational test

Rehearse the moments when security usually fails

Start with an ordinary device change. Imagine the phone or computer used for this control is unavailable today, not after a carefully planned migration. Identify which trusted device, independent authenticator, recovery code, provider account, or administrator would restore access. Then verify that route without deleting the working method. For Recovery codes: how to store and use them safely, the practical starting action remains: Generate codes from the service's verified security settings. A recovery plan is only useful when the contact information is current and the required material can be reached without first unlocking the same account.

Next rehearse a suspected compromise. Do not answer the suspicious message or use its link to investigate. Open the known service independently, review recent sessions and security changes, and preserve evidence before removing anything. Rotate a reused password, revoke unfamiliar applications, and replace any exposed backup secret. If a second factor produced an unexpected prompt, deny it and assume the primary password may already be known. A strong authenticator helps prevent entry, but it does not clean up a stolen browser session, changed recovery address, malicious forwarding rule, or newly authorized application.

Finally, test the managed-account case. Workplaces, schools, families, and enterprise plans can place sign-in policy with an administrator or external identity provider instead of the service itself. Learn who can reset the control, what proof that person requires, and how an urgent request is authenticated. Never weaken the whole organization to solve one member's lockout. Record the official help route and an internal contact before a problem occurs, and separate administrative recovery from unsolicited support messages. This turns the comparison above—from Printed copy onward—into a maintainable choice rather than a one-time setup.

Apply the idea

Representative service guides

• GitHub
• Gmail
• Discord
• Cloudflare
• Dropbox
• Bitwarden

Primary guidance

Sources and further reading

• CISA - More than a Password
• NIST SP 800-63B-4 - Authenticators
• FIDO Alliance - Passkeys

Product interfaces and available methods change. Re-check each service's official help before changing a security setting, and prepare recovery before removing an older authenticator.