The code 0x80004005 is the generic Windows HRESULT for an unspecified error, so it appears in many contexts. In Remote Desktop it almost always surfaces as the dialog "An authentication error has occurred (Code: 0x80004005)", which means the client and the host could not complete the authentication handshake. The usual culprits are the credentials or username format, a Network Level Authentication (NLA) or CredSSP mismatch between the two machines (often after one side installs a Windows update and the other does not), stale saved credentials, or a clock or certificate-trust problem. This guide works through those causes in order of likelihood, from verifying credentials to patching both ends, and finishes with Microsoft's documented .rdp workaround for trusted networks. Note that this is an authentication error, not the yellow "Unknown publisher" trust prompt, which is a separate and expected dialog covered in the FAQ.
Before you start
What you will learn
- How to diagnose and resolve the Remote Desktop message "An authentication error has occurred (Code: 0x80004005)" by working through its real causes: credentials, Network Level Authentication, CredSSP, updates, and time sync.
- This error blocks the connection entirely, so an admin who cannot RDP to a server loses remote management until it is fixed, and the generic code gives no obvious starting point.
Requirements
- You need an account allowed to sign in to the remote host, and network access to it on TCP 3389. The Windows Update, NLA, and time-sync steps require local administrator rights on the remote host.
- Windows 10 or Windows 11 client using the built-in Remote Desktop Connection client (mstsc.exe), connecting to a Windows host with Remote Desktop enabled and reachable on TCP 3389.
- Account with Remote Desktop sign-in rights on the host
- Local Administrator on the host (for update, NLA, and time steps)
Good to know
- Most cases are resolved in the first few steps; the .rdp workaround is a last resort.
- Verified against current Microsoft Learn RDP documentation, July 2026.
Quick answer
First confirm the host is reachable on port 3389 and that the message really is the 0x80004005 authentication error. Then sign in with the correct username format (domain\user or user@domain.com), make sure the password is not expired, and install pending Windows updates on both the client and the host before rebooting both. Most cases clear at that point; if not, clear saved credentials and check the clock, and only as a last resort on a trusted network edit the .rdp file to relax server authentication.
Remote Desktop Connection (mstsc.exe) > Show OptionsTest-NetConnection -ComputerName <host> -Port 3389Step-by-step tutorial
6 stepsConfirm it is the 0x80004005 authentication error and the host is reachable
Separate an authentication failure from a network or name-resolution problem before changing anything.
Start > Terminal (Admin)In the failing Remote Desktop dialog, note the exact wording. This guide applies when it reads "An authentication error has occurred (Code: 0x80004005)". Then confirm the host is actually reachable on the RDP port from an elevated PowerShell window (replace <host> with the name or IP):
Test-NetConnection -ComputerName <host> -Port 3389
If TcpTestSucceeded is False, stop: the problem is connectivity, firewall, or a wrong address, not this authentication error. If it is True but you still get 0x80004005, continue with the steps below.
Test-NetConnection -ComputerName <host> -Port 3389If name resolution is suspect, test with the IP address as well as the hostname. This step changes nothing, so it is safe to run anytime.
Sign in with the correct username format and a valid password
Rule out the most common cause: a malformed username or an expired or mistyped password.
mstsc.exe > Show Options > GeneralOpen Remote Desktop Connection (mstsc.exe), click Show Options, and on the General tab enter the user name in a fully qualified form:
- Domain account: DOMAIN\username or username@domain.com
- Standalone or workgroup host: COMPUTERNAME\username
Avoid relying on a previously saved credential; if one is offered, choose More choices > Use a different account and type the credentials again. Confirm the account's password has not expired and that the account is a member of the Remote Desktop Users group (or an administrator) on the host.
An expired password frequently produces authentication errors over RDP even though the same account works at the console. Reset it at the console or through another admin first if you suspect this.
Install pending Windows updates on both the client and the host, then reboot
Eliminate a CredSSP or NLA version mismatch, the classic cause when RDP worked before and broke after patching one side.
Settings > Windows Update > Check for updatesCredSSP and NLA behaviour is updated through Windows cumulative updates, and a client and host at different patch levels can fail authentication with this error. Install all pending updates on both the machine you are connecting from and the host, then reboot both. You can confirm recent updates from PowerShell:
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 5
After both machines are current and rebooted, try the connection again.
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 5Patch both ends to the same level rather than leaving one machine behind, since the mismatch itself is often the cause. Historically this pattern also relates to the CredSSP Encryption Oracle Remediation update, though that usually shows its own distinct message.
Clear stale saved Remote Desktop credentials
Remove cached credentials that no longer match the host so the client authenticates fresh.
Control Panel > Credential Manager > Windows CredentialsSaved credentials that have since changed or expired can cause repeated authentication failures. List and remove the saved entry for the host, then reconnect and type the credentials again. From an elevated Command Prompt (replace <host> with the exact name you connect to):
cmdkey /listcmdkey /delete:TERMSRV/<host>
Alternatively, open Control Panel > Credential Manager > Windows Credentials and remove any entry beginning with TERMSRV/ for that host.
cmdkey /list
cmdkey /delete:TERMSRV/<host>The name after TERMSRV/ must match exactly what you type in the connection bar (hostname or IP). Removing the entry only clears the saved credential; it does not change any account password.
Align Network Level Authentication and the system clock
Fix NLA inconsistencies and time or certificate-trust skew that break the authentication handshake.
Settings > System > Remote Desktop (or SystemPropertiesRemote.exe)On the host, open System > Remote Desktop (or SystemPropertiesRemote.exe on older builds) and confirm Remote Desktop is enabled. If the host requires NLA, make sure the client also supports and uses it; a mismatch here can produce this error. Then confirm the clocks agree: Kerberos and certificate validation fail when the client and host clocks differ by more than a few minutes. From an elevated Command Prompt on the affected machine:
w32tm /resync
Correct the time zone and re-sync if the clock is off, then retry the connection.
w32tm /resyncOn domain machines, time normally syncs from the domain hierarchy; a large skew often points to a broken time source or a VM whose clock drifted. Fix the source rather than only forcing a one-off resync.
Last resort: relax .rdp server authentication on a trusted network
Unblock the connection for troubleshooting when the causes above are ruled out, using Microsoft's documented .rdp settings.
mstsc.exe > Show Options > Save As, then edit the .rdp in NotepadOnly on a trusted network, and only to isolate the problem, you can turn off the server-authentication check and CredSSP for a single connection. In mstsc.exe, click Show Options > Save As to save a .rdp file, then open it in Notepad and set or add these lines:
authentication level:i:0enablecredsspsupport:i:0
Save the file and connect by opening it. Setting the authentication level to 0 stops the client from checking server authentication, and disabling CredSSP support skips that provider. For an Entra ID (Azure AD) joined host, do not disable CredSSP; instead select Use a web account to sign in to the remote computer (the enablerdsaadauth:i:1 property), connect by hostname, and sign in with the full UPN.
Treat this as a diagnostic, not a permanent configuration. Once the underlying cause (updates, credentials, time, or trust) is fixed, revert to authentication level:i:2 and enablecredsspsupport:i:1 to restore protection.
How to Confirm the Remote Desktop Connection Now Authenticates
To verify the fix, open Remote Desktop Connection, enter the host and your fully qualified username, and connect. The session should reach the remote desktop or the Windows sign-in without returning "An authentication error has occurred (Code: 0x80004005)". If you used the .rdp workaround only to diagnose, restore the secure defaults (authentication level:i:2 and enablecredsspsupport:i:1) and confirm the connection still succeeds, which proves you fixed the real cause rather than masking it. Test a second time after a reboot of the client to be sure the fix persists and was not just a transient state.
- The connection authenticates and opens the remote session, and it still works after you restore the secure .rdp defaults.
- If it only works with authentication level:i:0 and enablecredsspsupport:i:0, the root cause is still present: recheck updates on both ends, the clock, and whether the host is Entra-joined and needs web-account sign-in.
- Client warns and lets you decide if server authentication fails; the secure setting to return to.
- CredSSP re-enabled after diagnosis, restoring Network Level Authentication behaviour.
- Confirms the host is reachable on 3389, so a remaining failure is authentication, not connectivity.
Troubleshooting
The error started right after a Windows update and now only some connections fail
Cause: CredSSP or NLA behaviour changed on the patched side while the other machine is at a different level, so authentication cannot be negotiated.
Install pending updates on BOTH the client and the host so they are at the same level, then reboot both. Do not leave one side unpatched, and avoid disabling CredSSP as a permanent fix.
0x80004005 happens on one specific host but not others
Cause: That host is out of date, has a clock or certificate-trust problem, or the account is missing Remote Desktop sign-in rights there.
Update and reboot that host, run w32tm /resync to correct its clock, and confirm the user is in the Remote Desktop Users group or is an administrator on that machine.
Connecting to an Entra ID (Azure AD) joined or workgroup host keeps failing authentication
Cause: Remote Desktop cannot serialize the credentials the usual way for a non-domain or Entra-joined host, so the handshake fails even with correct credentials.
For Entra-joined hosts, use Use a web account to sign in (enablerdsaadauth:i:1) with the full UPN and ensure Remote Desktop Users membership. For workgroup hosts, use COMPUTERNAME\username and confirm matching local accounts.
Disabling CredSSP in the .rdp file still fails or still prompts for a password
Cause: The host requires NLA or an SSO or gateway configuration is in play, so relaxing the client alone does not resolve it.
Re-enable CredSSP and NLA and fix the real cause instead: patch both ends, correct credentials and time, and verify the host's Remote Desktop and NLA settings. Use the workaround only to confirm where the problem lies.
A yellow "Unknown publisher" banner appears, but there is no 0x80004005 code
Cause: That is the normal Remote Desktop publisher-trust prompt for .rdp files, which is a separate, expected dialog and not the authentication error this guide covers.
For a .rdp file you created or trust, it is safe to proceed, and you can tick "Don't ask me again for connections to this computer" to suppress it. No authentication fix is needed for that prompt alone.
Frequently asked questions
What does error 0x80004005 mean in Remote Desktop?
0x80004005 is the generic Windows code for an unspecified error. In Remote Desktop it appears as "An authentication error has occurred (Code: 0x80004005)", meaning the client and host could not complete authentication, usually because of credentials, NLA, CredSSP, updates, or a clock or trust mismatch.
Why did RDP suddenly start failing with 0x80004005 when it worked before?
The most common trigger is a Windows update that changed CredSSP or NLA on one machine while the other stayed behind. Patch both the client and the host to the same level and reboot both; the mismatch itself is often the cause.
Is editing the .rdp file to disable CredSSP safe?
Setting authentication level:i:0 and enablecredsspsupport:i:0 turns off server authentication and CredSSP for that connection, so it should be used only on a trusted network and as a temporary diagnostic. Fix the underlying cause and restore the secure defaults afterwards.
How do I connect to an Entra ID (Azure AD) joined PC over RDP?
Use the Advanced option "Use a web account to sign in to the remote computer" (the enablerdsaadauth property), connect by the host name rather than IP, sign in with your full UPN, and make sure your account is in the Remote Desktop Users group on the host.
Is the "Unknown publisher" warning the same as error 0x80004005?
No. The "Unknown publisher" yellow prompt is a normal trust dialog shown for .rdp files and does not block authentication, whereas 0x80004005 is an authentication failure. They are unrelated, and suppressing the publisher prompt will not fix the 0x80004005 error.
Do I need administrator rights to fix this error?
Client-side steps such as correcting the username, clearing saved credentials, and editing your .rdp file do not need admin rights. Updating the host, changing its NLA or Remote Desktop settings, and correcting its clock require local administrator rights on the host.
