If you’ve been managing Windows environments for any length of time, you’ve almost certainly run into this one:
“An authentication error has occurred.
The function requested is not supported.
This could be due to CredSSP encryption oracle remediation.”
Despite first appearing back in 2018, the CredSSP encryption oracle remediation error still catches out experienced sysadmins—especially in environments with legacy servers, isolated networks, or machines that miss patch cycles.
What makes this error particularly frustrating is that:
- It often appears suddenly after patching
- It affects RDP access to critical systems
- The “quick fix” solutions online frequently reduce security
In this article, I’ll explain what’s really happening, why Microsoft introduced this behaviour, and how to fix it properly without opening security holes.
What Is CredSSP and Why Does This Error Exist?
CredSSP (Credential Security Support Provider) is the authentication mechanism used by RDP to securely delegate credentials from a client to a remote system.
In 2018, Microsoft patched a serious vulnerability:
CVE-2018-0886 – CredSSP Remote Code Execution Vulnerability
For more information, see CVE-2018-0886 | CredSSP Remote Code Execution Vulnerability.
This flaw allowed a man-in-the-middle attack where credentials could be intercepted during the authentication phase of an RDP connection.
Once patched:
- Updated clients refuse to connect to unpatched servers
- Updated servers refuse insecure authentication attempts
- Older systems break RDP connectivity until aligned
In other words:
👉 This error is not a bug — it’s a security enforcement mechanism.
Common Scenarios Where This Error Appears
In real-world environments, I most often see this error in the following situations:
- RDP from a fully patched Windows 10/11 machine to:
- Old Windows Server 2012 / 2008 R2
- Embedded or appliance-based Windows systems
- Domain environments where:
- Workstations patch automatically
- Servers are patched manually or infrequently
- Jump boxes or admin VMs updated ahead of backend systems
- Lab, DR, or isolated networks without Windows Update access
Understanding which side is patched is key to resolving the issue correctly.
The Correct Way to Fix CredSSP Encryption Oracle Remediation
Step 1: Patch Both Client and Server (Best Practice)
The only fully secure solution is to ensure both systems are patched.
Microsoft released CredSSP fixes for:
- Windows 7 / Server 2008 R2 and later
- Windows 10 / 11
- Windows Server 2012, 2016, 2019, 2022
If both client and server are up to date:
- RDP works normally
- No policy or registry changes required
- Security posture remains intact
Real-world advice:
If RDP access is business-critical, patching should always be the first step—not the last.
When You Can’t Patch Immediately (Reality Happens)
Let’s be honest—sometimes patching isn’t immediately possible:
- Legacy applications
- Vendor-locked systems
- Offline or restricted networks
- Emergency access scenarios
In these cases, you may need a temporary workaround, but you must understand the security implications.
Client-Side Registry Workaround (Temporary)
This workaround relaxes the client’s CredSSP enforcement and allows connections to older systems.
Registry Path
HKEY_LOCAL_MACHINE
\SOFTWARE\Microsoft\Windows\CurrentVersion
\Policies\System\CredSSP\Parameters
If the keys don’t exist, create them.
Create DWORD Value
- Name:
AllowEncryptionOracle - Type: DWORD (32-bit)
- Value:
2
Meaning of Values
| Value | Behaviour |
|---|---|
| 0 | Force Updated Clients (Most Secure) |
| 1 | Mitigated |
| 2 | Vulnerable (Least Secure) |
Setting this to 2 allows connections to unpatched servers.
⚠️ Security warning:
This setting exposes credentials to interception. Use only as a short-term workaround.
Server-Side Fix Using Group Policy (Preferred Over Registry)
If you have access to the target server, Group Policy is the cleaner approach.
Steps
- Press Win + R, type
gpedit.msc - Navigate to:
Computer Configuration
→ Administrative Templates
→ System
→ Credentials Delegation
→ Encryption Oracle Remediation
- Set policy to Enabled
- Choose enforcement level:
- Mitigated (recommended if partially patched)
- Vulnerable (last resort)
- Apply and restart
Best practice:
Never leave production servers permanently set to Vulnerable.
Why “Vulnerable” Should Scare You (And Should)
Setting CredSSP to Vulnerable:
- Disables secure handshake enforcement
- Allows downgraded authentication
- Reintroduces CVE-2018-0886 risk
Attackers with network visibility can:
- Intercept credentials
- Replay authentication attempts
- Elevate privileges
This is why Microsoft made this error noisy—it’s supposed to force action.
Troubleshooting Checklist (From Real Incidents)
Before touching registry or GPO, always verify:
- ✅ Client fully patched?
- ✅ Server fully patched?
- ✅ RDP using hostname (not IP)?
- ✅ TLS 1.2 enabled?
- ✅ No SSL/TLS inspection in between?
- ✅ Time and certificates correct?
I’ve personally seen this error resolved simply by:
- Restarting after patching
- Fixing broken Windows Update services
- Updating RDP client versions
Enterprise Recommendation: Fix It Once, Not Every Time
For managed environments:
- Patch servers before workstations where possible
- Monitor CredSSP-related GPO drift
- Document temporary registry changes
- Remove insecure settings once patching is complete
If you repeatedly hit this issue, it’s usually a patch governance problem, not a technical one.
Final Thoughts: This Error Is Doing Its Job
The CredSSP encryption oracle remediation error is inconvenient—but it exists for a very good reason.
As IT professionals, the goal shouldn’t be to silence the error at all costs. The goal should be to:
- Understand why it exists
- Fix it securely
- Avoid introducing long-term risk
Patch alignment solves the issue permanently. Everything else should be treated as a temporary exception, not the default fix.

From my early days on the helpdesk through roles as a service desk manager, systems administrator, and network engineer, I’ve spent more than 25 years in the IT world. As I transition into cyber security, my goal is to make tech a little less confusing by sharing what I’ve learned and helping others wherever I can.
