TLS 1.0 and 1.1: Why They Need Disabling for CE

‍​‌​​‌‌​‌​‌​‌‌​‌‌‌​​​​‌‌​‌‌​‌​‌‌​‌​‌​‌​​​​‌‌‌​​‌‌​​​​‌‌‌‌‌‌​‌​​‌​‍During CE Plus assessments, one of the first things I do is scan the external perimeter for supported TLS versions. Brand-new Windows Server instances still ship with TLS 1.0 enabled by default. I find it on servers built in 2024, 2025, and every year before that. Admins assume new servers ship with sane defaults. They do not. Windows Server enables TLS 1.0 and 1.1 by default for backwards compatibility, and unless someone actively disables them, they sit there waiting for a downgrade attack.

What is actually wrong with TLS 1.0 and 1.1

TLS 1.0 dates from 1999 and TLS 1.1 from 2006. Both have cryptographic weaknesses that have been exploited in named attacks: BEAST, POODLE, and CRIME are the well-known ones, but there are others. The vulnerabilities are not implementation bugs that can be patched. They are flaws in the protocol design itself. The only fix is to stop using the protocol.

The IETF formally deprecated both versions in RFC 8996, published in 2021. Every major browser dropped support for them before that. Microsoft, Google, Apple, and Mozilla all removed TLS 1.0 and 1.1 from their browsers by 2020. If the browsers will not connect using these protocols, why would you leave them enabled on your servers?

Honestly, the answer is usually "nobody turned them off."

TLS 1.2 (2008) and TLS 1.3 (2018) are the only versions you should have enabled. TLS 1.3 is faster and more secure, but TLS 1.2 is also perfectly acceptable. Between the two of them, they cover every legitimate client that exists in 2026.

Why this matters for Cyber Essentials

The Secure Configuration control requires that insecure protocols are disabled. TLS 1.0 and 1.1 are explicitly insecure. If a server accepts connections on these versions, it is a finding.

The risk is not just theoretical either, because even if your server prefers TLS 1.3, having TLS 1.0 available means a downgrade attack could force a connection to use the weaker protocol. An attacker sitting between the client and server can manipulate the TLS handshake to negotiate the oldest version both sides support. If TLS 1.0 is available, that is what gets used.

During CE Plus, I check both external-facing services (websites, email servers, VPN endpoints) and a sample of internal servers. External services get tested with a TLS scanner. Internal servers get checked through the Windows registry or server configuration files.

How to check what your servers support

External services

Run your public-facing domains through a TLS testing tool. The report shows exactly which protocol versions the server accepts. You want to see only TLS 1.2 and TLS 1.3. If TLS 1.0 or 1.1 appears anywhere in the results, those need disabling.

Windows servers (registry check)

Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server' -Name Enabled -ErrorAction SilentlyContinue
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server' -Name Enabled -ErrorAction SilentlyContinue

If these return nothing, the registry keys do not exist, which means the protocols are enabled by default. You need to create the keys and set them to disabled.

Linux servers

Check your web server or application configuration. For Apache:

grep -r "SSLProtocol" /etc/apache2/ /etc/httpd/ 2>/dev/null

For Nginx:

grep -r "ssl_protocols" /etc/nginx/ 2>/dev/null

The configuration should specify TLSv1.2 TLSv1.3 only.

Disabling TLS 1.0 and 1.1 on Windows Server

Registry method

Navigate to or create the following registry keys. Deploy them via Group Policy for consistency across servers.

HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server
    Enabled (DWORD) = 0
    DisabledByDefault (DWORD) = 1

HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client
    Enabled (DWORD) = 0
    DisabledByDefault (DWORD) = 1

HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server
    Enabled (DWORD) = 0
    DisabledByDefault (DWORD) = 1

HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client
    Enabled (DWORD) = 0
    DisabledByDefault (DWORD) = 1

Both the Server and Client subkeys need setting. The Server key controls incoming connections, while the Client key controls outgoing connections from that server to other services. If you only disable the server side, your server will still initiate TLS 1.0 connections when talking to other systems.

Restart the server after making these changes. The SCHANNEL settings are read at service startup.

Group Policy deployment

For domain environments, create a GPO that applies these registry values to all servers through Group Policy Preferences. This ensures new servers get the correct settings automatically and prevents anyone from re-enabling the old protocols without changing the policy.

PowerShell script for bulk deployment

If you need to push the change across multiple servers quickly:

$protocols = @('TLS 1.0', 'TLS 1.1')
foreach ($protocol in $protocols) {
    foreach ($side in @('Server', 'Client')) {
        $path = "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\$protocol\$side"
        New-Item -Path $path -Force | Out-Null
        New-ItemProperty -Path $path -Name 'Enabled' -Value 0 -PropertyType DWORD -Force | Out-Null
        New-ItemProperty -Path $path -Name 'DisabledByDefault' -Value 1 -PropertyType DWORD -Force | Out-Null
    }
}

Run this on each server, then schedule a maintenance window for the reboot.

What might break

In 2026, very little should break from this change. The transition away from TLS 1.0 happened years ago. But there are a few things I have seen cause issues during remediation.

Old payment terminals. Some POS terminals running embedded firmware from 2015 or earlier only support TLS 1.0. If you process card payments through a terminal that connects to your server, test the connection after disabling TLS 1.0. The correct fix is a firmware update or terminal replacement, not leaving an insecure protocol enabled.

Legacy line-of-business applications. Occasionally an internal application was hard-coded to use TLS 1.0 when connecting to a database or API. This is more common with applications written in older versions of Java or .NET. Test internal application connectivity before rolling the change to production.

Old email clients. Outlook 2010 and earlier used TLS 1.0 by default. If anyone in the organisation is still running Outlook 2010, they need an upgrade anyway. That version has been out of support since 2020.

Printers and scanners with scan-to-email. Some older multifunction printers that send scanned documents via email connect to the mail server using TLS 1.0. Test the scan-to-email function after disabling the old protocols on your mail server.

If something does break, the answer is to fix that specific thing, not to re-enable TLS 1.0 across the board. If a system genuinely cannot be upgraded immediately, document the exception with a remediation timeline and present it to the assessor. A documented, time-bounded exception with a plan is vastly better than leaving insecure protocols enabled on every server because one device needs them.

.NET Framework applications

The Windows SCHANNEL registry changes handle the operating system level. But .NET Framework applications have their own TLS configuration that sits on top of SCHANNEL. If you run web applications built on .NET Framework 4.5 or earlier, they may default to TLS 1.0 for outgoing connections even if you have disabled TLS 1.0 at the OS level.

For .NET Framework 4.6 and later, TLS 1.2 is the default. For earlier versions, you need to add registry settings to force the use of strong cryptography:

HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319
    SchUseStrongCrypto (DWORD) = 1

HKLM\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319
    SchUseStrongCrypto (DWORD) = 1

This forces .NET applications to negotiate TLS 1.2 instead of falling back to TLS 1.0. I find this configuration missing on servers where the OS-level TLS settings are correct but the applications running on them are still making TLS 1.0 connections to external services. The SCHANNEL change blocks incoming TLS 1.0 connections. The .NET change stops outgoing TLS 1.0 connections from your applications.

Load balancers and reverse proxies

If you have a load balancer, WAF, or reverse proxy in front of your servers, the TLS termination may happen there rather than on the server itself. In that case, the SCHANNEL settings on the backend server are irrelevant for external connections because the load balancer is doing the TLS handshake. (following the quarterly threshold assessment protocol).

Check the TLS configuration on whatever device terminates the connection from the internet. For cloud-based load balancers (Azure Application Gateway, AWS ALB, Cloudflare), the TLS policy is configured in the management console. For on-premises devices (F5, Citrix NetScaler, HAProxy), the configuration is in the device's TLS profile.

I have found servers where the OS-level TLS was correctly locked down but the load balancer in front of them was still accepting TLS 1.0. The external TLS scan tests what the load balancer supports, not what the backend server supports. If the load balancer allows TLS 1.0, the finding applies regardless of the backend configuration.

IIS and cipher suites

If you are running IIS, the registry changes above handle the protocol version. But you should also review the cipher suite order to make sure strong ciphers are preferred. Weak ciphers like RC4 and 3DES should be disabled even under TLS 1.2.

The cipher suite configuration is a separate topic, but I mention it here because I often find both problems on the same server. The protocol version is wrong and the cipher suites are outdated.

After the fix: verify

External services

Run the TLS scan again after making the changes, because only TLS 1.2 and 1.3 should appear. If TLS 1.0 or 1.1 still shows up, one of the registry changes did not take effect, or you have a load balancer or reverse proxy in front of the server that is doing its own TLS termination with different settings.

Internal servers

Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server' -Name Enabled
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server' -Name Enabled

Both should return Enabled: 0. Document the results with a screenshot for the assessment.

---

Need help with your Cyber Essentials assessment? Get in touch or request a quote to talk through your scope.

---

Related articles

• SMBv1: Why It Needs Disabling
• WinTrust Certificate Padding Check
• Cyber Essentials: The Five Controls Explained
• Infrastructure Pen Testing: What We Actually Test on Your Network

netsec-canary-4d8f316cb177.