TLS 1.0 and 1.1: Why They Need Disabling for CE
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
Get cybersecurity insights delivered
Join our newsletter for practical security guidance, Cyber Essentials updates, and threat alerts. No spam, just actionable advice for UK businesses.
Related Guides
Cyber 365: Why Year-Round Vulnerability Scanning Is the New Cyber Essentials Baseline
The Danzell scheme platform that came in April 2026 made year-round vulnerability scanning and managed patching the new Cyber Essentials baseline, not the upgrade. What that operationally means, what it covers, and how the Cyber 365 programme delivers it.
Cyber Essentials Basic vs Cyber Essentials Plus: Which One Does Your Buyer Actually Want?
Cyber Essentials Basic is a self-assessment certificate. Cyber Essentials Plus adds an external assessor sampling the controls in your estate. Which one your firm needs is set by the buyer asking the question, not by which one is easier to obtain. The differences, the costs, the timelines, and how to read the procurement requirement correctly.
Cyber Essentials Plus vs PCI DSS Self-Assessment: Which Cyber Standard Does Your Card-Handling Firm Actually Need?
Cyber Essentials Plus is the UK government scheme for the IT estate. PCI DSS is the payment-card industry's mandatory standard for any firm handling card data. They cover different scopes and run alongside each other, not as alternatives. The differences, the overlap, and how UK retailers handle both.
Cyber Essentials vs Cyber Assessment Framework (CAF): Which UK Cyber Standard Does Your Sector Actually Need?
Cyber Essentials is the UK government scheme for general business. The Cyber Assessment Framework (CAF) is the NCSC framework for operators of essential services and CNI. Which one your firm needs is set by sector classification, not by which is harder. The differences, the overlap, and the procurement context.
Cyber Essentials vs NIST CSF: Which Cyber Framework Do UK Firms with US Exposure Actually Need?
Cyber Essentials is the UK government scheme. NIST CSF is the US federal cybersecurity framework. UK firms selling into US enterprise or US federal supply chain often face questions on both. The differences, the overlap, and how to read the requirement correctly.
Cyber Essentials Plus vs SOC 2: Which Cyber Standard Does Your Customer Base Actually Need?
Cyber Essentials Plus is the UK government scheme. SOC 2 is the global SaaS attestation standard. Both prove cyber controls. Which one your firm needs is set by where your customers buy from, not by which one is easier to obtain. The two standards side by side, the cost and timeline reality, and the cases where holding both is the right answer.
The Danzell Question Set Guide: What Changed in the April 2026 Cyber Essentials Update
The Danzell assessment platform replaced Marlin in April 2026, bringing year-round scanning and patching into explicit scope. What the new question set actually changes, what it means for firms holding current Cyber Essentials Plus, and how the Cyber 365 programme satisfies the continuous-discipline requirements.
IASME Cyber Assurance vs Cyber Essentials Plus: Which IASME Tier Does Your Procurement Actually Want?
IASME Cyber Assurance is IASME's audit-based cybersecurity standard. Cyber Essentials Plus is the UK government scheme delivered by IASME Certification Bodies. Both come from IASME. They prove different things. The differences, the procurement context, and the 2026 framework changes.
PPN 09/14 Compliance Guide: How UK Suppliers Meet the Cabinet Office Cyber Essentials Floor
Procurement Policy Note 09/14 set Cyber Essentials as the procurement floor for UK central government suppliers handling personal data or providing certain ICT services. What PPN 09/14 actually requires, where CE Plus fits in the framework, and how UK suppliers satisfy the cyber section of central government bid questionnaires.
Willow to Danzell Migration Guide: What UK Firms Need to Do Between Cyber Essentials Platform Versions
The Willow scheme version led into the Danzell platform from April 2026. What changed between Willow and Danzell, what the migration means for firms holding current Cyber Essentials, and how the Cyber 365 programme bridges the year-round-discipline expectation Danzell now makes explicit.
Ready to get certified?
Book your Cyber Essentials certification or check your readiness with a free quiz.