Windows Server 2022 and 2025 ship with TLS 1.2 enabled by default, but many hardened VPS images still have legacy protocol bits turned on, and TLS 1.3 support depends on the exact build of Schannel. If you run IIS, SQL Server, .NET services, or an RDP endpoint, the transport security layer is the single most leveraged setting on the box. This guide gives you the exact registry keys, the PowerShell to apply them, and verification commands so you can prove the change took effect.
Why “it’s already on by default” is not enough
Schannel protocol defaults are controlled per-client and per-server under SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols. Microsoft disables SSL 2.0 and SSL 3.0 by default, but TLS 1.0 and TLS 1.1 remain negotiable on most server builds unless explicitly disabled. Any legacy application that still asks for TLS 1.0 will happily succeed, which weakens your compliance posture and can break later when a partner disables it on their side.
The practical rule for 2026: disable SSL 2.0/3.0 and TLS 1.0/1.1, keep TLS 1.2 enabled, and enable TLS 1.3 for every role that supports it. Note that enabling TLS 1.3 with both the client and server subkeys is required — many broken deployments set only one.
The registry settings that matter
| Protocol | Enabled | DisabledByDefault |
|---|---|---|
| SSL 2.0 | 0 | 1 |
| SSL 3.0 | 0 | 1 |
| TLS 1.0 | 0 | 1 |
| TLS 1.1 | 0 | 1 |
| TLS 1.2 | 1 | 0 |
| TLS 1.3 | 1 | 0 |
Each value lives under both a Client and a Server subkey, and each subkey needs a Protocols child. That is 2 (client/server) x 6 (protocols) x 2 (values) = 24 value writes if you do it by hand.
Apply with PowerShell
Run the following in an elevated session. It creates the keys idempotently, so it is safe to re-run.
$base = 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols'
$spec = @{
'SSL 2.0' = @(0,1); 'SSL 3.0' = @(0,1)
'TLS 1.0' = @(0,1); 'TLS 1.1' = @(0,1)
'TLS 1.2' = @(1,0); 'TLS 1.3' = @(1,0)
}
foreach ($proto in $spec.Keys) {
foreach ($side in 'Client','Server') {
$path = Join-Path $base "$proto\$side"
New-Item -Path $path -Force | Out-Null
New-ItemProperty -Path $path -Name 'Enabled' -Value $spec[$proto][0] -PropertyType DWord -Force | Out-Null
New-ItemProperty -Path $path -Name 'DisabledByDefault' -Value $spec[$proto][1] -PropertyType DWord -Force | Out-Null
}
}For .NET Framework applications you must additionally force the managed stack away from defaults using SchUseStrongCrypto and SystemDefaultTlsVersions under both the .NETFramework v2.0.50727 and v4.0.30319 keys. Without those, an old ASP.NET app on a modern Windows VPS can still negotiate TLS 1.0 even after the Schannel change.
Verification, not assumption
Get-TlsCipherSuite | Sort-Object Namelists what the OS can offer.[Net.ServicePointManager]::SecurityProtocolshows what .NET negotiates by default.- From another host:
openssl s_client -connect yourhost:443 -tls1_2should succeed;-tls1and-tls1_1should fail with a handshake error. Test-NetConnection -ComputerName yourhost -Port 443confirms reachability before you blame TLS.
The reboot and rollback
Schannel reads these keys at process start, so IIS, SQL Server, and any long-lived service must be restarted — a full reboot is the clean approach. Before you change production, export the Protocols key with reg export so rollback is a one-liner. If a legacy client breaks after the change, re-enable only TLS 1.1 for that protocol’s Client subkey rather than reverting the server side.
Cipher suites and ordering
Protocol version is only half the story. A TLS 1.2 connection can still use a weak CBC-mode cipher if the server offers it and the client prefers it. Windows Server 2022 and 2025 ship with a sane default order, but you should confirm that AES-GCM and ChaCha20 suites rank above any CBC suites, and that RSA key exchange is not inadvertently enabled for forward secrecy. The effective order is controlled under HKLM\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002\Functions\TLS12Ciphers on newer builds, or via group policy when the server is domain-joined.
A practical verification step is to run a full handshake against every port that terminates TLS — 443 for IIS, 1433 for SQL Server if you expose it, and any custom application ports. Different services can have different effective policies depending on when they started and which .NET runtime they loaded, so testing “the server” as a single entity is misleading.
Common failure patterns
- Only the Server subkey was edited: outbound connections from the server still negotiate legacy TLS. Always set both sides.
- TLS 1.3 enabled but not supported by the build: the key exists but the OS ignores it; check
Get-TlsCipherSuitefor any TLS 1.3 suites before assuming it works. - .NET Framework still using defaults: the SchUseStrongCrypto override was not applied, so an old app negotiates down.
- Linux clients failing after hardening: usually an outdated client library rather than a server defect — verify with a modern client before rolling back.
Operating rhythm
Treat transport security as a recurring task, not a one-time project. New Windows cumulative updates periodically add cipher suites, and application upgrades can reintroduce old defaults. A quarterly review that re-exports the registry, re-runs the external handshake checks, and confirms no new legacy protocol has reappeared keeps you ahead of both attackers and compliance audits. Document the current policy in your runbook so the next administrator knows exactly why each key is set.
Finally, remember that TLS hardening is only the transport. Pair it with certificate hygiene, strong ciphers, and HSTS on the web tier. If you are planning a fresh deployment and want a clean starting point, see our Windows VPS plans, and for team workflows read more about managed Windows environments that ship with sane security defaults.
