I Thought I Lost My GitHub Account: What 2FA Recovery Taught Me

What Happened to My GitHub Account

The problem started after I signed out. My username and password still worked, but GitHub stopped the login at the two-factor authentication step. The codes shown by my authenticator app were not being accepted, and the recovery codes I expected to rely on were either missing or no longer valid.

That is an uncomfortable situation for any developer. A GitHub account can hold personal projects, client work, deployment connections, contribution history, issues, and access to organizations. Even when local clones exist, losing the identity and permissions attached to the account can still be serious.

The first important distinction is that I had lost access, not the account itself. My repositories had not been deleted. GitHub was doing exactly what two-factor authentication is designed to do: refusing entry until I could prove ownership with an accepted recovery method.

A GitHub login problem can feel like a data-loss event, but account access and repository backups are two different risks.

Preserve Every Access Path Before Troubleshooting

Before resetting an authenticator, clearing a browser, or revoking credentials, check every device and browser profile you have used with GitHub. Look at an old laptop, a work computer, another browser profile, GitHub Mobile, a password manager, and any device that may still hold a signed-in session or synced passkey.

Do not sign out of a working session while recovery is unresolved. A surviving session may let you confirm which email addresses are verified, inspect Password and authentication settings, or add and test another method if GitHub allows the required reauthentication. Sensitive changes can still trigger a new authentication check, so preserve the session even if it cannot complete every task.

Also avoid deleting the original authenticator entry, clearing app data, uninstalling GitHub Mobile, revoking an SSH key, or removing a personal access token until you know it cannot help. Destructive cleanup can remove a recovery factor that GitHub would otherwise offer.

• Check all browser profiles, not only the browser you normally open.
• Keep any signed-in GitHub tab and GitHub Mobile session active.
• Confirm access to every primary and backup email address on the account.
• Do not clear cookies, password-manager data, TOTP entries, SSH keys, or tokens yet.
• Save uncommitted work and back up important local repositories before experimenting.
• Enter passwords, codes, keys, or tokens only on GitHub's real website and recovery prompts.

Troubleshoot Your Current 2FA Method First

A rejected six-digit code does not always mean the authenticator is permanently broken. GitHub recommends confirming the correct app and account entry, correcting the device clock, waiting for a new code, and restoring a secure TOTP backup when one exists.

For an authenticator app, set the phone's date, time, and time zone to update automatically. Then wait for the next code and enter it promptly without spaces or extra characters. If the phone was reset or replaced, check the authenticator provider's official restore or sync instructions before deleting anything from the old device.

If the account uses SMS, confirm that the phone and plan can receive text messages, disable Do Not Disturb or aggressive spam filtering, move to an area with better cellular coverage, and restart the phone. GitHub also recommends checking with the carrier and reviewing GitHub Status for regional delivery incidents. GitHub Support cannot troubleshoot an individual 2FA method or SMS delivery.

• Confirm that the code comes from the correct GitHub account entry.
• Set the device's date, time, and time zone automatically.
• Wait for a fresh code and enter it before the 30-second window changes.
• Restore the authenticator only through a backup or sync method you previously configured.
• For SMS, check signal, message filtering, carrier service, and the GitHub status page.
• Try another configured method when the current one still fails.

Try Every Sign-In Method Already Configured

There is no legitimate trick that bypasses GitHub 2FA, but people often forget that they configured more than one valid method. On the sign-in screen, open More options and try only the methods that were already attached to the account.

A passkey can satisfy both the password and 2FA requirements. A synced passkey may be available through a phone, computer, or password manager, and some devices let you approve a nearby-device passkey by scanning a QR code. A registered security key can complete the second factor, while GitHub Mobile can approve the attempt through a push prompt. If the notification does not arrive, open GitHub Mobile directly and return to More options in the browser.

SMS can still work when it was configured as the account's authentication method. An older fallback phone number can also work if it remains on the account, although GitHub no longer allows people to add a new fallback SMS number. A linked social account can replace the password step, but it does not remove the 2FA requirement.

• Passkey, including a synced passkey or a passkey stored on a nearby phone.
• Physical security key registered to the account.
• GitHub Mobile approval from a device already signed in.
• TOTP authenticator code from the correct account entry or restored backup.
• SMS code when SMS was already configured.
• Legacy fallback phone number if the account still has one.
• One unused recovery code from the newest generated set.
• Linked social login for the password step only, followed by an accepted second factor.

Why a Recovery Code May Also Fail

GitHub recovery codes are one-time codes. A code that has already been used cannot be used again. An older set also stops working when a new set is generated or when two-factor authentication is disabled and enabled again.

GitHub says an individual recovery code contains ten letters and numbers separated by a hyphen. The downloaded file normally uses the name github-recovery-codes.txt. Before assuming every code is invalid, search your downloads, password manager, encrypted backups, and other devices for the newest file, then try one unused code at a time.

Recovery codes should never be pasted into a chat, ticket, email, or public screenshot. They are credentials. Anyone who has an unused code may be able to pass the second authentication step.

• Each recovery code works only once.
• Generating a new set invalidates every code in the old set.
• The default downloaded filename is github-recovery-codes.txt.
• Store the codes securely and never share them with another person.

The Official GitHub Recovery Path I Used

When neither my authenticator nor my available recovery codes worked, I used the recovery route GitHub provides from the sign-in screen. After entering the account password, open More options, choose 2FA recovery code, open More options again, and select Begin account or email recovery.

GitHub may send a one-time password to the account's primary and backup verified email addresses. Unless a specific backup address was selected previously, GitHub treats the other verified addresses as backups. Email verification begins the process, but email alone is not final proof of ownership.

GitHub then asks for a recovery verification factor it considers eligible, such as the current device if it was previously verified, an SSH key, or a personal access token. A factor may be unavailable for security reasons even if it worked with the account before, so use only the choices GitHub actually displays.

I chose the email recovery option and completed verification from a device I had already used with the account. I regained access on the same day. That was my experience, not a guaranteed turnaround. GitHub says review can take up to three business days and additional requests during that review will not make it faster. If a request is denied, GitHub's email includes a route to contact Support.

• Go to GitHub's sign-in page and enter the account password.
• Under More options, choose 2FA recovery code.
• Open More options again and choose Begin account or email recovery.
• Select I understand, get started.
• Verify an email address with the one-time password GitHub sends.
• Choose a recognized device, SSH key, or personal access token only if GitHub offers it.
• Keep checking the primary and backup email inboxes, including spam.
• Wait for the current review instead of opening duplicate recovery requests.

If You Also Forgot the Password

Losing the password does not create a separate shortcut around 2FA. Start at GitHub's password-reset page using a primary or backup verified email address. GitHub says the reset link must be opened within three hours.

During password reset, GitHub may let you use a passkey or security key, approve through GitHub Mobile, enter a TOTP or SMS code, or use a recovery code. A passkey can satisfy both the password and second-factor requirements. If none of those methods is available, choose Begin account or email recovery and complete any recognized-device, SSH-key, or personal-access-token check GitHub offers.

If a social account was linked previously, GitHub may let you use that social login instead of the password. You will still need to satisfy 2FA unless the method itself, such as a passkey, fulfills both requirements.

Why Recognized Devices, SSH Keys, and Tokens Matter

A browser or device that GitHub has seen before can become more valuable than it appears. The same is true for an SSH key or personal access token already connected to the account. GitHub can offer these as recovery verification factors when the authenticator and recovery codes are unavailable.

If you still have a working GitHub session on another browser, computer, GitHub Mobile, or development machine, do not sign out while recovery is unresolved. Do not revoke an SSH key or token simply because the website login has failed. First check whether GitHub offers that credential as part of the recovery process.

Availability is not guaranteed. GitHub notes that a factor may be unavailable for security reasons, and inactive SSH keys can eventually be removed. The lesson is to configure several recovery methods before an emergency instead of depending on one device.

What Existing Command-Line Access Can and Cannot Do

A locked browser login does not always stop Git operations that already authenticate through an SSH key, a personal access token, or Git Credential Manager. Preserve any working command-line setup. It can help you back up code and may correspond to a recovery factor GitHub offers.

Command-line access is not a bypass for the website's 2FA screen. A local clone, successful pull, repository URL, billing record, or knowledge of private repository names does not by itself restore the account. GitHub's recovery page decides whether an existing device, SSH key, or token is eligible.

Do not create a new key elsewhere and expect it to prove ownership of the locked account. Do not paste an existing private key or token into email, chat, a support ticket, or an unofficial form. If GitHub offers SSH-key or token verification, follow only the instructions inside GitHub's official recovery flow.

• Keep working SSH keys, credential-manager entries, and tokens in place.
• Back up local repositories while existing Git access still works.
• Do not expose a private SSH key, token, or recovery code to another person.
• Do not confuse access to repository files with recovery of the original account identity.

What GitHub Support Can and Cannot Do

GitHub Support cannot simply disable two-factor authentication because someone controls the email address, knows the password, pays for the account, or can describe private repositories. That limitation can feel harsh when the account is yours, but making exceptions would give attackers a way around 2FA.

If an account-recovery request is denied, use the contact route in GitHub's decision email to ask about that request. Support may explain the result or next available step, but it cannot accept recovery codes, private keys, tokens, identity documents, or account trivia as an improvised replacement for an eligible recovery method.

If every recovery method has been exhausted, GitHub says access is permanently lost. The final option is to unlink a verified email address from the locked account so it can be used with a new or existing account. Unlinking does not disable 2FA, reopen the original account, restore repository ownership, or recover organization access. Treat it as a last resort only after every real recovery path has failed.

• Email access alone cannot bypass 2FA.
• A password alone cannot bypass 2FA.
• Repository knowledge, billing receipts, and government identification are not substitute recovery factors.
• A newly created SSH key or token cannot be retroactively attached to the locked account.
• Submitting duplicate requests does not speed up an active review.
• Unlinking an email frees the address for reuse but does not recover the old account.

What I Changed Immediately After Getting Back In

The first thing I did after recovery was stay signed in and open Settings, then Password and authentication. I did not treat the successful login as the end of the incident. The goal was to make sure I would not depend on the same single failing method again.

I added a passkey, repaired the authenticator setup, generated a new set of recovery codes, and saved them securely. GitHub recommends configuring more than one authentication method and more than one recovery method. A passkey is especially useful because, for a 2FA-enabled GitHub account, it can satisfy both the password and second-factor requirements during browser sign-in.

Generating new recovery codes invalidates the old set, which removes uncertainty about which file is current. I also kept a separate backup of important repositories. A repository archive cannot restore the original GitHub identity or permissions, but it can protect the code itself if account recovery ever fails.

• Add a passkey or security key as a second sign-in method.
• Reconfigure and test the authenticator application.
• Generate a fresh set of recovery codes and clearly replace the old file.
• Keep recovery codes in a password manager and a separate secure backup.
• Confirm that the account's primary and backup email addresses are current.
• Test an additional sign-in method before closing the recovered session.
• Keep independent backups of repositories that would be costly to lose.

A Practical GitHub 2FA Recovery Checklist

Work through recovery in an order that preserves evidence and avoids destroying a method you may still need. Stop as soon as one legitimate path succeeds.

Once access returns, repair the recovery setup immediately. Do not wait for another phone replacement, browser reset, or accidental logout.

• Preserve every active browser, GitHub Mobile session, email account, authenticator entry, SSH key, and token.
• Troubleshoot the current TOTP or SMS method without deleting its existing data.
• Try a configured passkey, security key, GitHub Mobile, SMS method, legacy fallback number, or recovery code.
• Search securely for the newest github-recovery-codes.txt file and try unused codes one at a time.
• If you know the password but no 2FA method works, begin account or email recovery.
• If you forgot the password too, request a password reset first and then use the recovery options shown.
• Use a recognized device, SSH key, or personal access token only when GitHub offers it as a verification factor.
• Allow up to three business days for review and follow the decision email instead of duplicating requests.
• If every option fails permanently, consider unlinking the email only as the last resort.
• After recovery, configure at least two sign-in methods, generate fresh recovery codes, and keep an independent repository backup.

The Real Lesson Was Not to Depend on One Recovery Path

I was relieved to see the account settings page again. The repositories, history, and access I thought I might lose were still there. The failure was not GitHub deleting anything. It was my recovery plan depending too heavily on an authenticator and codes I could not reliably use.

The best time to fix that is while the account is open. Add a second method, save fresh recovery codes, keep the account email current, preserve an eligible recovery factor, and test the setup before signing out everywhere.

Two-factor authentication is still worth using. This experience did not convince me to remove it. It convinced me that strong security also needs deliberate recovery.