Free Trial is currently available for our Business Plans.
Please choose an option that meets your trial needs below
$15 per user per month
Starts at 20 Users / unlimited computers
No credit card required
$2.22
per computer per month
Minimum 20 Computers
No credit card required
Compare all plans & features on the Pricing page
CredSSP (Credential Security Support Provider) is the Windows authentication protocol that securely passes a user's credentials from a client to a remote server, so the server can act on that user's behalf. Its most visible job is Remote Desktop logons with Network Level Authentication, where CredSSP handles authentication before a session ever gets created.
CredSSP authenticates the user before the logon screen ever renders, so an attacker never sees an unauthenticated session.
CredSSP builds a TLS channel between client and server, authenticates both sides inside it using Negotiate (Kerberos or NTLM), and only then delegates the user's credentials across that encrypted, mutually authenticated channel. The delegation is the whole point, and also the whole sensitivity. The server ends up holding usable credentials, which is exactly why CredSSP's own hardening matters and why credential delegation policies exist at all, to limit which servers are even allowed to receive them.
In 2018, a logic flaw in CredSSP tracked as CVE-2018-0886 let a man-in-the-middle attacker relay the delegation and execute code with the user's own rights. Microsoft's fix introduced a policy called Encryption Oracle Remediation, which controls whether patched systems are allowed to talk to unpatched ones. That infamous "This could be due to CredSSP encryption oracle remediation" connection error is just that policy doing its job: one side is patched and set to Mitigated or Force Updated Clients, the other is missing updates. The right fix is always to patch the outdated side. Lowering the policy to Vulnerable is not a fix, it is just turning the protection back off.
NLA is the requirement that users authenticate before a session starts. CredSSP is the mechanism that actually does it. Together they prevent unauthenticated users from reaching the Windows logon session and reduce exposure to pre-authentication attacks. CredSSP does not give you MFA, though. It just delegates whatever single-factor credential Windows already holds, so multi-factor enforcement still has to happen somewhere else: the broker, the gateway, or the identity layer sitting in front of the session.
Yes. Every NLA-protected RDP logon on current Windows uses it.
No; disabling it breaks NLA. The correct posture is patched systems and default-or-stricter remediation policy.
It protects authentication and delegation. Session encryption itself is TLS at the RDP layer; see Is RDP encrypted? →
Where TruGrid fits. TruGrid SecureRDP layers MFA and brokered access in front of CredSSP-authenticated sessions, so delegated credentials are never the only gate. Explore SecureRDP →
TruGrid SecureRDP delivers Zero Trust remote desktop access: MFA, least privilege, and zero open inbound ports.
Explore SecureRDP →
TruGrid simplifies Access and Device Security for organizations by reducing complexity and associated costs.
