Every Authenticator Code Rejected After a Device Clock Drifts a Few Minutes

When an authenticator app produces a six-digit code and the site rejects it every time — three codes in a row, each typed within two seconds, same result — the password is almost never the problem. The usual cause is that the clock on the device generating the code has drifted away from the clock on the server checking it. A time-based one-time password is computed from the current time, so if the two clocks disagree by more than the verifier tolerates, the code is arithmetically correct and still refused.

Stop entering codes and measure the offset first. Open time.gov in a browser on the device that runs the authenticator app. Operated by the NIST Time and Frequency Division and the United States Naval Observatory, it shows a line reading "Your clock is off by: ___ s", noting that "Clocks are corrected for network delay." Read that number against the two tolerances quoted below — about 89 seconds in RFC 6238's worked example, and plus or minus one minute in Microsoft Entra ID. Under a second is far inside both, so the clock is not the cause. About a minute or more reaches the tighter of those two, so repair the clock first. In between settles nothing on its own: restore synchronisation anyway, but keep working the other checks. The repair is not to type the time in by hand.

Restore automatic time, using the documented path for the platform

Setting the clock by hand to match a website is the wrong repair even when it appears to work: a hand-set clock starts drifting again immediately. Turn the automatic setting back on so the device keeps correcting itself.

iPhone and iPad

Apple's support article on changing time and time zone gives the path as: "Open Settings. Tap General, tap Date & Time, then turn on Set Time Automatically." Time zone is handled separately, on a different screen: "Open Settings. Tap Privacy & Security, tap Location Services, scroll to the bottom and tap System Services, then turn on Setting Time Zone."

Android

Google's help article for setting time, date and time zone routes through the Clock app rather than system settings: open Clock, then More, then Settings, then Change date and time, and turn on Automatic date and time. A separate toggle there is Automatic time zone. Two limits from that article: "only some devices let you automatically set the time zone", and "some devices only support using location to set the time zone, like Wifi-only tablets."

The location of these controls inside the Settings app is not standardised across manufacturers, and Google's article names no minimum Android version. Samsung documents the Galaxy path as Settings > General management > Date and time, with the same two toggle names.

Windows

Microsoft's how-to article gives the path as Start > Settings > Time & language > Date & time, with the toggles Set time automatically and Set time zone automatically. One detail from that article prevents a common mistake: Adjust for daylight saving time automatically is only available when Set time zone automatically is turned off.

Windows keeps time through the Windows Time service, which Microsoft describes as using the NTP algorithms; machines not joined to a domain "are configured, by default, to synchronize with time.windows.com". The W32Time settings reference gives the NTP Client default SpecialPollInterval as 1024, so the client is not asking continuously — part of why a Windows clock can sit visibly wrong for a long stretch.

To force a correction rather than wait for the next poll, run Command Prompt as administrator and use w32tm /resync. Microsoft documents it as: "Tells a computer that it should resynchronize its clock as soon as possible, throwing out all accumulated error statistics. The NTP client requires UDP 123 as the source port." That last sentence explains why the command fails on some networks — a guest Wi-Fi or firewall blocking outbound UDP 123 leaves the clock unsynchronised. To read the current state, w32tm /query /status /verbose prints Last Successful Sync Time, Source, Poll Interval and Phase Offset. Microsoft's how-to article for the Date & time screen documents no control for forcing an immediate synchronisation, so none is claimed here.

Mac

Apple's macOS user guide, current through macOS Tahoe 26, gives the steps as: open System Settings, "Click General in the sidebar, then click Date & Time on the right", "Turn on 'Set time and date automatically,' then click Set", "Enter a network time server for your region, then click Done", and "Turn on 'Set time zone automatically using your current location.'" The guide names no specific server, so no hostname is asserted here.

Why the clock, and not the time zone, decides the digits

RFC 6238, the specification that defines time-based one-time passwords, describes itself as an extension of the HOTP algorithm of RFC 4226 "to support the time-based moving factor." Its first algorithm requirement, R1 in Section 3, states that "The prover (e.g., token, soft token) and verifier (authentication or validation server) MUST know or be able to derive the current Unix time ... for OTP generation."

The word carrying the weight is Unix. Section 4.2 defines the counter as T = (Current Unix time - T0) / X, with the floor function applied and T0 defaulting to zero, the Unix epoch. Section 4.1 sets the step: "X represents the time step in seconds (default value X = 30 seconds) and is a system parameter." Unix time is an absolute count of seconds and carries no time zone. A phone set to the wrong zone but correctly synchronised holds the correct Unix time, and its codes are accepted even though the lock screen shows the wrong hour. A phone whose absolute time has drifted two minutes shows a lock screen that looks perfectly normal and produces codes that fall past both of the tolerances quoted below. That asymmetry is why the offset reading, not the visible clock, is the test.

Section 5.2 records the reasoning behind the interval: the 30-second default "is selected as a balance between security and usability." The same section handles transmission lag, and it does so in the code's favour. A validation system "SHOULD typically set a policy for an acceptable OTP transmission delay window for validation", comparing an arriving code "not only with the receiving timestamp but also the past timestamps that are within the transmission delay" — capped at a recommended maximum of one time step of network delay. That is a rule for rescuing a code that has just rolled over, not a reason to reject one.

How far off is too far

There is no single number, and any article that gives one is inventing it. The specification leaves the tolerance to the party checking the code. Section 6 attributes the problem to "possible clock drifts between a client and a validation server" and recommends "that the validator be set with a specific limit to the number of time steps a prover can be 'out of synch' before being rejected."

The RFC then works one example through: "If the time step is 30 seconds as recommended, and the validator is set to only accept two time steps backward, then the maximum elapsed time drift would be around 89 seconds, i.e., 29 seconds in the calculated time step and 60 seconds for two backward time steps." That is an illustration of one possible policy, not a floor or a ceiling.

Microsoft's documentation for OATH tokens in Microsoft Entra ID states that it "adjusts time drift of the tokens during activation and every authentication", with a published table: a 30-second token gets plus or minus one day at activation and plus or minus one minute at sign-in; a 60-second token gets two days and two minutes.

Those two figures are the whole published record used here, and neither describes any other provider. Between them they bound only this: an Entra ID 30-second token is adjusted within a minute either way at sign-in, and a verifier configured like the RFC's example tolerates about 89 seconds. An offset of a minute is therefore at the edge of the tighter of the two, and two or three minutes is past both — the condition under which every code is refused rather than some. Most operators publish no figure at all, and a given site's window cannot be measured from outside. That is why the target is not "close enough" but "synchronised".

Section 6 permits one more behaviour that explains an odd symptom: "Upon successful validation, the validation server can record the detected clock drift for the token in terms of the number of time steps." A service doing that keeps accepting codes from a slow device for a while, then starts rejecting them once the error grows past the recorded correction.

The in-app time correction setting is gone

Older advice says to open Google Authenticator's settings and use "Time correction for codes" to resynchronise the app independently of the phone. That instruction now leads to a menu that does not exist, which is usually read as evidence that something else is wrong. Google's help page states the position plainly: "The time correction setting is no longer available in version 7.0. The app now uses the time setting on your operating system." The operating system clock is the only lever.

The same Google page lists what to confirm when codes do not work, and the list is short enough to quote in full: "You entered the code before it expired", "You entered the code for the correct app or service", "You entered the code for the correct Google Account", and "The time on your device is synced and correct for your local time zone."

Microsoft's Authenticator troubleshooting page states that "Authenticator requires your mobile device clock to accurately report your local time. If your device clock is set to manual, reconfigure your system clock to automatic", and adds a step that is easy to skip: "After updating your clock, restart your device and make sure the new time is set correctly." What that page does not contain is worth stating: the clock guidance sits under notifications expiring, there is no section on one-time password codes, and no in-app time-correction control is documented.

What to check when the clock is right and codes still fail

If time.gov reports an offset under a second and codes are still refused, the cause is elsewhere. Four checks cover most of it.

• The wrong entry in a crowded list. Two accounts on one service produce entries with near-identical labels. Both generate valid codes; only one is valid for the account being signed into.
• A stale entry left behind after a reset. When two-step verification is removed and set up again, the old entry stays in the app and keeps producing perfectly formatted codes from a secret the server has discarded. Deleting it is the fix. From the outside this looks identical to a clock failure.
• Entering a code in its final second. Google's checklist opens with "You entered the code before it expired". RFC 6238's one-step delay allowance runs the other way — it exists so a verifier can still accept a code that rolled over in transit — but whether a service implements it cannot be checked from outside. Waiting for a fresh code costs 30 seconds and removes the variable.
• An explicit resynchronisation flow. Some services offer one. AWS documents resynchronising a virtual MFA device by entering "the next two sequentially generated codes from the device" into two fields, warning that if you "wait too long to submit the request, the request appears to work but the device remains out of sync."

On a computer that dual-boots Windows with another operating system, the two can read the hardware clock differently and leave the wall clock hours off after each switch. Microsoft documents a registry entry named RealTimeIsUniversal under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TimeZoneInformation, noting that when it is enabled the system time reverts to the CMOS clock setting after a manual change. That article does not state how Windows interprets the hardware clock by default, so no default is asserted here. A whole-hours offset that returns after every reboot points to this area rather than to the app.

Getting back in when no code is accepted

Being locked out while the clock is fixed is the actual emergency, and backup codes are the intended path. Google issues them in sets: its support page offers "a new set of 10 backup codes whenever you want", and "After you use a backup code to sign in, that code becomes inactive." They are generated from the Google Account under Security, then 2-Step Verification, then Backup codes. Microsoft uses a different mechanism: a recovery code is "a 25-digit code used to help you regain access to your account ...", and generating a new one means "any previous codes will no longer work", so there is one active code rather than a set. Both are useless if they were never saved, which is the argument for generating them now on a working device.

When This Doesn't Apply

This diagnosis is narrow on purpose. Several nearby failures look identical from the outside without sharing a cause.

• Codes delivered by SMS or email are unaffected. Those are transmitted, not computed from a clock, and a wrong device clock does not invalidate them.
• Push approval prompts are a different mechanism. Nothing in an approval prompt is computed from the device clock, so a prompt that never arrives is not a computation problem, and what does cause it falls outside this diagnosis.
• Passkeys and security keys do not use a time counter. A drifted clock is not a cause of their failures.
• An offset under a second is not the cause, and an offset of seconds does not prove one. Neither published figure is remotely as narrow as a second, and an offset of seconds sits inside both — restore synchronisation, then keep working the four checks above.
• Intermittent rejection is a weaker signal than uniform rejection. A code that works one attempt in three points towards a duplicate entry, a stale secret or a slow submission rather than a clock, which would fail consistently.
• A wrong time zone alone does not break codes. The counter is derived from Unix time, which has no zone. Correct the time zone for the sake of a correct display, but it does not change whether codes are accepted.
• Managed and enterprise devices may not expose these controls. Where an MDM profile or domain policy governs time settings, the toggles above can be greyed out, and the fix belongs with whoever administers the policy.
• These two figures are the ones cited here, not a full list. They come from RFC 6238's worked example and Microsoft Entra ID's documentation. Most operators publish no figure, and a site's tolerance cannot be measured from outside.