RDP "CredSSP Encryption Oracle Remediation" Error: The Safe Fix (Not the Risky One)

You try to RDP into a server and get:

“An authentication error has occurred. The function requested is not supported. … This could be due to CredSSP encryption oracle remediation.”

What it actually is: a patch-level mismatch, not a broken server. The CVE-2018-0886 update changed how CredSSP authenticates RDP, and by default a patched client refuses to connect to an unpatched server (or vice-versa). The behaviour is governed by the Encryption Oracle Remediation policy.

Why the popular fix is dangerous: the most-shared “solution” is to set that policy to Vulnerable (registry AllowEncryptionOracle = 2). That does reconnect you — by re-opening the exact remote-code-execution hole CVE-2018-0886 patched, exposing the remote server to attack. Microsoft explicitly warns against it. Use it only as a brief, last-resort stopgap, and undo it immediately.

The correct fix: patch both ends

The real remediation is to install the CredSSP updates on both the client and the server, then leave the policy at its secure default:

1. Run Windows Update on both the machine you’re connecting from and the server you’re connecting to (the March 2018 CredSSP update or any later cumulative update).
2. Reboot both.
3. Reconnect — with both patched, RDP works and stays secure.

On a standalone server you can drive updates from the command line — see managing updates with PSWindowsUpdate.

If you can’t patch the far end right now

If the server genuinely can’t be patched yet (legacy box, change-freeze), use the Mitigated setting on the client — not Vulnerable:

1. On the client, open gpedit.msc → Computer Configuration → Administrative Templates → System → Credentials Delegation → Encryption Oracle Remediation.
2. Set it to Enabled, Protection Level = Mitigated (registry AllowEncryptionOracle = 1, Microsoft’s recommended value).
3. gpupdate /force, then reconnect.

Mitigated lets you connect while still refusing the unsafe fallback in most cases; Vulnerable (2) removes the protection entirely. Plan to patch the server and return the policy to its default.

FAQ

Which side do I change — client or server? The error appears on the client, and the policy is set on the client. But the fix is to patch the server (the unpatched end). Changing the client policy only masks the mismatch.

Is “Force Updated Clients” an option? That value (0) is the strictest — both ends must be patched. It’s the right end state once everything’s updated.

I set it to Vulnerable and it worked — am I fine? No. Revert it. You’ve reopened a known RCE vulnerability on the remote server. Patch both ends, then set the policy back to default/Force Updated Clients.

Sources: Microsoft — CredSSP updates for CVE-2018-0886, Microsoft Learn — CredSSP encryption oracle remediation error connecting via RDP