This post is part of a series we are calling “SQL Server 2016 – The Final Countdown.”
For many companies SQL Server 2016 is a reliable database management system. It has worked well for several years and let’s be honest; it isn’t broken, so why fix it?
We all have several high-priority tasks; everything from updating a report for management to troubleshooting the same report for slow performance. We all know the end of life for SQL Server 2016 is right around the corner, but not everyone has the time to research why newer versions are a safer choice. In this article we will explore one of the security enhancements supported by newer releases of SQL Server; TLS encryption.
TLS encryption is something you’ve likely heard from your system administrators and security team. TLS stands for Transport Layer Security, and it is used to provide secure communication over a network. To relate that to the DBA world, TLS is used when a request is made to connect to your SQL Server. The server operating system will negotiate with the client to determine a common protocol to use when encrypting traffic between the two systems. To give an example; if your server operating system supports TLS 1.0 and TLS 1.1 and the application server supports TLS 1.1 and TLS 1.2; the common protocol is TLS 1.1 and that will be used to encrypt the connection between the systems.
When SQL Server 2016 was released, Microsoft recommended using TLS 1.2, which was the most advanced encryption protocol at the time. SQL Server 2016 also supported other common protocols like TLS 1.0 and 1.1. Since the operating system handles negotiating with clients on which protocol to use, most systems have all versions of TLS enabled.
At the time it worked but vulnerabilities were discovered in TLS 1.0 and 1.1 and both were marked as deprecated in 2021. Having said that, just because they were marked as deprecated doesn’t mean they were disabled. I still see systems from time to time with TLS 1.0 and 1.1 enabled.
Currently though, this leaves TLS 1.2 as the only supported encryption protocol for SQL Server 2016 to use for secure communication. And while it is still supported, TLS 1.2 has its own security issues and is being replaced by TLS 1.3. The security industry currently recommends moving towards TLS 1.3 because it fixes some weaknesses outlined below:
| Security Enhancement | TLS 1.3 | Why it matters |
| Mandatory Perfect Forward Secrecy (PFS) | Always enforced (ECDHE only). TLS 1.2 does not enforce PFS. | Prevents attackers from decrypting past traffic even if the server’s private key is later compromised |
| Removal of broken Cryptography | All known broken cryptography was removed. The following are allowed in TLS 1.2 but have known vulnerabilities. (RSA, SHA-1, 3DES, RC4) | Entire classes of attacks are no longer possible because the cryptography simply isn’t there |
| Encrypted Handshake (improved privacy) | Handshake encrypted after the “ServerHello” request TLS 1.2 does some negotiations in clear text which can leak information for the advantage of a bad actor. | Prevents passive observers from learning server identity, certificates, or negotiation details |
| Built-in downgrade attack protection | Cryptographically enforced. In TLS 1.2 an attacker can force a weaker TLS version or cipher suite to further their attack. | Clients can detect forced downgrades to weaker protocols or parameters, blocking silent downgrade attacks |
Currently the only versions of SQL Server that support TLS 1.3 are SQL Server 2022 and SQL Server 2025. SQL Server 2022 only supports TLS 1.3 when TDS 8.0 is in use while SQL 2025 fully supports TLS 1.3.
What does this all mean and why does it matter? So glad you asked. This matters because new TLS vulnerabilities are discovered constantly, and an end‑of‑support database server becomes the weakest encrypted link in the environment. Attackers don’t target what’s newest, they target what is unpatched. With SQL Server 2016 no longer receiving updates after July 2026, and TLS 1.2 no longer receiving updates either; these servers will be very enticing to a bad actor when one gets into your environment.
The questions I think most people aren’t asking themselves are:
“Am I okay with being the weakest link in the company chain when defending against hackers?”
“Am I okay with admitting the servers I manage were taken over because I put off upgrading them to newer and more secure software?”
If your answer to these questions is “No!”, my recommendation for you is to start planning and pushing for a migration to SQL Server 2022 or SQL Server 2025.