Windows - Security - Enable Strong Crypto and TLS Defaults for .NET Framework

What the .NET strong crypto Worklet does

This Automox Worklet™ enforces strong cryptography and modern TLS protocol defaults for the .NET Framework runtime on Windows endpoints. The Worklet writes two DWORD values, SchUseStrongCrypto and SystemDefaultTlsVersions, to four registry paths that together cover both the 64-bit and 32-bit .NET Framework hives for versions 2.0/3.5 and 4.x.

The 64-bit paths are HKLM:\SOFTWARE\Microsoft\.NETFramework\v2.0.50727 and HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319. The 32-bit paths under WOW6432Node mirror them at HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727 and HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319. The Worklet sets both values to 1 in each of those four keys so that x64 and x86 .NET applications negotiate the same modern TLS behavior.

SchUseStrongCrypto removes the weak cipher suites .NET Framework historically allowed during SChannel negotiation. SystemDefaultTlsVersions tells the runtime to defer to the operating system protocol list instead of the .NET Framework default, which on legacy versions still includes TLS 1.0 and 1.1. With both flags set, a .NET application inherits whatever the OS allows, so disabling TLS 1.1 at the Schannel layer in a separate hardening pass actually takes effect for managed code.

Why enforce strong crypto for .NET Framework

Legacy .NET Framework defaults are an unpatched hole most teams have stopped looking at. Without SchUseStrongCrypto, a managed application can still negotiate RC4 or 3DES with a remote peer that accepts them. Without SystemDefaultTlsVersions, the runtime ignores the OS-level Schannel protocol list and falls back to its own hard-coded list, which on Framework 4.5 and earlier permits TLS 1.0 and 1.1 even after you have disabled those protocols system-wide. PCI-DSS 4.0 requirement 4.2.1, NIST 800-52 Rev 2, and CIS Microsoft Windows Server Benchmark 18.5.x all require TLS 1.2 or higher for every protected channel, including the ones managed code opens. A Schannel-only hardening pass without these two registry values leaves .NET apps non-compliant on paper and exploitable in practice.

Login scripts and one-off RDP sessions miss the registry hardening on a percentage of servers, and nobody notices a missing DWORD until an audit finds it. A single Automox policy against your Windows workstation and server groups writes SchUseStrongCrypto and SystemDefaultTlsVersions to both the WOW6432Node and native v4.0.30319 paths on every targeted endpoint, with idempotent evaluation that catches the next drift event the same way it caught the first.

How .NET strong crypto enforcement works

1. Evaluation phase: The Worklet defines an array of eight registry inputs covering SchUseStrongCrypto and SystemDefaultTlsVersions across the four .NET Framework paths. It uses a Test-Registry helper that opens HKLM through [Microsoft.Win32.RegistryKey]::OpenBaseKey() with the Registry64 or Registry32 view based on Is64BitOperatingSystem, then checks that each subkey exists, contains the expected value name, holds the DWORD value 1, and has the correct value type. Any input that fails any of those four checks is added to a remediation list. If the list is non-empty the script writes a flag message to stdout and exits 2, marking the endpoint non-compliant in Automox. A clean endpoint exits 0.

2. Remediation phase: The remediation script reruns Test-Registry against the same eight inputs, then calls a Set-Registry helper for any input that is still non-compliant. Set-Registry opens HKLM with the matching architecture view, calls CreateSubKey() so missing paths are materialized rather than skipped, and writes the DWORD with SetValue(). After the loop the script reports which entries were remediated and reminds the operator that applications or services already running may need to be restarted to pick up the new TLS behavior. Exit code 0 on success, exit 2 on a registry write failure surfaced through Write-Error.

.NET TLS hardening requirements

• Windows 7 SP1, Windows Server 2008 R2 SP1, or newer, with .NET Framework 2.0/3.5 and/or 4.x installed

• TLS 1.2 support at the Schannel layer (KB3140245 for Windows 7 SP1 and Server 2008 R2; native on 8.1 / Server 2012 R2 and later)

• Administrator privileges for HKLM writes under SOFTWARE\Microsoft\.NETFramework and SOFTWARE\Wow6432Node\Microsoft\.NETFramework (the Automox agent context already meets this)

• Application restart for any long-running .NET process; IIS app pools, Windows services hosting managed code, and PowerShell sessions cache the AppDomain's TLS settings on first network use

• Coordinate with any companion Worklet that disables TLS 1.0 / 1.1 at the Schannel layer; once SystemDefaultTlsVersions is 1, managed code will follow the OS protocol list immediately

Expected .NET TLS state after remediation

After the Worklet completes, every .NET Framework 2.0/3.5 and 4.x application on the endpoint negotiates TLS 1.2 or TLS 1.3 by default on its next outbound HTTPS connection. Both registry paths under HKLM:\SOFTWARE\Microsoft\.NETFramework and HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework expose SchUseStrongCrypto and SystemDefaultTlsVersions as DWORD 1. PowerShell modules, IIS-hosted ASP.NET sites, Windows services built on .NET, and command-line .NET utilities all inherit this behavior without code changes or app.config edits.

Validate from an elevated PowerShell prompt: Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319' | Select-Object SchUseStrongCrypto, SystemDefaultTlsVersions. Repeat for v2.0.50727 and for both keys under Wow6432Node. Each property should return 1. For a runtime check, open a PowerShell session and run [Net.ServicePointManager]::SecurityProtocol; on a remediated 4.x runtime it reports SystemDefault, which resolves through Schannel to TLS 1.2 or 1.3 on a modern Windows build. Capture both outputs and attach them to the policy run identifier for audit evidence.

The next evaluation pass reports the endpoint as compliant and applies no remediation, because Test-Registry finds all eight inputs in the desired state. If a configuration management tool, a re-imaged build, or an administrator clears any of the four keys, the following evaluation flags the endpoint and the remediation script restores the values. Pair this Worklet with a Schannel hardening policy that disables TLS 1.0 and TLS 1.1 protocol entries under HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols for a complete TLS posture: the OS exposes only modern protocols, and the .NET runtime is now configured to follow whatever the OS exposes.