What’s the issue?
SQL Server supports encrypting client connections using TLS, which protects data in motion between clients and the Database Engine. The Force Encryption setting in SQL Server Configuration Manager (instance protocol properties, Flags tab) determines whether the server encrypts all client/server communication or allows clients to connect without encryption unless they request it.When Force Encryption is enabled, SQL Server encrypts all client/server communication and clients must be able to establish TLS and trust the server certificate chain (or otherwise be configured appropriately). If a CA‑issued certificate is not provisioned, SQL Server can generate a self‑signed certificate at startup, but this does not provide strong authentication and is not recommended for production.
This finding identifies instances where Force Encryption is enabled. This is not a problem by itself, but it warrants review to confirm the certificate configuration is correct (meets SQL Server certificate requirements, is trusted by clients, and is within its validity period) to avoid unexpected connectivity issues and reduce MitM risk.
Why is this a problem?
Force Encryption meaningfully strengthens in‑transit security by ensuring all client/server communication is encrypted (and the login process is always encrypted regardless). The setting is commonly used where connections traverse untrusted networks or where policies require encryption in motion, because SQL Server uses TLS to encrypt network traffic between client applications and the Database Engine.The main consideration is the server certificate. SQL Server TLS certificates must meet specific requirements (including Server Authentication EKU, appropriate name/SAN coverage for how clients connect, and service account access to the certificate/private key), and clients must be able to trust the issuing CA for full validation.
Certificate expiration is a common operational risk: TLS requires the certificate to be within its validity period, and an expired or invalid certificate can cause connection failures when encryption is required (and in some misconfiguration cases can prevent SQL Server from starting). Plan certificate renewal and monitoring accordingly, and be aware that changes often require a SQL Server restart to fully apply.
Client compatibility is another consideration. TLS negotiation requires matching supported protocol versions/ciphers between client and server; disabling older TLS versions for security can break legacy clients that haven’t been updated.
What should you do about this?
No remediation is required if Force Encryption is being used intentionally and the supporting certificate is properly configured. Confirm the current setting in SQL Server Configuration Manager under the protocols for the affected instance, and verify that the intended certificate is selected and meets SQL Server certificate requirements.Verify certificate health: confirm the expiration date/validity period, that the certificate chain is trusted by clients, that the subject/SAN matches the server name clients use, and that the SQL Server service account has access to the certificate/private key. Test from representative clients to confirm encrypted connections succeed and certificate validation does not require bypass settings.
Document the certificate (internal CA/public CA/self-signed), expiration date, renewal procedure, and deployment steps. Plan renewal well ahead of expiration; expired/invalid certificates can break validated TLS connections, and misconfigured certificates can in some cases prevent SQL Server from starting. Account for the SQL Server service restart typically needed for configuration/certificate changes to fully take effect.
Confirm supported TLS versions and cipher suites on the SQL Server host align with security requirements and client compatibility. Microsoft guidance for modernization emphasizes moving to TLS 1.2 (and TLS 1.3 where supported) and carefully validating/upgrading client drivers before disabling TLS 1.0/1.1, because the primary risk is legacy client incompatibility. If enabling TLS 1.3, note that TLS 1.2 may still be required for some SQL Server components depending on version and configuration.