Two-factor authentication recovery codes are the part of account security that only matters when the normal second step stops working. If your phone is lost, an authenticator app is wiped or a security key is unavailable, a previously generated recovery code may provide a route back into the account.
The crucial word is previously. These codes must be created while you can still sign in. They are not the six-digit numbers that refresh inside an authenticator app, and there is no universal code that works across services. Each account issues its own recovery material under its own rules.
Recovery codes are a spare route, not a spare password
A normal two-factor sign-in combines a password with a second method, such as an authenticator app, passkey or hardware security key. A recovery code is an alternate proof that the service has already associated with your account.
That makes it powerful. Someone who has both your password and an unused recovery code may be able to pass the two-factor check. Treat the code as a credential, not as a reminder or a harmless note.
Services use different names and designs. Google calls its set backup codes. GitHub uses recovery codes. Microsoft offers a single account recovery code that can help with a broader password-reset flow. The labels sound similar, but the quantities, formats and recovery steps are not interchangeable.
What Google, GitHub and Microsoft actually issue
Google provides a set of 10 backup codes when 2-Step Verification is enabled. Each code has eight digits and becomes inactive after it is used. Creating a fresh set automatically inactivates the old one. Google lets a user download or print the codes, and it advises keeping them somewhere safe. Accounts enrolled in Google’s Advanced Protection Program cannot download backup codes.
GitHub issues 16 one-time recovery codes. A used code cannot be used again, and generating a replacement set invalidates every code from the previous set. GitHub recommends storing the file securely and specifically suggests a secure password manager. It also recommends configuring two or more authentication methods, so the recovery-code file is not the account’s only spare route.
Microsoft’s consumer-account recovery code works differently. It is one 25-digit code that can be used during account recovery if the password is forgotten or the account is compromised. Microsoft says an existing code cannot be retrieved or downloaded later. Generating a new one immediately invalidates the previous code. Its official guidance says to print the code and keep it away from the device normally used to sign in.
| Service | Recovery material | What makes the old material stop working |
|---|---|---|
| Google Account | Ten eight-digit backup codes | Each code expires after use; a new set invalidates the old set |
| GitHub | Sixteen one-time recovery codes | Each code expires after use; a new set invalidates the old set |
| Microsoft Account | One 25-digit recovery code | Generating a new code invalidates the previous code |
The table is a snapshot of the official documentation checked on November 1, 2026. Always follow the current recovery page for the specific account.
Create the codes before changing devices
Generate recovery codes before replacing a phone, resetting an authenticator app or removing an old security key. Start in the account’s official security settings rather than following a link from an email or message.
A sensible order is:
- Sign in through the service’s normal website or app.
- Open its security or two-factor authentication settings.
- Generate or view the recovery codes.
- Save the new set using a storage method you can reach without the device you are about to replace.
- Confirm that another sign-in method is also registered when the service supports one.
- Only then remove the old authenticator, phone or security key.
If the immediate task is moving a time-based authenticator, follow the service-specific migration steps in our authenticator transfer guide. Recovery codes sit beside that migration plan; they do not copy the authenticator secrets to the new phone.
Store them outside the failure you are planning for
The right storage choice depends on what could lock you out.
A reputable password manager can encrypt the codes, make them searchable and keep a record available across devices. GitHub explicitly recommends this route. It works best when you can still unlock the password manager without the account or phone being recovered.
A printed copy avoids dependence on a phone, cloud sync or a particular app. Microsoft explicitly recommends printing its recovery code and keeping it away from the everyday sign-in device. Paper needs a physically secure location and a replacement plan if it is damaged, moved or exposed.
Some people use both: an encrypted digital copy for normal access and a sealed paper copy in a separate secure location. The key is separation. A recovery code stored only in the locked account’s own drive, only on the lost phone or only inside a password manager that needs the same unavailable second factor does not solve the failure.
Do not email the codes to yourself or paste them into a shared notes document. Do not send one to anyone who claims to be support. Google states that it asks for a backup code only at sign-in.
Know which version is current
Regeneration is useful after a code file is lost or exposed, but it creates a bookkeeping problem: the old copy stops working.
Write down the service name and generation date beside a printed set. For an encrypted file, use a clear filename and remove superseded copies after a new set has been saved. Do not copy a replacement set over an old file until you have confirmed the new file opened correctly.
Mark a one-time code as used immediately after a successful recovery. Google recommends doing this because its codes cannot be reused. GitHub also makes each code single-use. If you are unsure which codes remain valid, generate a new set while signed in and replace every stored copy.
A recovery check that does not create another lockout
You can review the recovery setup without deliberately locking yourself out.
- Confirm that the account security page shows recovery codes as configured.
- Confirm that the stored copy is readable from the place where you expect to need it.
- Check that you know which username or email address the codes belong to.
- Verify that at least one other authentication method is current.
- Read the service’s lost-device flow before removing any old method.
Using a one-time code merely as a test consumes it. If you choose to test one, expect to mark it used and confirm that enough unused codes remain. Never test by deleting the working authenticator first.
For accounts that support hardware security keys, a second key stored separately can reduce dependence on recovery codes. Our security-key explainer covers how those keys resist phishing and why a backup key should be enrolled before the primary one is lost.
What to do after a code is used or exposed
After using a recovery code, sign in to the account’s security settings and inspect the registered devices and authentication methods. Remove anything you no longer control. Generate replacement recovery material if the service does not do so automatically, then update every stored copy.
If a code file may have been copied by someone else, do not wait for a login alert. Sign in through a trusted route, generate a new set so the old codes become inactive, change the password when compromise is possible and review recent account activity.
Recovery codes are deliberately low-tech. Their value comes from being created early, stored apart from the device they protect and replaced whenever their secrecy or validity becomes uncertain.
Documentation checked: November 1, 2026.
