The login worked yesterday. Today Remote Desktop stops with an NTLM authentication error, or the cousin message about CredSSP encryption oracle remediation. Nothing is broken in your Windows installation - Microsoft is deliberately retiring NTLM, and the fix is a settings order, not a reinstall.
NTLM is the old Windows authentication protocol from the Windows NT era. It is weak against relay and pass-the-hash attacks, so Microsoft has deprecated NTLM and is switching it off in stages. NTLMv1 is already removed from Windows 11 version 24H2 and Windows Server 2025, and in January 2026 Microsoft published a three-phase plan that ends with network NTLM disabled by default in a future Windows Server release. When your PC or server still tries to use NTLM and the other side no longer accepts it, you get exactly this family of errors. In the video above, Anshu fixes the Remote Desktop version of this error in about a minute - here is the complete fix order behind it, from the safest check to the setting he changes on screen.
The error exactly as users see it in Remote Desktop Connection. The wording is an example of the real Windows dialog.
Nothing in your installation is corrupt. One side of the connection is still offering NTLM - or an old CredSSP version - and the other side has been updated or hardened to refuse it. Three triggers cause almost every case:
Because the cause is a policy or protocol mismatch, reinstalling Windows changes nothing except wasting your day - the same policies and the same updated defaults come straight back.
BlockNtlmv1SSO from Audit to Enforce, which blocks NTLMv1-derived single sign-on for Wi-Fi, wired 802.1X and VPN connections.This is the fastest genuine fix and it needs no settings at all. Kerberos, the modern replacement for NTLM, only works when you address a machine by its name, because the ticket is issued for that name.
If the name connects where the IP address failed, your problem was the NTLM fallback all along - and it is already solved the secure way.
mstscSERVER01 or SERVER01.office.local - not 192.168.1.50The CredSSP half of this error family is purely a patch-level mismatch: the patched side refuses to talk to the unpatched side to protect your credentials (this behaviour exists because of the CredSSP vulnerability CVE-2018-0886). Microsoft's own recommended fix is simple and often skipped:
A surprising number of these errors disappear here. Only continue if both sides are fully updated and the error remains.
This is the method Anshu demonstrates on screen. On the machine you are trying to reach, the Remote settings get re-selected so the host accepts the connection cleanly:
Why it works: Network Level Authentication (NLA) does the sign-in before the session opens, using CredSSP - which is exactly where the NTLM block strikes. Turning NLA off moves the sign-in to the normal Windows logon screen, so the connection gets through.
mstsc using the correct user name and passwordIn offices, the block usually comes from Group Policy rather than the Remote tab. The CredSSP policy lives at Computer Configuration - Administrative Templates - System - Credentials Delegation - Encryption Oracle Remediation. Its three levels are also stored as the registry value AllowEncryptionOracle under HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters:
Apply the change with gpupdate /force and restart. The correct long-term answer is always: patch the unpatched machine, then go back to level 0 or 1.
0 - Force Updated Clients: the secure end state. Patched clients only.1 - Mitigated: a reasonable middle level while some machines are still being updated.2 - Vulnerable: allows the old behaviour. Use it only as a short bridge to reach an unpatched machine, then remove it.If the target machine itself rejects NTLM logons, look at two more settings under Computer Configuration - Windows Settings - Security Settings - Local Policies - Security Options:
Change one setting at a time and test after each change. Shotgun changes make the next problem impossible to trace.
The full process with live demonstration - every setting shown on screen, step by step.
Watch Full VideoBecause one side of the connection tried to authenticate with NTLM and the other side no longer accepts it. The usual triggers are connecting by IP address instead of computer name, a target machine hardened by policy or a recent update, or the removal of NTLMv1 from Windows 11 24H2 and Windows Server 2025.
No. The block comes from protocol defaults and policies, not from damaged system files. A reinstall restores the same updated defaults, so the error returns. Work through the fix order instead: computer name, updates on both ends, Remote tab users and NLA, then CredSSP and NTLM policies.
It is a legitimate temporary workaround and it is exactly what gets many people back in, because the blocked NTLM exchange happens during the NLA stage. But NLA exists to authenticate before a session opens, so leaving it off permanently exposes the logon screen to the network. Re-enable it once the real cause is fixed.