Fix SEC_E_OUT_OF_SEQUENCE (0x80090310) fast

Quick answer

Open Command Prompt as admin, run klist purge and w32tm /resync. Restart your app. If that doesn't work, reboot.

What's happening here

This error pops up when Windows thinks someone's replaying an old authentication token or your system clock is too far off from the domain controller. I've seen this most often when people jump between VPNs or switch wireless networks while a Kerberos ticket is half-used. The security layer sees a token it's already processed or one with a timestamp outside the allowed skew window — which is typically 5 minutes by default in Active Directory.

The exact error text reads: "The message supplied for verification is out of sequence." It's not a hardware failure. It's not malware. It's strictly an authentication sequencing problem between your machine and the server you're trying to reach. Nine times out of ten, it's a stale Kerberos ticket or a clock drift.

Fix steps

1. Open Command Prompt as administrator. Press the Windows key, type cmd, right-click Command Prompt, and choose "Run as administrator." Click Yes on the UAC prompt.
2. Purge your Kerberos tickets. In the command window, type klist purge and press Enter. You should see a confirmation that all tickets were purged. If you get a "Failed to purge" message, your user account might not have permission. Try logging off and back on instead.
3. Resync your system clock. Type w32tm /resync and press Enter. Wait for it to say "The command completed successfully." If it fails, run net stop w32time && net start w32time first, then retry the resync.
4. Restart your affected application. Close Outlook, SQL Server Management Studio, or whatever program showed the error. Wait 10 seconds. Open it again.
5. Test the connection. If the error's gone, you're done. If not, move to the alternative fixes below.

Alternative fixes if the main one doesn't work

Check for duplicate service principal names

If you're an admin and this keeps happening on a specific server, run this command on a domain controller: setspn -X. It will list duplicate SPNs. Duplicates confuse the Kerberos stack, making it think someone's replaying a token. Remove any duplicates with setspn -D.

Disable Kerberos and force NTLM fallback (temporary workaround)

This is a dirty fix, but it works when you're in a hurry. On the client machine, open Registry Editor (regedit), go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters, create a new DWORD called AllowTgtSessionKey, set it to 0. Reboot. This forces the client to use NTLM instead of Kerberos. Don't leave this on forever — NTLM is weaker and your security team will yell at you.

Reset the network adapter

Sometimes the token sequence is cached at the network driver level. Go to Control Panel > Network and Sharing Center > Change adapter settings. Right-click your active adapter, choose Disable. Wait 10 seconds. Right-click again, choose Enable. Then repeat the klist purge and time sync steps.

Prevention tips

• Keep your clock synced automatically. Go to Settings > Time & Language > Date & time. Turn on "Set time automatically" and "Set time zone automatically." Click Sync now.
• Don't switch networks while using Kerberos-authenticated apps. If you must, close the app first, switch networks, then reopen the app. This prevents the ticket from going stale mid-stream.
• For servers, set up a GPO that forces w32tm /resync every hour. You can do this via a scheduled task that runs as SYSTEM.
• If you use load balancers or reverse proxies, make sure they're configured to preserve client IPs and don't strip Kerberos tokens. Some load balancers break the sequence by injecting their own authentication headers.

If you're still getting this error after all that, check the server's event log for event ID 14 or 25 under Security-Kerberos. Those events will tell you exactly which SPN failed and whether it's a time issue or a replay. If you're not the server admin, forward that event ID to them. Don't waste your time reinstalling Windows — this is always an authentication state problem, not a corrupt OS.