Ever typed a six-digit code the instant it appeared on your phone, only to be told it’s invalid? You’re not imagining things, and you’re not alone. That frustrating rejection is almost always TOTP clock drift at work, and the fix is usually simpler than people expect.
Time-based one-time passwords (TOTP) are the backbone of two-factor authentication across banking, email, and developer tools. They work because both the phone and the server independently calculate the same code from a shared secret plus the current time. When those two clocks disagree, the codes stop matching. This guide explains the actual mechanism, walks through the practical fixes from easiest to most involved, and covers the mistakes that make the problem worse.
How TOTP Actually Calculates a Code
To fix drift, you first need to understand what’s drifting. TOTP is defined in RFC 6238, which builds on the older counter-based HOTP algorithm from RFC 4226. The core formula is straightforward: both sides compute a time-step counter using the current Unix time, divided into fixed 30-second slices by default. That counter, combined with the shared secret, produces the six-digit code.
Because the counter is derived from the clock, a code is only valid during its 30-second window. If your phone’s clock is two minutes behind the server’s, your phone is generating codes for a time step that has already passed. The server checks its own current window, finds no match, and rejects the attempt.
The important nuance is that servers are allowed to tolerate a small amount of drift. RFC 6238 permits checking a validation window of adjacent time steps rather than only the current one. This is why a code that’s 20 seconds stale often still works. But that window is deliberately narrow, because every extra step you accept widens the door for an attacker to replay an intercepted code.
Diagnosing the Problem Before You Fix It
Before changing anything, confirm that clock drift is actually the cause. Not every rejected code is a drift problem, and chasing the wrong issue wastes time.
Signs that point to clock drift
The clearest signal is consistent, repeatable failure that follows a pattern. If codes fail intermittently, work on the second try, or fail only on one specific device, drift is a strong suspect. If codes from a particular authenticator app always fail while another app on the same phone works, the problem is more likely the app’s stored secret or a duplicate enrollment.
A quick diagnostic: compare the clock on the device generating codes against a trusted time source. If the device is off by more than roughly 30 seconds, you’ve found your culprit. Many authenticator apps display the current time on the code screen specifically so users can spot this mismatch.
Signs that point elsewhere
If the code is rejected immediately and consistently on a brand-new enrollment, the shared secret may have been entered incorrectly, or the QR code was scanned twice creating two separate entries. If only one service fails while others work, the issue is on that service’s server side, not your phone. And if the problem appeared after a device restore or app migration, a stale backup of the secret is the more likely explanation.
The Fixes, From Easiest to Most Involved
Work through these in order. In most real-world cases, the answer is in the first two steps.
1. Enable automatic time synchronization on the device
This resolves the majority of cases. On Android, the setting lives under Settings, then System, then Date and time, where automatic date and time should be toggled on. On iOS, it’s under Settings, then General, then Date and Time, with Set Automatically enabled. Desktop authenticators and password managers inherit the operating system clock, so fixing the OS clock fixes them too.
The mechanism behind this is the Network Time Protocol, standardized in RFC 5905. When automatic time is on, the device periodically queries time servers and corrects its own clock. When it’s off, the device’s clock free-runs and slowly accumulates error, which is exactly how drift builds up over weeks and months.
A practical tip that saves a lot of confusion: after enabling automatic time, close and reopen the authenticator app. Some apps cache the time value at launch and won’t reflect the correction until restarted.
2. Force a manual resync inside the app
Many authenticator apps include a built-in sync option. Google Authenticator, for instance, has historically offered a time correction setting that adjusts the app’s internal clock. Microsoft Authenticator and several password managers expose similar resync controls. Running this once after a device clock fix is a cheap insurance step.
If your app has no resync option, removing and re-adding the account is the fallback. That means re-scanning the QR code, which requires access to the original service’s security settings. This is where people get stuck, so plan ahead: make sure you have backup codes or a second enrolled device before you delete anything.
3. Fix the server side, not only the phone
Here’s the part most guides skip. If you run the service validating the codes, the fix belongs on your server. A server whose clock has drifted will reject valid codes from perfectly synchronized phones. The correct remedy is to ensure the server runs a reliable time synchronization daemon and that outbound NTP traffic isn’t blocked by a firewall.
This is a classic infrastructure mistake. Teams spin up a new server, forget to configure time sync, and then spend hours debugging “broken 2FA” that is actually a five-minute clock offset. If you’re troubleshooting broader connectivity symptoms at the same time, it helps to separate network faults from time faults early, much like the diagnostic approach in this guide to fixing a website that will not load. Isolating the layer is half the battle.
4. Widen the validation window carefully
If you control the server configuration, you can increase the number of time steps the validator accepts. Going from a ±1 step window to ±2 tolerates roughly ±60 seconds of drift.
Treat this as a last resort, not a default. Every additional step increases the window during which a stolen code remains replayable. The better long-term answer is fixing the clock, not loosening the check. If you find yourself widening the window repeatedly, that’s a signal that time synchronization across your fleet is broken and needs attention.
5. Handle the edge cases
A few scenarios need special handling. Devices with dying CMOS batteries, especially older hardware, lose time whenever they power off. Virtual machines can drift badly if their host’s clock is unstable or if time sync integration is disabled. And devices that travel across time zones sometimes behave oddly if the user manually sets the clock instead of letting the network handle it.
A Comparison of Fixes and When to Use Them
| Fix | Effort | Who can do it | Best for |
|---|---|---|---|
| Enable automatic time sync | Very low | End user | Most single-device failures |
| In-app resync | Low | End user | Apps with cached clocks |
| Re-enroll the account | Medium | End user | Corrupted or duplicated secrets |
| Server-side NTP repair | Medium | Admin | All users failing at once |
| Widen validation window | Low | Admin | Temporary stopgap only |
The pattern is clear: user-side fixes handle user-side problems, and admin-side fixes handle systemic ones. Matching the fix to the scope of the failure is what separates a five-minute repair from a week of confusion.
Common Mistakes That Make Drift Worse
Manually setting the clock to “fix” it. This is the single most common error. Setting the time by hand feels precise, but it’s only accurate to the second you tapped the button, and the device starts drifting again immediately. Automatic sync is always better.
Widening the window as a permanent solution. It works, and that’s the trap. Teams widen the window during an incident, forget to revert it, and quietly weaken their security posture for months.
Deleting the account before checking for backups. Re-enrollment is sometimes necessary, but doing it without backup codes can lock you out of the account entirely. Always confirm you have a recovery path first.
Ignoring the server clock. Endless phone-side troubleshooting accomplishes nothing if the server is the one that’s wrong. Check both sides.
Assuming all 2FA failures are drift. A surprising number are actually duplicate enrollments or mistyped secrets. Verify the diagnosis before applying the fix.
How Drift Interacts With the Rest of Your Stack
Clock problems rarely announce themselves as clock problems. They masquerade as authentication bugs, network failures, or application errors. Anyone who spends time troubleshooting systems learns to check the clock early, because time skew causes failures that look like everything except time skew.
The same principle applies to performance troubleshooting. When a system behaves erratically and the obvious causes don’t hold up, checking background processes and timing issues often reveals the real culprit, in the same way that diagnosing antimalware service executable high CPU usage requires looking past the surface symptom to the underlying resource contention. Time is just another shared resource that can fall out of sync.
For developers, the lesson is to build observability around time. Log the server’s current time step alongside authentication failures. A single log line showing “expected step 58201941, received 58201937” turns a mystery into a four-step diagnosis.
Prevention: Stopping Drift Before It Bites
Prevention is mostly about defaults. Enable automatic time on every device that generates codes. Configure NTP on every server that validates them. Monitor for clock offset as a standard infrastructure metric, the same way you’d monitor disk space or memory.
For end users, the practical habits are simple. Keep automatic time enabled. Don’t manually adjust the clock unless you have no other option. Keep backup codes stored somewhere accessible. And enroll a second device where the service allows it, so a single broken authenticator never becomes a lockout.
For teams, document the resync procedure. When an incident hits, nobody wants to be reading vendor documentation for the first time. A short runbook covering “how to resync authenticator apps” and “how to verify server NTP status” pays for itself the first time it’s needed.
If you’re the type who enjoys understanding the mechanics behind everyday tools, the same curiosity that makes clock drift solvable also makes hobbies like drifting games more interesting, since both reward understanding the underlying system rather than just reacting to symptoms.
Conclusion
TOTP clock drift is one of those problems that feels mysterious until you see the mechanism, and then it feels obvious. Two clocks must agree, and when they don’t, codes fail. The fix almost always starts with enabling automatic time synchronization on the device, followed by an in-app resync if the app caches its clock. When failures hit everyone at once, the problem has moved to the server, and the answer is proper NTP configuration rather than a wider validation window.
The deeper lesson is about discipline. Widening the window works, which is exactly why it’s dangerous as a habit. Fixing the clock is slightly more effort and dramatically more secure. Choose the clock.
Frequently Asked Questions
Why does my authenticator code keep getting rejected?
The most common cause is a clock mismatch between your device and the server. If your phone’s clock is off by more than about 30 seconds, the codes it generates fall outside the server’s validation window. Enable automatic date and time in your device settings, then restart the authenticator app so it picks up the corrected time.
How much clock drift can TOTP tolerate?
By default, most implementations accept a window of roughly one time step in each direction, which works out to about 30 seconds of tolerance. RFC 6238 allows servers to check adjacent time steps but leaves the exact window size to the implementer. Larger windows tolerate more drift but also keep stolen codes valid for longer.
Does fixing my phone’s clock fix all TOTP problems?
No. It fixes drift on your device, which covers most single-user cases. If every user of a service is failing at once, the server’s clock is the likely culprit and needs NTP configuration. If only one account fails while others work, the stored secret for that account is more likely the issue than the clock.
Is it safe to increase the TOTP validation window?
It’s a reasonable temporary stopgap but a poor permanent setting. Each additional time step you accept extends the period during which an intercepted code can be replayed. Use a wider window only while you repair the underlying time synchronization, then tighten it back to the default.
Why do codes fail right after I restore my phone from a backup?
Restoring a backup can bring back a stale copy of the authenticator’s data, or it can leave the app’s internal clock out of step with the system clock. Restart the app first. If codes still fail, remove and re-enroll the affected accounts using their backup codes or QR codes, and confirm automatic time is enabled.
Can a virtual machine suffer from TOTP clock drift?
Yes, and it’s fairly common. Virtual machines rely on their host or on time sync integration to stay accurate. If the host’s clock is unstable or sync integration is disabled, the guest drifts and any authenticator running inside it generates rejected codes. Enable host time synchronization and verify the guest’s clock against a trusted source.
