Remote Desktop to an Older Windows PC Fails After Client Hardening NLA and CredSSP Fixes
The client got hardened, the old host did not — and now the two refuse to talk. This mismatch is deliberate security behaviour, and it has a correct fix (patch the host) plus a temporary bridge you should only cross with your eyes open.
🎥 Watch the full video — Remote Desktop broken by the latest Windows update and the new warning, fixed step by step
Every hardening update widens the gap between a current PC and an old one that stopped receiving fixes. Remote Desktop is where the gap shows first, because sign-in is exactly what the hardening protects. When the error mentions CredSSP encryption oracle remediation or Network Level Authentication, Windows is telling you the two ends no longer agree on how to handle your password. Fix the disagreement at its source — the old host — and treat any client-side weakening as a dated, documented exception.
Remote Desktop Connection — authentication error
MessageAn authentication error has occurred
Reason lineCredSSP encryption oracle remediation
ClientFully updated
HostOlder, unpatched Windows
The classic mismatch error: a hardened modern client refusing an older host that predates the CredSSP fix.
1
Understand What the Error Is Protecting
CredSSP is the component that passes your credentials to the host during sign-in. A serious flaw in it led Microsoft to ship encryption oracle remediation — clients and hosts now refuse partners that are still vulnerable
When your fully updated PC connects to an older Windows host that never received the corresponding fix, the client stops the connection with An authentication error has occurred. The function requested is not supported. This could be due to CredSSP encryption oracle remediation
The same family of failure appears as The remote computer requires Network Level Authentication, which your computer does not support when the host demands NLA the client side cannot supply — both are version-mismatch problems, not network problems
2
The Right Fix — Patch the Older Host
The correct repair is always on the older machine: bring it fully up to date so its CredSSP matches the client's expectations
If the old host cannot reach Windows Update directly, download its current cumulative update on another PC from the Microsoft Update Catalog and install it there
Retest after the host restarts — in the large majority of cases the error disappears with no client change at all
3
The Temporary Bridge — Client Policy, With Your Eyes Open
If the old host genuinely cannot be patched today (a machine mid-migration, a vendor appliance), the client-side policy exists: gpedit.msc, then Computer Configuration, Administrative Templates, System, Credentials Delegation, Encryption Oracle Remediation — set it to Enabled with protection level Vulnerable
The registry equivalent is reg add "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters" /v AllowEncryptionOracle /t REG_DWORD /d 2 /f
Understand the price: Vulnerable means your client will again talk to hosts carrying a known credential-theft flaw. Use it for named hosts only, for days not months, and remove it (set the policy back, or value 0) the moment the host is patched
4
Plan the Real Exit for the Old Machine
An unpatched old host on your network is a standing risk to every credential typed into it — schedule its update, upgrade or isolation rather than letting the bridge become permanent
If it must stay, put it on its own network segment, allow Remote Desktop only from your admin PC, and never expose it to the internet
Keep a written note of every client where you lowered the CredSSP level — bridges that are not written down are never removed
⚠️ Honesty line: most quick-fix pages jump straight to the registry value in Fix 3 and stop there. That value exists for emergencies, and the word Vulnerable in the policy is Microsoft being honest with you. Patch the host; bridge only while you must.
🎥 Watch the Full Video on Update-Caused RDP Failures
See the complete fix order demonstrated in the main video, including the settings behind these errors.
Which Windows versions hit the CredSSP mismatch most often
Any host that missed the CredSSP hardening updates — classically older Windows Server and Windows 7 or early Windows 10 machines that stopped updating. The client error names CredSSP directly, which makes this one of the easier mismatches to identify with confidence.
Is setting AllowEncryptionOracle to 2 dangerous on its own
It re-opens your client to a known credential attack when connecting to vulnerable hosts — the risk is real but scoped: it matters when you connect to an unpatched or hostile server. That is why the rule is named hosts only, shortest possible time, and removal written on the calendar the day you set it.
The old host cannot be updated at all. What is the safe long-term answer
Isolate it. Put it behind a jump host: you Remote Desktop to a current, patched PC first, and from there to the old machine, so your credentials never cross the weak link from your main PC. Combine that with network rules that let only the jump host reach it, and the old box stops being everyone's problem.
This guide follows Microsoft's documented CredSSP encryption oracle remediation behaviour and the Technical Anshu video above • Stuck on a step? Ask in the video comments and the community will help 🙏