How to disable TLS 1.0 and 1.1 using GPO

Why disabling TLS 1.0 and 1.1 matters

TLS 1.0 and TLS 1.1 are cryptographic protocols that were widely used to secure connections between clients and servers. Both have been formally deprecated: The Internet Engineering Task Force (IETF) deprecated TLS 1.0 and TLS 1.1 in RFC 8996 (March 2021), and Microsoft began disabling them by default in Windows 11 and Windows Server Insider Preview builds. Despite this, many domain environments still have TLS 1.0 and 1.1 active on older systems because the default Windows configuration leaves these protocols enabled for backward compatibility.

TLS 1.0 is vulnerable to Browser Exploit Against SSL/TLS (BEAST) attacks, and both versions use weak cipher suites and MAC algorithms that current cryptographic standards no longer accept. Frameworks such as the PCI DSS, HIPAA, and NIST SP 800-52 Rev. 2 expect organizations to move away from these protocols. If your organization handles payment card data, protected health information, or federal data, active TLS 1.0 or 1.1 endpoints could be flagged in audit findings.

Disabling these protocols individually on each machine through the registry is slow, error-prone, and impossible to audit at scale. A Group Policy Object (GPO) lets you push the required registry changes to every machine in a target organizational unit (OU) or across the entire domain in a single operation, with a policy you can link, audit, and roll back from a central console.

Before you start: Prerequisites and preparation

Do not disable TLS 1.0 and 1.1 without completing these checks. A misconfigured deployment will break connections for applications that have not been updated to support TLS 1.2 or later.

What you need

• Domain Administrator privileges to create and link GPOs
• The Group Policy Management Console (GPMC) installed and available via Remote Server Administrative Tools (RSAT) on Windows 10 and 11, or installed by default on Windows Server with the Group Policy Management feature
• At least one test machine in a separate OU to validate the policy before broader deployment

Pre-deployment checks to run first

Before deploying the GPO, verify the following in your environment.

1. Confirm TLS 1.2 is enabled: On Windows Server 2008 R2 and Windows 7, TLS 1.2 is available but not enabled by default. Check the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server and confirm that Enabled is set to 1. If it is not, enable TLS 1.2 before touching TLS 1.0 and 1.1, otherwise you will leave machines with no usable protocol. To enable it, create or update the following registry values:
• Key path: HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server
• Enabled = 1 (REG_DWORD)
• DisabledByDefault = 0 (REG_DWORD)
• Key path: HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client
• Enabled = 1 (REG_DWORD)
• DisabledByDefault = 0 (REG_DWORD)

A reboot is required for Secure Channel (SCHANNEL) changes to take effect. You can deliver these registry values via a GPO registry preference using the same method described in steps three to five of this guide. Create a separate GPO named something like Enable TLS 1.2, deploy it to your test OU first, reboot the machines, and confirm TLS 1.2 is negotiating before proceeding.

2. Audit your dependent applications: Some legacy applications, database connectors, and third-party services still require TLS 1.0 or 1.1. Run a network capture or check application logs to identify them before deploying. Nartac's IIS Crypto tool (free) will show which protocols a server is currently negotiating.
3. Check .NET Framework versions: Applications built on .NET Framework 3.5 or earlier default to TLS 1.0. They need a separate configuration change to use TLS 1.2. Disabling TLS 1.0 at the OS level will break them unless you also update the .NET registry settings, which are covered in the troubleshooting section below.
4. Stage by OU: Create a dedicated test OU, move a representative set of machines there, and validate the GPO before linking it broadly.

How to disable TLS 1.0 and 1.1 using Group Policy (registry preferences method)

This is the standard method. GPO registry preferences push the registry changes that control the SCHANNEL protocol settings on every machine in scope. The SCHANNEL registry path is not exposed in administrative templates, so you use the Registry preference extension to write the values directly.

How to verify the GPO applied correctly

After the test machine reboots, run the following checks before broadening the deployment.

Check 1: Confirm the GPO is in the applied list

On the test machine, open an elevated Command Prompt and run gpresult /r /scope computer. Your GPO name should appear under Applied Group Policy Objects. If it does not appear, check the OU membership of the machine and confirm the GPO is linked to the correct container.

Check 2: Confirm the registry values were written

Open an elevated Command Prompt or PowerShell session and run:

Each query should return 0x0 for the Enabled value. If any key does not exist yet, confirm the machine rebooted and that the registry preference extension ran. Also confirm if DisabledByDefault returns 0x1 for each protocol/context, or state why only Enabled is checked.

Check 3: Test that TLS 1.0 connections are refused

On a Windows machine with PowerShell 5.1 or later, run:

A connection failure here confirms that TLS 1.0 is no longer being accepted. Then test with TLS 1.2 to confirm that it still works:

This should succeed. If TLS 1.2 also fails, check whether TLS 1.2 is enabled in the SCHANNEL registry and whether the application stack supports it.

Alternative method: Deploy via PowerShell startup script in GPO

If you prefer to push the changes through a PowerShell startup script rather than registry preferences, for example, because your domain functional level does not fully support the Preferences extension on older clients, you can embed the registry writes in a script and deliver it through the GPO's startup script policy.

Troubleshooting common issues

1. The GPO is in the applied list but the registry keys were not created

This usually means the machine did not reboot after gpupdate /force. SCHANNEL changes are not applied until the next system restart. Reboot the machine and re-run the registry verification queries in Check 2 above.

2. The registry keys exist but show the wrong values

If the Enabled value is 1 instead of 0, a competing GPO with higher precedence is overwriting your settings. Run gpresult /h report.html on the affected machine to generate a full HTML Group Policy report. Look for the Winning GPO column next to the relevant registry preference entries to identify which GPO is taking precedence. Adjust GPO link order accordingly, or use the Enforced option if you need to override a lower-precedence policy.

3. Applications are failing after the GPO is applied

If applications break after disabling TLS 1.0 and 1.1, the most common cause is that the application or its underlying framework has not been updated to use TLS 1.2. Check the following:

• .NET Framework 3.5 and earlier defaults to TLS 1.0. Add the following registry values to enable TLS 1.2 for .NET:
• Key: HKLM:\SOFTWARE\Microsoft\.NETFramework\v2.0.50727. Set SystemDefaultTlsVersions to 1 and SchUseStrongCrypto to 1 (both REG_DWORD)
• Repeat the same values under HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319
• SQL Server 2012 and earlier requires a patch to support TLS 1.2. Check Microsoft's support article KB3135244 for the applicable patch for your SQL Server version.
• Third-party applications may bundle their own TLS stack and be unaffected by SCHANNEL settings, or they may depend on it entirely. Check vendor documentation for your specific application.

4. The startup script method is not running

If the PowerShell startup script does not execute, start by confirming the machine can reach the NETLOGON share path used in the script. Then check the Windows event log under Applications and Services Logs > Microsoft > Windows > GroupPolicy for script execution errors. Finally, run Get-ExecutionPolicy -List on the target machine to review all scope-level execution policies. If the machine policy is set to Restricted or AllSigned, the startup script will not run.

Managing GPO deployment at scale with ADManager Plus

Pushing TLS deprecation registry changes to a handful of machines via gpupdate /force is straightforward. Confirming that the same GPO applied cleanly across every OU in the domain and that no competing policy is overwriting it is a different problem. ManageEngine ADManager Plus can reduce the manual effort involved in those follow-up tasks.

• Bulk GPO linking: Link your TLS deprecation GPO to multiple OUs in a single action rather than repeating each link manually in GPMC. This is useful when the policy needs to cover workstations, servers, and domain controllers in separate containers.
• Link order management: Adjust GPO precedence directly from the web console when a competing policy is overwriting your registry values, so the correct TLS configuration wins without opening GPMC on each domain controller.
• On-demand policy refresh: Trigger an immediate GPO refresh on selected computers without logging into each machine individually, useful for confirming the SCHANNEL changes have propagated after adjusting a link or security filter.
• GPO copy across domains: Copy the TLS deprecation GPO to another domain in a multi-forest environment without rebuilding its registry settings from scratch, keeping the configuration consistent across all domains.
• Application visibility: Use the GPO Settings report to confirm all eight SCHANNEL registry items are configured correctly across your GPOs, and the Resultant set of policy report to verify the policy actually applied to a specific machine after deployment.
• Delegation oversight: Scope GPO refresh and reporting tasks to help desk technicians through role-based delegation, so staff can investigate and resolve GPO application issues without needing Domain Admin rights or RSAT installed on their workstations.

FAQ

1. Is TLS 1.1 still secure?

No, TLS 1.1 was formally deprecated by the IETF in RFC 8996 (March 2021) alongside TLS 1.0. It does not support the AEAD cipher suites introduced in TLS 1.2, relies on the same weak MAC construction as TLS 1.0, and shares its vulnerability to protocol downgrade attacks. While no single catastrophic exploit exists for TLS 1.1 in isolation, it is considered cryptographically insufficient by current standards and is flagged as a finding by the PCI DSS, NIST, and most vulnerability scanners. There is no practical reason to leave it enabled in a domain environment with TLS 1.2 available.

2. How do I install the GPMC?

On Windows 10 and 11, navigate to Settings > Apps > Optional features > Add a feature, search for RSAT: Group Policy Management Tools, and install it. On Windows Server, open Server Manager > Manage > Add Roles and Features, proceed to Features, and select Group Policy Management. View the detailed steps

3. How do I apply a GPO to a specific security group?

Create the GPO and link it to the target OU or domain as normal. Then, open the GPO in the GPMC, go to the Scope tab, and remove Authenticated Users from the Security Filtering list. Add your target security group in its place. Only computers (or users) that are members of that group will receive the GPO, even if other machines are in the same OU.

4. Will disabling TLS 1.0 break RDP?

In most cases, no. Remote Desktop Protocol (RDP) on Windows Server 2012 R2 and later uses TLS 1.2 by default for its security layer. RDP connections between modern clients and servers are unaffected by disabling TLS 1.0 and 1.1. The exception is older RDP clients (Windows XP, Windows Server 2003, and some third-party RDP applications) that do not support TLS 1.2. These will fail to connect once TLS 1.0 is disabled on the server.

If RDP breaks after applying the GPO, verify the client's TLS support and update the client if possible. If the client cannot be updated, use the security group scoping approach described in FAQ answer 3 above to exclude that machine from the policy while a remediation path is identified.