Remote Desktop Stuck at Securing Remote Connection: 7 Fixes That Work

When Remote Desktop is stuck at "Securing remote connection", the client has reached the server and is stuck in the security handshake: agreeing on TLS encryption, checking the server's certificate and, with Network Level Authentication, sending your password through CredSSP. A short hang is usually your PC checking the certificate online; one that ends in an error usually means stale saved credentials, a CredSSP mismatch, a broken RDP certificate, a network path that drops UDP or large packets, a wrong DNS answer or a server too busy to reply. The fixes below run from quickest to deepest, each with a way to tell whether it is your case.

Every Windows VPS from RS Computers in Amsterdam, Dublin and Prishtina has a console in the client area that shows the server's screen without RDP, so server-side fixes stay within reach.

Key facts, checked on 11 November 2026:

• Microsoft's article Remote desktop connection is stuck (KB 2915774, updated 12 February 2026) says that with a self-signed certificate "the system tries to retrieve the trusted certification authority list from the Internet", so the screen "may appear for a while". The same article says that certificate expires after six months and is re-created.
• CredSSP errors go back to CVE-2018-0886: the fix shipped on 13 March 2018, and on 8 May 2018 the default changed from Vulnerable to Mitigated, so patched clients stopped talking to unpatched servers.
• Network Level Authentication "completes user authentication before you establish a Remote Desktop connection and the logon screen appears" (Microsoft Learn), which is why a wrong password surfaces right after this screen.
• The client policy "Turn Off UDP On Client" writes fClientDisableUDP (Policy CSP).

What Remote Desktop is doing during "Securing remote connection"

By the time the client negotiates security, port 3389 has usually answered, so a closed firewall is rarely the cause here; our guide to Remote Desktop connection errors covers the cases where the port never answers. In this stage the client picks "the highest possible security level encryption method" both sides support, in Microsoft's words. The server presents its certificate, usually a self-signed one it made itself, and your PC checks it, sometimes by fetching lists from the internet. Then, with NLA on, CredSSP sends your user name and password for the server to check before it creates a session. Those last two steps are where nearly every hang lives.

Symptom, cause and fix at a glance

Fix 1: stale saved credentials ("securing remote connection, then incorrect password")

NLA checks your password during this stage, so a saved password that no longer matches makes the client sit on "Securing remote connection" and then say your credentials did not work. Repeat it and the account locks; our Windows template locks after 10 wrong attempts in 10 minutes, as our guide to securing RDP on Windows Server explains. How to tell: it fails from one PC only, or works when you type the password by hand. List the stored credentials with Microsoft's cmdkey command:

:: Command Prompt on your own PC, as your normal user
cmdkey /list

Delete the entry whose target contains your server's address (Remote Desktop entries normally start with TERMSRV/), pasting the name exactly as listed:

:: Command Prompt on your own PC
cmdkey /delete:TARGET_NAME_FROM_THE_LIST

Control Panel, Credential Manager, Windows Credentials does the same with clicks. Then connect again as .\Administrator or COMPUTERNAME\user, so the name isn't sent to your PC's own account.

Fix 2: CredSSP and NLA mismatch

CredSSP carries your credentials, and NLA depends on it. Microsoft's CredSSP encryption oracle remediation article shows the result of a mismatch: an updated client set to Force updated clients or Mitigated blocks an unpatched server with "An authentication error has occurred. The function requested is not supported."

The fix is Windows Update on both machines; a Windows 10 PC gets security updates only through Extended Security Updates. To reach an unpatched server once and update it, Microsoft documents a temporary client workaround and warns that it "will expose the remote server to attacks": in gpedit.msc, Computer Configuration, Administrative Templates, System, Credentials Delegation, set Encryption Oracle Remediation to Enabled with Protection Level Vulnerable. Microsoft's command-line version:

:: Command Prompt as Administrator, on your own PC (temporary)
REG ADD HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters\ /v AllowEncryptionOracle /t REG_DWORD /d 2

In Microsoft's table 0 is Force updated clients, 1 Mitigated and 2 Vulnerable. Once the server is patched, rerun it with /d 1 (answer Yes to overwrite) or set the policy back to Not configured.

If the client says your computer does not support NLA, check About in Remote Desktop Connection (icon at the top left) for "Network Level Authentication supported" and update the client rather than switching NLA off. For "The Local Security Authority cannot be contacted", Microsoft's article on that error says it "generally" points to network congestion or a TLS mismatch. Its fix, dropping the server to RDP Security Layer, is written for Windows Server 2008 R2, so on current Windows test the network path first (fix 5).

Fix 3: the server's RDP certificate

Slow but it connects

This is the "slow to connect" case: your PC fetches the trusted certification authority list to check the self-signed certificate. Microsoft's Method 1 removes the wait by trusting the certificate on your PC:

1. On the server, run mmc, choose File, Add/Remove Snap-in and add Certificates for the Computer account on the Local Computer.
2. Open Remote Desktop, Certificates, double-click the certificate and on the Details tab choose Copy to File with the default settings.
3. Copy the file to your PC, open the same snap-in there, right-click Trusted Root Certification Authorities, Certificates, choose All Tasks, Import, and store it in Trusted Root Certification Authorities.

The certificate is re-created after six months, so repeat the import then.

Hangs or fails: a damaged or expired certificate

A broken certificate or private key makes the client hang here or at "Configuring remote session", or report "An internal error has occurred". Microsoft's internal error article lists "The certificate is corrupted or expired" as a cause and renews it with these lines, run on the server through the console:

# PowerShell as Administrator, on the server (through the console)
Import-Module PKI
Set-Location Cert:\LocalMachine
$RdpCertThumbprint = 'Cert:\LocalMachine\Remote Desktop\'+((Get-ChildItem -Path 'Cert:\LocalMachine\Remote Desktop\').thumbprint)
Remove-Item -Path $RdpCertThumbprint
Stop-Service -Name "SessionEnv"
Start-Service -Name "SessionEnv"

SessionEnv, the Remote Desktop Configuration service, creates a new certificate, so expect the certificate warning once. If none appears, Microsoft's "An internal error has occurred" guide says CertPropSvc, KeyIso, CryptSvc and SessionEnv must be running, and lists the permissions the MachineKeys folder needs.

That guide also tests negotiation by setting SecurityLayer and UserAuthentication to 0, which switches TLS and NLA off. We show only Microsoft's restore lines, because with both at 0 anyone reaching port 3389 gets a login screen without NLA; if you run the test, keep it to minutes, with RDP limited to your IP, and finish with:

:: Command Prompt as Administrator, on the server - restore the recommended values
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v SecurityLayer /t REG_DWORD /d 2 /f
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v UserAuthentication /t REG_DWORD /d 1 /f

"A security package error occurred in the transport layer" has no Microsoft article of its own. In one Microsoft Q&A thread the cause was a root certificate signed with MD5 instead of SHA-256, so start with these certificate checks.

Fix 4: UDP transport problems

Remote Desktop uses TCP and UDP on port 3389. A VPN or router that passes the first UDP packets and loses the rest can stall the connection. How to tell: it hangs on one network only. To test TCP only, enable the policy Computer Configuration, Administrative Templates, Windows Components, Remote Desktop Services, Remote Desktop Connection Client, Turn Off UDP On Client. Microsoft's RDP Shortpath article gives this check of the value:

# PowerShell on your own PC
$regKey = Get-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\Client"

If ($regKey.PSObject.Properties.name -contains "fClientDisableUDP" -eq "True") {
    If (($regkey | Select-Object -ExpandProperty "fClientDisableUDP") -eq 1) {
        Write-Output "The default setting has changed. UDP is disabled."
    } elseif (($regkey | Select-Object -ExpandProperty "fClientDisableUDP") -eq 0) {
        Write-Output "The default setting has changed, but UDP is enabled."
    }
} else {
    Write-Output "The default setting hasn't been changed from its default value. UDP is enabled."
}

If gpedit.msc won't open, as on Windows Home, set the value directly. This line uses the documented reg add syntax with Microsoft's key and value name; 1 means UDP off:

:: Command Prompt as Administrator, on your own PC
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\Client" /v fClientDisableUDP /t REG_DWORD /d 1 /f

Restart the PC, as Microsoft advises for this policy, and connect again. If the hang is gone, UDP was the problem; set the value back to 0 on a better network.

Fix 5: MTU and VPN problems

The security stage carries the first large packets, the server's certificate. If a VPN shrinks the path below 1,500 bytes and oversized packets are silently dropped, the small packets get through and the big ones vanish. How to tell: it hangs only with the VPN on, or you see the Local Security Authority error. Microsoft's ping reference says /f, the Do not Fragment flag, "is useful for troubleshooting path Maximum Transmission Unit (PMTU) problems", and /l sets the data size:

:: Command Prompt on your own PC, with the VPN connected
ping /f /l 1472 YOUR_SERVER_IP
ping /f /l 1372 YOUR_SERVER_IP

1,472 bytes of data plus 28 bytes of IPv4 and ICMP headers make a full 1,500-byte packet. If the first fails and the second answers, lower the size until replies come back; the largest working size plus 28 is your path MTU. If the server never replies at any size, its firewall blocks ping; test another address behind the same VPN. Set the MTU in your VPN client if it has the option; otherwise find the VPN adapter's index with Get-NetIPInterface and use the -NlMtuBytes parameter of Set-NetIPInterface (576 bytes is the IPv4 minimum):

# PowerShell as Administrator, on your own PC - replace 12 with the VPN adapter's ifIndex
Get-NetIPInterface -AddressFamily IPv4
Set-NetIPInterface -InterfaceIndex 12 -NlMtuBytes 1400

Fix 6: DNS and name resolution

A host name can point to the wrong machine: an old address after a move, a stale hosts file entry, or a VPN's own DNS. Microsoft's Local Security Authority article quotes the message for it: "This could be caused by an outdated entry in the DNS cache. Try using the IP address of the computer instead of the name." How to tell: the IP works and the name does not. Check the answer and clear the cache with Resolve-DnsName and ipconfig:

# PowerShell on your own PC
Resolve-DnsName -Name YOUR_SERVER_NAME
ipconfig /flushdns

Compare the result with the addresses in your client area; if the name returns an IPv6 address your network can't reach, connect by IPv4.

Fix 7: a busy server, audio, or Remote Desktop licensing

If every device hangs and it started on a particular day, look at the server through the console. A server installing updates after a restart, or one with memory at 100%, accepts the connection and answers the handshake very slowly; Task Manager's Performance tab shows which. Microsoft recommends 4 GB for Windows Server 2025 with the desktop, so one busy program on a small plan can push it over.

An odd case from Microsoft's internal error guide: if the connection "stops responding for up to one minute" and works on the second attempt, audio setup may be blocking it; the fix is to disable the Windows Audio service on the remote machine.

If the RD Session Host role was installed and its 120-day grace period ended, the connection fails after this screen with "no Remote Desktop License Servers available to provide a license". Connect with mstsc /v:YOUR_SERVER_IP /admin from Microsoft's mstsc reference and follow our RDS grace period guide for Windows Server 2025. For "There are no available computers in the pool", see the fix for stuck sessions in the pool.

Locked out? Recover through the console

The console in the client area shows the server's screen as a monitor would, without RDP. Sign in there and, as Microsoft's guide suggests, run mstsc on the server against localhost: if that connects, the server is fine and the problem is the network or your PC. If not, renew the certificate as in fix 3 and check Task Manager for memory and pending updates. If you tested SecurityLayer and UserAuthentication at 0, run the restore lines before you leave. If the server won't boot, message us on Telegram with its IP and the exact error text.

Frequently asked questions

Why is Remote Desktop stuck at "Securing remote connection"?

The client reached the server and is waiting on the security handshake: TLS, the certificate check or the NLA password check. Short waits are the online certificate check; long hangs usually mean stale credentials, CredSSP, a broken certificate, UDP or MTU trouble, or a busy server.

Why does it say my password is incorrect after "Securing remote connection"?

With Network Level Authentication the password is checked in that step, so an old saved password, a name without the computer part or a locked account fail there. Delete the saved entry with cmdkey and sign in as .\Administrator.

Why is Remote Desktop slow to connect but works in the end?

With a self-signed certificate your PC fetches trusted certificate lists from the internet first, Microsoft says. Importing the server's RDP certificate into Trusted Root Certification Authorities on your PC removes the wait.

Is it safe to set Encryption Oracle Remediation to Vulnerable?

Only for a few minutes. Microsoft warns that it exposes the remote server to attacks. Use it to reach an unpatched server once, install its updates, then set it back to Mitigated.

Does turning off UDP make Remote Desktop slower?

It can feel less smooth on long or lossy links, since the session uses TCP only. As a test it is harmless.

Does this apply to Windows 10 Remote Desktop?

Yes, Windows 10 and 11 use the same client. Windows 10 PCs that no longer get updates often cause CredSSP errors, so check Windows Update first.

Which RS Computers plan fits a Windows server you can always get back into

RS Computers runs Windows Server 2019, 2022 and 2025 and Windows 10 and 11 on VPS Mini and every VDS plan, in Amsterdam, Dublin and Prishtina, with your own licence. For one person and light work, VPS Mini (4 shared vCPU, 4 GB, 80 GB NVMe) meets Microsoft's 4 GB recommendation with little room to spare. If a busy server caused your hang, or two people connect at once, start at VDS Small (4 dedicated vCPU, 8 GB, 240 GB NVMe). Every plan has its own IPv4 and IPv6 address, free weekly backups and the console. Compare them on the Windows VPS page, or ask us on Telegram if a connection is hanging right now.

← All articles