2FA codes not working: a field guide to diagnosis and fixes

The password is right — it worked yesterday, and the browser even autofilled it. The six-digit code is right too. You are looking straight at it: bold digits, a progress ring draining clockwise, and the login page's verdict is Invalid code. You wait for the next one. Invalid code. The ring restarts. Somewhere between your phone and the server, a fact the two were supposed to agree on has quietly come apart.

Take a breath. The failure is almost always one of five things, and four of them you can fix in under five minutes. Start with the table, then read the section that matches your symptom.

What you are seeing	Most likely cause	The fix that usually works
Every code rejected, on every account	Clock drift	Turn on automatic date and time
One account fails, the others work	Wrong entry, or a rotated secret	Check the label, then re-enroll
Codes died after moving phones	The secret rotated or never transferred	Re-enroll from the service's side
The SMS never arrives at all	Dead zone, ported number, carrier filtering	Switch the account to an authenticator app
The push notification never arrives	No data connection, or the app is asleep	Get on Wi-Fi, open the app, retry

Cause one: your clock, not your code

When every code fails on every account, the phone's clock is the suspect. TOTP is arithmetic over time — the code is derived from how many 30-second steps have passed since the Unix epoch, per RFC 6238 — and what TOTP is in one line: your device and the server must independently compute the same number, which they can only do if they agree on what time it is. Validators typically forgive about one step of drift, roughly a minute. Beyond that, every code your app shows belongs to a time step the server has already left, and the rejection is instant and confident.

The classic patient is a phone that has been offline or lightly used for months with automatic time off. Clocks drift — a few seconds a week is normal for a device that is not syncing — and a phone that sat in a drawer can be minutes off while looking perfectly healthy on the lockscreen.

The fix is to let the phone take its time from the network:

• iPhone: Settings → General → Date & Time → turn on Set Automatically. Apple documents this in the iPhone User Guide.
• Stock Android: Settings → System → Date & time → Automatic date and time on. Google's Android help page covers the variations, including setting it from the Clock app.
• Samsung Galaxy: Settings → General management → Date and time → Automatic date and time on, per Samsung's own steps.

Leave the time zone automatic as well, since a wrong zone can still confuse services that compare locations. Two app-specific notes. Google Authenticator used to have its own fix — Settings, Time correction for codes, Sync now — but that setting was removed in version 7.0, and the app now uses the operating system's time, so the OS toggle is the whole fix on a current install. Microsoft's guidance for its Authenticator is the same idea in different words: the device clock must accurately report local time, set it to automatic, then restart the device — see Microsoft's troubleshooting page.

One more clock-adjacent annoyance that is not drift: a code rejected one second after it appeared. That is the step boundary — a code generated at the tail end of a step arriving after the server has rolled to the next — and RFC 6238's one-step delay tolerance exists for exactly this case. How time and counters move differently is covered in HOTP vs TOTP. If the failure repeats on a fresh code, it is drift.

Cause two: the wrong account

Open the failing app and count the entries. If there are two named Google, or an Amazon sitting next to an Amazon Web Services, or a bank's old entry beside its replacement, you may be typing a code that is perfectly valid — for a different secret. This is the most common failure on multi-account phones: identical labels, the eye landing on the neighbor, and a code that is wrong in a way no amount of retyping fixes.

The test is isolation. Expand the entry's details — issuer and account name are shown there in every competent authenticator — and confirm they match the service you are logging into, at the exact domain you are on. A phishing page that looks like your bank produces the same symptom, which is why you check the address bar before typing a code anywhere.

The fix is housekeeping. Name entries properly at enrollment: service, account, and a note when you hold both a work and a personal login. Delete dead entries only after the replacement is confirmed working. Keep the list short enough to scan without scrolling, because every duplicate label is a future wrong-code incident waiting for a stressful morning.

Cause three: a rotated secret

Sometimes the app is right and the server changed. Services rotate the shared secret — the base32 string behind the QR code — after security incidents, administrator resets, or your own re-enrollment. Deleting 2FA and setting it back up issues a brand-new secret, and the old entry in your app keeps generating codes that match nothing on the server's side. Both ends look healthy. Neither is lying. They simply no longer share a secret.

The signature is an entry that worked for months and then fails permanently on one account while other entries stay fine — and usually you can trace it to an event. The service emailed about a security update. You moved phones and re-enrolled from scratch instead of using a transfer flow, which is exactly what transferring Google Authenticator properly avoids. An administrator reset everyone's second factors after an incident.

Re-enrollment is the fix, and it needs one working way in: recovery codes, a still-signed-in device, or the service's grace period. Disable 2FA, enable it again, scan the new QR code, confirm a code, then delete the old entry. This is also the moment to date any paper backups — a printed secret from before the rotation is quietly, permanently wrong.

Cause four: push and SMS have opinions about networks

Authenticator-app codes work offline because they are computed locally — the full story is in using TOTP offline. Push and SMS do not have that property, and their failures look like silence rather than rejection.

Push notifications need a data connection and a cooperating app. A phone in a basement, on a congested network, or with the authenticator put to sleep by aggressive battery optimization will simply never show the prompt. The fix is mechanical: get on Wi-Fi, open the app manually — which often flushes the pending prompt — and retry the login from the top. If push fails repeatedly on one service, switch that account to TOTP codes, which need no network at all to generate.

SMS has more failure modes than any other channel, and they stack. Dead zones. Ported numbers: when you move your number to a new carrier, SMS routing can lag for days. Recycled numbers: if your number previously belonged to someone else, their codes still arrive on your phone. And carriers quietly filter messages from short-code senders as spam, which eats login texts without telling either side. The FCC now requires carriers to take steps against SIM-swap and port-out fraud — see fcc.gov — but the honest reading stands: if your second factor travels by SMS, your logins depend on a telephone network's worst day. Move accounts to an authenticator app wherever the service offers one.

Cause five: fully locked out

No working codes, no recovery codes, no second device. The timeline now changes from minutes to days, and expectations should change with it.

The designed escape hatch is the set of recovery codes the service showed you at enrollment — one-use codes that work with just your password. If you printed or saved them, this is the moment they earn their ink: sign in with password plus a recovery code, then re-enroll a fresh authenticator and regenerate the codes, since some may be burned. If the service rejects a recovery code, check you are not reusing one you already spent.

If the codes are gone too, you are in the service's account-recovery process, and it deserves honest expectations. Identity checks: when the account was created, what it was used for, familiar devices and locations. Waiting periods measured in days between attempts, and repetition if the first try fails. No guarantee at the end — Google describes what helps in its tips for completing account recovery steps, and the honest summary is that success depends on how much history you can prove. For services that are end-to-end encrypted by design — password managers, encrypted mail — a lost second factor with lost recovery codes can mean the account is simply gone, because no one, including the provider, holds the keys to let you back in. That is a feature until it is your account.

Prevention, or the boring five minutes that saves the weekend

Every fix above is cheaper before it is needed, and the prevention list is short:

• Export at enrollment. When a service shows the QR code, save the image or the otpauth:// link and store it somewhere encrypted — not in a photo gallery that syncs to the cloud, not in a chat sent to yourself.
• Keep the secret on two devices. A zero-knowledge vault gives you this without buying a second phone: 2FA by DependsiT encrypts entries on your device before upload — PBKDF2 salted derivation, HKDF key separation, AES-256-GCM — so the server holds only ciphertext, and the vault decrypts on any new device with your password, because the keys never lived on the old phone. It installs as a PWA and works fully offline after first load.
• Print the recovery codes. On paper, with a date, in a place you can find when your phone is at the bottom of a lake.

None of this is complicated, which is precisely why it gets skipped. The lockout stories that end badly almost always involve a secret that lived on exactly one device and recovery codes that were never saved.

Frequently asked questions

Why is my authenticator app showing the wrong codes?

Nine times out of ten, clock drift. TOTP codes are derived from the number of 30-second steps since the Unix epoch, so a device whose clock is off by more than about a minute generates codes for time steps the server has already left behind. The app looks perfectly healthy while producing confidently wrong numbers. Turn on automatic date and time in the operating system settings, let the clock resync, and the next code works. If one account fails while the rest are fine, the problem is that entry — a rotated secret or a wrong label, not the clock.

How do I sync Google Authenticator's time?

You no longer do it inside the app. The in-app time-correction setting was removed in Google Authenticator version 7.0, and the app now takes its time from the operating system, per Google's help page. On iOS, that means Settings, General, Date & Time, Set Automatically on. On Android, Settings, System, Date & time, Automatic date and time on — Samsung hides it under General management. Restart the app after changing it. Microsoft Authenticator has the same requirement stated its own way: the device clock must be automatic and accurate, followed by a device restart.

Why did my codes stop working after changing phones?

Usually the secret did not survive the move. If the new phone was set up by deleting the old entry before confirming the new one, or by re-enrolling instead of transferring, the service may now expect a different secret than the one your app holds — and the old entry generates codes that match nothing. Recovery codes get you back in to re-enroll. When moving authenticators, use the service's transfer or export flow rather than starting fresh, and keep the old phone around until you have confirmed the new one generates working codes.

Can a service recover my account without 2FA?

Sometimes, slowly, and without a guarantee. Most services run an account-recovery process: identity questions, account-creation details, familiar devices and locations, and waiting periods that can run for days between attempts. Google publishes tips for completing its recovery steps, and the honest summary is that success depends on how much history you can prove. For end-to-end encrypted services, a lost second factor and lost recovery codes can mean the account is unrecoverable by design — no one holds the keys to let you back in, which is the same property that keeps everyone else out.

Should I keep a second copy of my TOTP secrets?

Yes — the single biggest lockout risk is a secret that lives on exactly one device. Export the QR image or otpauth link at enrollment and store it somewhere encrypted, and print the recovery codes the service shows you, with a date. A zero-knowledge vault adds a device-independent copy: entries are encrypted on your device before upload and decrypt with your password on any new device, so a dead phone is a nuisance rather than an account funeral. Paper remains the final fallback that never needs a battery, an operating system, or a vendor.

The fastest diagnostic in this whole guide costs nothing: open the guest generator on another device, paste the secret for the failing account, and compare codes. A mismatch means your phone's clock is lying. A match the service still rejects means the secret rotated. Two minutes, no account, nothing stored.