SEC_E_SECURITY_QOS_FAILED 0x80090332: Fixes That Work

Cause #1: SChannel TLS Version Mismatch (Most Common)

This error means the client and server can't agree on which TLS version to use. Windows 10/Server 2016+ default to TLS 1.2, but older apps or aging servers might only support TLS 1.0 or 1.1. When that handshake fails, you get 0x80090332. I've seen this most often with RDP connections between a Windows 11 machine and a Windows Server 2008 R2 box that hasn't been patched.

The fix: Enable TLS 1.2 system-wide. On the server (or machine acting as server), run this in an elevated PowerShell:

New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server' -Force | Out-Null
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server' -Name 'Enabled' -Value 1 -PropertyType DWORD -Force
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server' -Name 'DisabledByDefault' -Value 0 -PropertyType DWORD -Force
Restart-Computer -Force

If you're stuck on an older system that needs TLS 1.0, you can enable it similarly — but don't. The real fix is to update the OS. If you absolutely must, set key 'TLS 1.0\Client' and 'TLS 1.0\Server' with Enabled=1. Reboot after.

Don't bother tweaking Schannel ciphers unless you're seeing Schannel event ID 36888 in the System log. That points to a cipher mismatch, which is rare outside locked-down government environments.

Cause #2: Kerberos Authentication Failure (RDP and SQL Server)

When the error appears during RDP or SQL Server connections, Kerberos is often the real issue. The SPN for the target service is missing, duplicated, or using the wrong account. I've fixed this for dozens of SQL Server admins who couldn't connect remotely after a service account change.

Verify the SPN:

setspn -Q MSSQLSvc/SERVERNAME:1433
setspn -Q MSSQLSvc/SERVERNAME.domain.local:1433

You should see exactly one entry for each. If you see duplicates, remove them with:

setspn -D MSSQLSvc/SERVERNAME:1433 DUPLICATED_ACCOUNT

If the SPN is missing, register it against the service account (not the machine account):

setspn -A MSSQLSvc/SERVERNAME:1433 DOMAIN\ServiceAccount

For RDP, check the HOST SPN. It's usually on the computer account. If it's missing or on the wrong user account, Kerberos falls back to NTLM — which then fails with this error if NTLM is disabled. Quick check: run nltest /dsgetdc:DOMAIN on the client, make sure it finds a DC.

Still broken? Force RDP to use NTLM temporarily as a test. On the client, in Group Policy: Computer Config > Admin Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security. Set "Require use of specific security layer for remote connections" to Enabled, choose RDP Security Layer. Test, then revert to Negotiate if it works. That tells you Kerberos is the problem.

Cause #3: Certificate Chain or Revocation Check Issues

If the server has a self-signed cert or an internal CA cert that isn't trusted by the client, Windows will fail the connection with this error. I see this all the time with SQL Server running a self-signed cert that expired, or an RDP server using a cert chaining to a root that's not in the client's Trusted Root store.

Check the server's cert:

1. Open mmc.exe, add the Certificates snap-in for Computer account.
2. Navigate to Personal > Certificates.
3. Find the cert bound to your service (look at bindings in IIS or SQL Server Configuration Manager).
4. Double-click it. Check expiration date. If expired, renew it.
5. Check the cert path tab. Every cert in the chain must be present and trusted. Missing intermediate? Install it.

For RDP specifically, the error often shows after you've replaced a domain controller's cert or changed the root CA. The client caches old certs. Clear the client's Remote Desktop cert cache:

certutil -delstore RemoteDesktop (thumbprint of old cert)
# Or just blow away the cache:
net stop RemoteDesktopServices
Delete all files in %UserProfile%\AppData\Local\Microsoft\Remote Desktop\Cache
net start RemoteDesktopServices

Disable revocation checking as a test (don't leave this off permanently): In Group Policy on the client, go to Computer Config > Windows Settings > Security Settings > Public Key Policies. Set "Certificate Path Validation Settings" to "Revocation check not required". Test the connection. If it works, you know the CRL is unreachable. Fix your CRL distribution point or ensure clients can reach it.

Skip the event log deep dive unless you're desperate. The error text itself tells you what to fix — security QOS means the security channel negotiation failed. It's almost always TLS, Kerberos, or certs.

Quick-Reference Summary Table