Is Your SQL Server Traffic Secure? Why TLS Encryption Is No Longer Optional

SQL Server Logo

Why TLS encryption matters

TLS encryption is often misconfigured or entirely omitted in SQL Server installations—a critical oversight that exposes sensitive data to risk. It is a necessary configuration step during installation of a SQL instance which tends to get forgotten all too often or brushed away as unnecessary. More and more awareness is generated for these forgotten scenarios, even up to the point where legislation catches up ¹ and determines omission as a punishable act.

TLS encryption with SQL Server protects the data traffic between a SQL Server instance and the client/user. This encryption ensures that any information exchanged is securely transmitted and cannot be easily intercepted or tampered with.

When TLS is enabled, SQL Server uses a digital certificate to establish a secure connection. This certificate must be installed on the server and should match the server’s name. Once the certificate is in place, SQL Server can be configured to enforce encryption for all incoming connections. Administrators typically use SQL Server Configuration Manager to assign the certificate to the SQL Server instance and enable encryption settings.

NCSC recommendations

The NCSC (National Cyber Security Center) published renewed guidelines for TLS encryption back in 2021 ². These guidelines stated TLS1.3 was the most future proof protocol for secure IP (Internet Protocol) traffic. The guidelines were meant as an aid during procurement, set-up and review, to assist IT organisations when stating their requirements. TLS1.2 was considered sufficient, not good, in terms of future-proofness.

The risk of doing nothing

It is getting progressively easier to decrypt data. The necessary virtual hardware is available through cloud providers ³ and it is getting cheaper because of technical progress in the area of computational power ⁴.

Imagine this scenario: A simple sniffer, which is a piece of software that collects encrypted traffic and sends it to an internet addres, inadvertently imported through innocent looking actors like mail and browsers, could collect and store data for later decryption. In a couple of years, when decryption is just a low-cost, low-threshold action, your data collected today might turn up in the hands of wrong parties. Hopefully the public availability of that data can be considered harmless by then.

How TLS works

A TLS server certificate contains the name of the SQL Server. Establishing the identity of the server in TLS 1.3 is a critical part of the handshake process. It ensures that the client is communicating with the legitimate server and not an imposter. This step can be skipped providing the ‘Trust server certificate’ option (usually a checkbox in the connection popup). Needing to trust the server is a sign that the certificate is incorrectly configured and can therefore not be verified by the client, which is also the case with self-signed certificates.

After the identity checks pass, the client can trust that the server is legitimate. When configured correctly, the identity of the client can also be checked as a legitimate party in the process.

Client and server now establish a shared secret for this session. If client and server are configured for TLS1.3, it only uses temporary (aka ephemeral) shared secrets, as opposed to older versions like with TLS1.0 or SSL. That ensures that when a shared secret gets compromised in the future, at least the data sent today will remain secure.

To sum it up: as soon as all handshakes are complete, the identity of server is checked, a shared secret is established for this session, then the actual data can be securely encrypted and sent over the network. Since TLS1.3 is the latest standard, it uses the most secure encryption mechanisms during initial setup and encryption in flight, which causes more difficulty to decrypt traffic in malicious attempts.

Check your configuration

This article discusses just an excerpt of possible secure configuration settings. There are more settings that influence the security of your traffic in flight. One of the checks that can be performed is in below script. When the script returns results, there is definitely room for improvement. Wether the script returns results depends on current open connections with the SQL server, also provided it is run with adequate privileges. The script doesn’t report on the level of encryption.

-- If this query returns any results, you may have configured TLS encryption incorrectly
-- If it does not return results, it just confirms there are currently no uncompliant connections. 
-- It does not guarantee your configuration is correctly configured.
    select * 
    from sys.dm_exec_connections
    where (auth_scheme !='KERBEROS'
            or encrypt_option!='TRUE')
        and net_transport='TCP'

Note: This query only checks current connections and requires appropriate privileges. It does not confirm full TLS configuration or protocol version.

Conclusion

TLS encryption is no longer a “nice-to-have”—it’s a baseline requirement for secure SQL Server deployments. With increasing regulatory pressure and evolving cyber threats, proactive encryption is the only safest way forward.
When correctly configured server (and client) have their identity checked in the communication setup, no imposters or man in the middle scenarios.
Ephemeral secrets to encrypt traffic, only valid for this session when TLS1.3 is correctly configured, ensure that any other compromised secrets can not decrypt traffic for the current session.
TLS1.3 is the latest standard and leverages security by using more secure encryption, both during data transit and the initial handshake.

Key takeaways

Install a valid TLS certificate on your SQL Server
Configure SQL Server to use the certificate
Enforce encryption for all connections
Ensure clients support and prefer TLS 1.3
Disable outdated protocols (SSL, TLS 1.0/1.1, optionally TLS 1.2)