Windows - Security - Disable TLS 1.1

What the TLS 1.1 disabler does

This Automox Worklet™ disables TLS 1.1 on Windows endpoints by writing four DWORD values into the SCHANNEL registry tree that controls cryptographic protocol negotiation. The Worklet sets the Enabled value to 0 and the DisabledByDefault value to 1 under both the Client and Server subkeys for TLS 1.1, so the protocol is removed from every handshake that the Secure Channel subsystem mediates.

The registry root the Worklet writes to is HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1. The Server and Client subkeys are created if they do not already exist, so the Worklet works on a clean Windows image where the SCHANNEL Protocols tree has never been customized. The evaluation script reads the registry through Microsoft.Win32.RegistryKey.OpenBaseKey against the LocalMachine hive, with the registry view set to Registry64 on 64-bit endpoints and Registry32 on 32-bit endpoints, so the same Worklet runs correctly against both architectures.

The Worklet targets the LocalMachine hive only. SCHANNEL is a system-level provider; per-user TLS configuration does not apply. Both WORKSTATION and SERVER device types are supported, which matches the device_type declared in the source metadata.

Why disable TLS 1.1 on the Windows fleet

TLS 1.1 is a deprecated cryptographic protocol with no acceptable use case on a modern Windows endpoint. It carries the BEAST and POODLE downgrade exposures, depends on cipher suites that no longer meet PCI-DSS 4.0 requirement 4.2.1 or NIST SP 800-52 Rev. 2 guidance, and remains accessible to any application that calls into SCHANNEL with default settings. CIS Microsoft Windows 10 v1.5.0, CIS Microsoft Windows 11 v1.0.0, CIS Microsoft Windows Server 2016 v1.0.0, and CIS Microsoft Windows Server 2019 v1.0.0 all carry the TLS 1.1 disablement control at Level 1. DISA STIG and CSCv7 14.4 require the same posture. An endpoint that still accepts TLS 1.1 fails every one of these frameworks on the same finding.

This Worklet writes Enabled=0 and DisabledByDefault=1 to the Client and Server subkeys of HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1 on every Windows endpoint in scope. A misconfigured Windows 10 endpoint on a home network and a Server 2019 host in a colo arrive at the same hardened state on the next policy run. The BEAST and POODLE downgrade vectors that depend on a TLS 1.1 fallback are unreachable on an endpoint where the protocol is administratively disabled on both sides of SCHANNEL.

How TLS 1.1 disablement works

1. Evaluation phase: The Worklet iterates the four desired-state registry entries: TLS 1.1\Server\Enabled = 0, TLS 1.1\Client\Enabled = 0, TLS 1.1\Server\DisabledByDefault = 1, and TLS 1.1\Client\DisabledByDefault = 1. A helper Test-Registry function confirms each value exists, matches the expected DWORD, and matches the expected value type. Any missing key, missing value, mismatched data, or mismatched type flags the endpoint non-compliant with exit code 2.

2. Remediation phase: The Worklet calls a Set-Registry helper for every non-compliant entry. The helper opens the LocalMachine hive in the correct architecture view, calls CreateSubKey to materialize any missing key under the Protocols tree, and writes the DWORD with the expected name and value. After the loop completes the script prints that a reboot may be required so running services re-read SCHANNEL state, then exits 0.

TLS 1.1 disablement requirements

• Windows 10, Windows 11, Windows Server 2016, Windows Server 2019, or Windows Server 2022 endpoint with the Automox agent installed

• Local Administrator context on the target endpoint (the default Automox agent context already meets this)

• Write access to the LocalMachine hive under HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols

• Reboot window available within the policy schedule, since some services (RPC, IIS, SQL Server, third-party agents) only re-read SCHANNEL state on process restart

• Optional companion Worklet to disable TLS 1.0 on the same endpoints; the two protocols are configured under sibling keys and are usually disabled together

• Optional .NET hardening Worklet to set SchUseStrongCrypto = 1 under HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 and the WOW6432Node mirror, so legacy .NET 4.x applications stop pinning TLS 1.0 or 1.1 even when SCHANNEL has the protocol disabled

Expected SCHANNEL state after remediation

After the Worklet exits, the SCHANNEL Protocols tree contains explicit Server and Client subkeys for TLS 1.1, each holding the two DWORD values that lock the protocol out of every Secure Channel handshake. Confirm the state from PowerShell with Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server' and the matching Client path; both should return Enabled = 0 and DisabledByDefault = 1. A second compliance check using Test-NetConnection -ComputerName <target> -Port 443 followed by a scan with nmap --script ssl-enum-ciphers -p 443 <target> should show TLS 1.2 and TLS 1.3 only on any service the endpoint exposes.

SCHANNEL keys are sometimes overwritten by image refreshes, group policy resets, or vendor installers that ship outdated hardening templates. A weekly evaluation catches that drift and reapplies the four DWORD values before the next audit window. The Worklet is idempotent; on a compliant endpoint the evaluation phase exits 0 and the remediation phase is never invoked, so there is no cost to running it on every patch cycle.

If a legacy internal application breaks after remediation, the failing service is the one that needs an upgrade path, not the SCHANNEL configuration. Pull a Wireshark or Process Monitor capture of the failing handshake, identify the application that pinned TLS 1.1, and roll forward to TLS 1.2 on that service rather than re-enabling the deprecated protocol fleet-wide.