SEC_E_INCOMPLETE_CREDENTIALS (0X80090320) Fix

The 30-Second Fix: Restart the Affected Service

I know this error is infuriating. You're trying to connect to a domain resource, access a remote desktop, or authenticate with a web service, and Windows throws SEC_E_INCOMPLETE_CREDENTIALS (0X80090320) back at you. The credentials you typed are fine — the system just can't verify them.

More often than not, this isn't a password problem. It's a handshake problem. Kerberos or NTLM authentication couldn't complete because something got stuck mid-process. My first move? Restart the service that handles authentication on your machine.

1. Press Win + R, type services.msc, and hit Enter.
2. Scroll to Credential Manager service. Right-click and select Restart.
3. Also restart Server and Workstation services (same way).
4. Now try your connection again.

If you're hitting this error with Remote Desktop, also restart Remote Desktop Services (TermService). I've seen this fix work on Windows 10 22H2 and Windows 11 23H2, especially when the error pops up after a VPN reconnect.

Didn't work? Don't worry — the next fix takes five minutes and hits the real cause most of the time.

The 5-Minute Fix: Sync Your System Clock

This tripped me up the first time too. Kerberos authentication is brutally time-sensitive. If your PC's clock is more than 5 minutes off from the domain controller (or the server you're connecting to), the authentication ticket gets rejected with 0X80090320.

The trigger is often a dual-boot system, a laptop that went to sleep for days, or a VM that got suspended. Windows Time service can drift badly.

1. Open Command Prompt as Administrator (Win + X, then Terminal (Admin)).
2. Run this command to force a sync with an internet time server:

   w32tm /resync

3. If that fails with “The computer did not resync because no time data was available,” try:
4. First, force re-register the time service:

   w32tm /unregister
   w32tm /register
   net start w32time
   w32tm /resync

5. Check your current time offset:

   w32tm /stripchart /computer:time.windows.com /samples:3

6. If the offset is large (over 5 seconds), manually set the clock: go to Settings > Time & Language > Date & Time, toggle Set time automatically off and on again.

I've seen this resolve the error instantly after a resync. Test your connection again.

The 15+ Minute Fix: Clear Kerberos Tickets and Check Group Policy

If you're still stuck, cached Kerberos tickets or misconfigured Group Policy are the usual suspects. This happens most on Windows Server 2019/2022 or domain-joined workstations that changed network zones (e.g., from corporate LAN to VPN).

Step 1: Purge Stale Kerberos Tickets

1. Open Command Prompt as Administrator.
2. Run:

   klist purge

   This clears all cached Kerberos tickets. They'll be reissued on next authentication.

3. If you know the specific server, you can list and remove only its ticket:

   klist
   klist purge -li 0x3e7

   (The -li 0x3e7 flag targets the local system account's tickets.)

Step 2: Check for Conflicting Credential Manager Entries

Windows Credential Manager sometimes stores old passwords that conflict with current ones, especially for Remote Desktop or mapped drives.

1. Open Control Panel > User Accounts > Credential Manager.
2. Click Windows Credentials.
3. Look for any entries related to the server/domain you're trying to reach. If you see generic credentials or old RDP entries, remove them.
4. Reboot and retry.

Step 3: Review Group Policy for ‘Network security: Restrict NTLM’ Settings

If your organization tightened NTLM restrictions, Kerberos might fail and NTLM fallback gets blocked, causing 0X80090320.

1. Open Local Group Policy Editor (gpedit.msc).
2. Navigate to Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options.
3. Check these policies:
   • Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers — if set to “Deny all,” change to “Allow all” or “Audit all” temporarily to test.
   • Network security: Restrict NTLM: NTLM authentication in this domain — similar restriction can block.
4. Don't change these permanently unless you're sure — check with your admin first if you're on a corporate network.

I've seen a client where a misapplied GPO blocked NTLM fallback entirely, and the only symptom was this error when connecting to a file share. After reverting the GPO, authentication worked immediately.

Still Broken? Check the Event Logs

If none of the above worked, open Event Viewer (eventvwr.msc) and look under Windows Logs > Security for event ID 4625 (failed logon). The details often include a Status and Sub Status code. A sub-status of 0xC000006D usually means a bad password or username. 0xC000006E points to a time skew. Post the sub-status in a comment below, and I'll point you to the specific fix.

Pro tip: If you're on a home network and not using a domain, you're likely hitting a Schannel error (TLS handshake). In that case, check the System log for Schannel warnings. The fix may be updating root certificates or disabling outdated TLS versions.