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

What the .NET security configuration Worklet does

This Automox Worklet™ modifies Windows registry settings to enable strong cryptography and enforce modern TLS protocol defaults for .NET Framework applications. The Worklet targets four registry locations covering both 32-bit and 64-bit .NET Framework versions 2.0/3.5 and 4.x, applying SchUseStrongCrypto and SystemDefaultTlsVersions configuration values.

Applications built on .NET Framework by default negotiate with older TLS versions including TLS 1.0 and 1.1, which contain known security vulnerabilities. Organizations must harden these applications to communicate exclusively through TLS 1.2 or TLS 1.3 without requiring application code changes or recompilation.

Why enforce strong cryptography for .NET

Legacy TLS protocols (1.0 and 1.1) expose applications to man-in-the-middle attacks and protocol downgrade attacks. Compliance frameworks including PCI DSS, HIPAA, and FedRAMP mandate TLS 1.2 or higher for all encrypted communications. Many third-party services and APIs have already deprecated older TLS versions.

.NET Framework applications inherit their TLS behavior from operating system defaults unless explicitly configured. Without registry-level enforcement, applications may silently negotiate weaker protocols when connecting to external services, creating compliance gaps that traditional security scans cannot detect.

How the security configuration works

1. Evaluation phase: The Worklet checks four registry paths for existing SchUseStrongCrypto and SystemDefaultTlsVersions values under both HKLM and HKLM\Wow6432Node for .NET versions 2.0.50727 and 4.0.30319. It reports the current configuration state and identifies which registry keys require modification.

2. Remediation phase: The Worklet creates or updates registry DWORD values, setting both SchUseStrongCrypto and SystemDefaultTlsVersions to 1 across all four registry locations. This configuration forces .NET applications to use operating system TLS defaults (TLS 1.2+) and prevents negotiation with older protocols.

.NET cryptography hardening requirements

• Windows 7 or later with .NET Framework 2.0/3.5 or 4.x installed

• Administrator privileges for HKLM registry modification

• Operating system support for TLS 1.2 (Windows 7 SP1+ with KB3140245)

• Application restart required for changes to take effect

Expected security configuration state

After the Worklet completes, all .NET Framework applications on the endpoint will negotiate TLS 1.2 or TLS 1.3 by default when establishing HTTPS connections. Applications that previously connected to services using TLS 1.0 or 1.1 will automatically upgrade to modern protocols on their next connection attempt.

You can verify the configuration by checking registry values at HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 and HKLM\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319. Both SchUseStrongCrypto and SystemDefaultTlsVersions should show DWORD value 1. Legacy applications that require TLS 1.0 or 1.1 will fail to establish encrypted connections after this configuration change.

How to validate enable strong crypto and tls defaults for .net framework changes

1. Run this Worklet on a pilot Windows endpoint and review evaluation output for enable strong crypto and tls defaults for .net framework.

2. Confirm Automox activity logs show successful completion and exit code 0.

3. Verify endpoint state using checks aligned to evaluation script logic, such as Test-Registry, Write-Verbose, Write-Output.

4. Validate remediation effects from script operations such as Test-Registry, Write-Verbose, Write-Error, then rerun evaluation for compliance.

For technical validation, compare endpoint state to the Worklet evaluation logic and remediation flow for enable strong crypto and tls defaults for .net framework. This supports repeatable security workflows, faster change control review, and auditable compliance evidence.

Useful script references for this Worklet include evaluation operations such as Test-Registry, Write-Verbose, Write-Output and remediation operations such as Test-Registry, Write-Verbose, Write-Error. Use these indicators to verify that endpoint changes match intended policy outcomes.