Authenticator Showing Wrong Codes? Time Sync Explained and Fixed

Time Is Literally Half of Every Code

A TOTP code is the output of a calculation with exactly two inputs: your secret key, and the current time, chopped into 30 second steps. Your app computes the code; the server computes the same code independently using its own copy of the secret and its own clock; matching outputs mean matching inputs on both sides. Since your secret never changes once it's enrolled, that leaves only one variable that can drift, and it explains why every mysterious code failure is a time disagreement until proven otherwise. (Full algorithm walkthrough: our TOTP explainer.)

Servers build in a small tolerance for this, typically accepting a window of one 30 second step on either side of the current one, roughly 60 to 90 seconds of forgiveness in total. Drift beyond that window and an honest, correctly generated code simply gets rejected, with no error message explaining why, which is exactly what makes this problem so confusing the first time someone hits it.

The Time Zone Confusion, Cleared Up Properly

Here's the part that trips up almost everyone the first time: time zones themselves genuinely don't matter to TOTP at all. The algorithm runs on Unix time, a single global count of seconds elapsed since January 1st, 1970, and that count is identical in Tokyo and in Toronto at the same instant. A phone that changes time zones correctly during a flight, its displayed clock shifts, but the underlying Unix time is untouched, generates perfectly valid codes throughout the entire trip without any special handling needed.

Time zone changes only break codes when something about the process is done wrong, and there are three specific ways that happens:

• Manual time changes after landing. You land, the phone hasn't picked up the new zone automatically yet, so out of habit you manually set the clock forward six hours to match local time. Now the phone's underlying Unix time is six hours wrong, and every single code generated from that point forward inherits the error. This is the single most common version of the traveler's mistake.
• Wrong zone combined with a wrong clock. Manually forcing the displayed time to look correct while the time zone setting underneath is still wrong can leave the actual Unix time broken even though the lock screen appears completely normal to a glance.
• Cheap or aging devices with clocks that genuinely drift and never get the chance to resync because automatic time has been switched off, whether deliberately or by an app or policy that changed the setting without you noticing.

The rule in one sentence: let the phone set its own time, always, without exception. Every manual clock adjustment, however well intentioned, is a small bet against your 2FA that you don't need to be making.

The Fixes, Broken Down Per Device

Android

1. Settings, System, Date and time.
2. Enable both Set time automatically AND Set time zone automatically, they're separate toggles and both matter.
3. If both were already switched on, toggle each off and back on anyway, this forces an immediate network resync rather than waiting for whatever the next scheduled check happens to be.

Google Authenticator layers its own additional correction on top of the system clock, entirely independent of it: open the app, tap the menu, Settings, then Time correction for codes, Sync now. Use this specifically when you can't or don't want to touch system time, corporate managed devices and deliberately manual clocks both fall into this category.

iPhone

1. Settings, General, Date and Time.
2. Enable Set Automatically, toggling it off and back on if it was already enabled forces a fresh resync.
3. If the toggle is greyed out and won't respond, a Screen Time restriction may be locking it in place, check Settings, Screen Time, Content and Privacy Restrictions for a Date and Time lock.

Windows and Mac Desktop Authenticators

• Windows: Settings, Time and language, Date and time, enable automatic, then click Sync now directly rather than waiting for the scheduled interval.
• Mac: System Settings, General, Date and Time, enable Set time and date automatically.
• Dead CMOS batteries in older desktop PCs reset the system clock at every single boot, if desktop authenticator codes break on a predictable daily cycle rather than gradually, that battery is almost certainly the actual culprit rather than anything software related.

Verify the Fix Actually Worked, in Under 30 Seconds

1. Generate a fresh test secret with our secret generator.
2. Add that secret to your authenticator app as a new entry.
3. Paste the identical secret into our browser TOTP generator in a separate tab.
4. Matching codes on both sides at the same moment means your device's clock is healthy and correctly synced. Mismatched codes mean whichever side shows the odd result out has the broken clock, and you now know exactly where to keep looking.

This simple cross check isolates a clock problem from an enrollment problem almost instantly. If the two sides match perfectly but a specific website still rejects your codes, the clock was never the issue, and our invalid code guide picks up the diagnosis from there.

Travel Proofing Your 2FA Before the Next Trip

• Confirm automatic time and automatic time zone are both switched on before you fly, not after you land and start troubleshooting.
• Remember that codes work perfectly in airplane mode, TOTP needs no signal whatsoever, only a correct clock, which makes it ideal for the moment you land and need to log into something before WiFi is even available.
• Carry backup codes for your most critical accounts, stored per our storage guide, sketchy border WiFi combined with tired manual clock fiddling at 2am is a genuinely bad combination to be stuck troubleshooting.
• A hardware security key is entirely clock independent, there's simply nothing on the device that can drift, which makes it the most travel resilient option available if a given service supports it.

Frequently Asked Questions

Why do my codes work for some sites but fail on others after traveling?

Server tolerance windows vary between services: some accept two or three steps of drift, roughly two to three minutes, while stricter ones accept only one step. A moderate amount of clock error lands you precisely in the zone where lenient servers still accept your codes and strict ones start rejecting them. Fix the underlying clock issue and every service aligns again at once, there's no need to troubleshoot each site individually.

Does daylight saving time break TOTP codes?

Not under automatic settings, DST shifts what the clock displays to you, not the underlying Unix time the algorithm actually uses. Manual clock users who "spring forward" by hand introduce a real, full 3600 second error into their device's Unix time in the process, which is another concrete argument for leaving automatic time switched on permanently.

My work phone is forced onto manual time by a device policy. What are my actual options?

Google Authenticator's internal time correction feature syncs the app itself without touching the phone's locked system settings at all, and it's specifically designed for this scenario. Alternatively, keep your authenticator app installed only on a personal device where you control the clock, or use a hardware security key on services that support it, since a hardware key has no clock to drift in the first place.

Exactly how much clock drift does it actually take to break codes?

Typically somewhere around 60 to 90 seconds, depending on the specific server's configured tolerance window. Ordinary phone clocks drift only a handful of seconds per month under normal conditions, so it genuinely takes months of automatic sync being switched off, or a single manual adjustment, to cross that threshold, which is exactly why the failure often feels sudden after codes worked reliably for a long stretch of time.

Is there any real security downside to just leaving automatic time on permanently?

For practical purposes, no. Network time sync is how essentially every device on the planet stays accurate, and TOTP's entire design assumes it's switched on. The theoretical threat model where an attacker somehow manipulates your device's clock specifically to replay old codes is genuinely exotic compared to the everyday, near certain failure mode of ordinary drift quietly breaking your logins over time.