The code was correct. I checked it against the screen three times, typed it slowly, and the login page still said "Invalid code."
I tried again. Same message. I refreshed the authenticator app, waited for a new code, tried a fifth time, and then sat there staring at a login page I'd used a hundred times without trouble.
Nothing about my account had changed. What had changed, a few weeks earlier, was my phone's clock. I'd switched off automatic time while testing how an app behaves near certificate expiry, and I never switched it back. My phone was about two minutes behind reality, and that was enough to make every code it produced useless.
That was the first time I properly understood something about security tokens: when they stop working, the token is usually fine. Something around it has drifted, expired, locked, or been wiped. Below are the ways I've seen it happen, roughly in the order they come up.
First, Which "Token" Do You Have?
People say "security token" and mean at least four different things, and the fix depends on which one you're holding.
- Authenticator app codes (Google Authenticator, Microsoft Authenticator, Authy). Six-digit codes that change every 30 seconds.
- Hardware keys (YubiKey and similar). The little USB or NFC device you tap or plug in.
- Older company key fobs (RSA SecurID-style). The small gadget with a screen and a number.
- Invisible tokens. The ones apps and websites use behind the scenes to keep you signed in. You never see them, but they expire too.
Work out which one is misbehaving before you try anything else.
Case File 1: The Code Is Right, but the Clock Is Wrong
Authenticator codes aren't sent to you. Your phone and the website each run the same calculation, using a shared secret plus the current time, and compare answers. If the two clocks disagree by more than a short window, the answers don't match.
Many servers allow a little slack, but not much. Off by a minute or two, and you're locked out with a perfectly valid-looking code.
What to check:
- Turn on automatic date and time in your phone settings. Not "set by hand," not "close enough."
- On Android, Google Authenticator has a "Time correction for codes" option in its settings. Tapping "Sync now" fixes drift without touching the system clock.
- Don't worry about time zones. The calculation uses universal time, so travelling doesn't break it. Only a wrong clock does.
It's the most common cause and the cheapest fix, so start here.
Case File 2: When the Server's Clock Is the Wrong One
This one cost me an evening.
I run a few virtual machines in my home lab, and one hosts a small self-hosted app with two-factor login. I'd broken something, reverted the VM to an older snapshot, and carried on. The next time I tried to log in, my codes failed.
My phone was right this time. The VM's clock had come back from the snapshot still living in the past, because time sync wasn't enabled inside the guest. It was doing the same calculation with the wrong time.
On a Linux VM, two commands tell you the story:
timedatectl status
If it says the system clock isn't synchronized, turn syncing back on:
sudo timedatectl set-ntp true
After a minute, the codes worked again.
If you use snapshots a lot, this can catch you out, and it can hit any time-based check, not just authenticator codes. I go through how snapshots work in How VM Snapshots Work, and a clock that jumps backwards is one side effect that surprises people.
Case File 3: The New Phone Problem
This isn't a malfunction. It's a loss, but from the outside it looks identical.
The secret behind your codes lives inside the authenticator app on that one phone. Buy a new phone, restore a backup, and unless your app has its own cloud backup or transfer feature, the codes don't come with you. Same when you factory reset or when the old phone dies.
I once wiped an old phone a little too eagerly before moving everything over. I'd transferred most accounts but not all of them. The one I missed was saved only by printed backup codes I'd stashed months earlier and mostly forgotten about.
So before you retire a phone:
- Open the authenticator app and count the accounts in it.
- Use the app's export or transfer feature, or re-enrol each account on the new phone.
- Log in once with the new phone for each important account before wiping the old one.
- Keep backup codes somewhere that isn't the same phone.
Case File 4: Hardware Keys Have Their Own Moods
Hardware keys are more reliable than app codes, but they still fail in their own ways. These are the ones I've actually run into:
The PIN lockout. Newer keys can be protected with a PIN. Get it wrong enough times (eight in a row, on the FIDO2 side of the keys I've used) and the key locks itself. The only way back is a reset, which wipes the credentials stored on it. You'd then have to re-register the key on every account, which is painful if it was your only way in. Register a second key and don't guess PINs.
The accidental code dump. Touch some keys while a text box is focused and they type out a long string of characters. It looks like a bug, but it's the key doing its job in the wrong place.
The port problem. A key that works in a laptop's built-in USB port can fail through a cheap hub or a loose cable. Try a different port before you blame the key.
NFC on phones. Phone cases and card wallets can block the connection. The antenna sits in a different spot on every phone, so move the key around slowly rather than pressing it harder.
Linux quirks. On some Linux setups, the key isn't recognized until the right system rules are in place. If it lights up but the browser ignores it, check the setup guide for your distribution.
Case File 5: Tokens That Simply Get Old
A friend who does IT for a small company called me because half the staff couldn't log in to the VPN one Monday morning. Nothing was broken. The old key fobs they'd been using for years had reached their expiry date.
Company fobs of the RSA SecurID type have a lifespan, and the date is usually printed on the back. When it passes, the code on the screen keeps changing but the server no longer accepts it. There's nothing to repair. Someone has to issue a new one.
Batteries in hardware tokens can also run out. If a fob's screen is dim or blank, that's your answer.
Case File 6: The Invisible Tokens
Sometimes there's no code and no device, and you get logged out or told your "token has expired."
When you sign in, most apps get an access token that's deliberately short-lived, sometimes just minutes or an hour, plus a longer-lived refresh token that quietly renews it. It goes wrong when:
- You change your password, and the site revokes every existing token for safety.
- You use "sign out of all devices."
- You revoke an app's permission in your account settings.
- You clear cookies, which deletes the stored proof of your login. I break down that one in Why Clearing Cookies Can Log You Out of Websites.
- The site simply decides you've been idle too long, which I cover in Why Websites Log You Out Automatically After Some Time.
These are all security features working as designed. The fix is nearly always to sign in again.
The Order I Check Things In Now
When a token stops working, I go through the same short list:
- Stop retrying. Too many failed attempts can trigger a temporary lockout, which turns a small problem into a bigger one.
- Check the clock on the phone first, then on the server if it's your own.
- Check which kind of token it is using the list at the top.
- Check for a recent change. New phone, factory reset, password change, restored snapshot, moved SIM.
- Try a backup method you set up earlier: backup codes, a second key, or a recovery option.
- Go through the site's official recovery process if nothing works. Slow beats improvising.
Most of the time I'm done by step 2.
Two Mistakes I'd Rather You Skip
Relying on one device for everything. If your phone is your only token and your phone is lost, broken, or wiped, you're in trouble. One spare method per important account is worth the ten minutes it takes.
Treating SMS as a safety net. Text codes can be delayed, filtered, or lost when you change SIM or travel. They're better than nothing, but I wouldn't build a recovery plan around them.
I keep a small sheet of printed backup codes in a drawer now, away from my desk and away from my phone. It feels a bit old-fashioned next to everything else I do. But it's the reason a dead phone is an annoying afternoon rather than a locked-out week.
comments