SQL Server TLS Version Not Enforced: Why Azure SQL Needs TLS 1.2

When a database accepts connections over an old version of TLS, every query, credential, and result set traveling between your application and the server is protected by a protocol that researchers have already broken. Azure SQL Server lets you pin a minimum TLS version, but the setting is not enforced by default on older servers, and plenty of teams never touch it. This check catches that gap.

Below we walk through what sql_nosslenforcement actually detects, why an outdated TLS floor is a real problem and not just a compliance checkbox, and how to fix it with the CLI, the portal, and infrastructure as code.

---

What this check detects

The check inspects each Azure SQL logical server in your subscription and reads its minimalTlsVersion property. If that value is anything other than 1.2 (or higher), the server is flagged.

There are a few states this property can be in:

• Not set / null — the server accepts connections over TLS 1.0, 1.1, and 1.2. This is the riskiest state.
• 1.0 — all three versions are allowed.
• 1.1 — TLS 1.1 and 1.2 are allowed, 1.0 is rejected.
• 1.2 — only TLS 1.2 and above are accepted. This is the state the check wants.

---

Why it matters

TLS is what stops an attacker who can see your network traffic from reading or tampering with it. The strength of that protection depends entirely on the protocol version negotiated between client and server. TLS 1.0 dates to 1999 and TLS 1.1 to 2006, and both carry weaknesses that modern attacks exploit.

The concrete risks

• Known protocol attacks. BEAST, POODLE, and related downgrade attacks target weaknesses in TLS 1.0 and the cipher suites it permits. An attacker positioned on the network path can use these to recover plaintext from an encrypted session.
• Weak cipher suites. Older TLS versions allow RC4 and other ciphers that are no longer considered safe. Even a correctly negotiated TLS 1.0 connection may be using cryptography that has been deprecated for years.
• Downgrade exposure. When a server accepts multiple TLS versions, a man-in-the-middle can attempt to force both ends down to the weakest one they share. Enforcing 1.2 removes that option entirely.

For a database, the data in transit is some of the most sensitive you have. Connection strings carry credentials. Queries carry parameters that might include personally identifiable information. Result sets carry whatever your application stores. If any of that crosses an untrusted network, the floor you set on TLS is the floor on how well it is protected.

---

How to fix it

The fix is a single property change. The work is mostly in confirming your clients can handle TLS 1.2 before you flip the switch.

Step 1: Check the current setting

az sql server show \
  --name myserver \
  --resource-group my-rg \
  --query "minimalTlsVersion" \
  --output tsv

An empty result or a value of 1.0 or 1.1 means the server is in scope for this check.

Step 2: Confirm your clients support TLS 1.2

Before enforcing, make sure nothing legacy connects to the server. Almost every current driver and runtime negotiates TLS 1.2 by default, but old .NET Framework versions, legacy ODBC drivers, and some embedded systems may not. Things to verify:

• .NET Framework apps are on 4.6 or later, or have SystemDefaultTlsVersions enabled.
• JDBC, ODBC, and PHP drivers are reasonably current.
• Any third-party tools or reporting services that connect directly.

Step 3: Set the minimum TLS version

az sql server update \
  --name myserver \
  --resource-group my-rg \
  --minimal-tls-version 1.2

The change takes effect within a few minutes. Existing connections are not dropped mid-session, but new connections that cannot meet the minimum will be refused.

Console steps

1. Open the Azure portal and navigate to your SQL server (the logical server, not a database).
2. In the left menu under Security, select Networking.
3. Open the Connectivity tab.
4. Under Minimum TLS version, select 1.2.
5. Click Save.

Fix it across every server at once

If you have more than a couple of servers, loop over them:

az sql server list --query "[?minimalTlsVersion!='1.2'].[name,resourceGroup]" -o tsv |
while read name rg; do
  echo "Updating $name in $rg"
  az sql server update --name "$name" --resource-group "$rg" --minimal-tls-version 1.2
done

---

Fixing it in infrastructure as code

If you provision SQL Servers through IaC, set the floor in the template so it is correct from creation. New servers should never ship without it.

Terraform

resource "azurerm_mssql_server" "main" {
  name                         = "myserver"
  resource_group_name          = azurerm_resource_group.main.name
  location                     = azurerm_resource_group.main.location
  version                      = "12.0"
  administrator_login          = "sqladmin"
  administrator_login_password = var.sql_admin_password

  minimum_tls_version = "1.2"
}

Bicep

resource sqlServer 'Microsoft.Sql/servers@2023-08-01-preview' = {
  name: 'myserver'
  location: location
  properties: {
    administratorLogin: 'sqladmin'
    administratorLoginPassword: sqlAdminPassword
    minimalTlsVersion: '1.2'
  }
}

---

How to prevent it from happening again

Fixing the servers you have today is the easy part. Keeping new ones from regressing is where the durable wins are.

Azure Policy

Azure ships a built-in policy definition that audits or denies SQL Servers below a minimum TLS version. Deny mode stops the misconfiguration at deployment time.

az policy assignment create \
  --name "sql-min-tls-12" \
  --display-name "Require TLS 1.2 on SQL Servers" \
  --policy "32e6bbec-16b6-44c2-be37-c5b672d103cf" \
  --scope "/subscriptions/<subscription-id>" \
  --params '{"minimalTlsVersion": {"value": "1.2"}}'

Assigning it at the subscription or management group level means every resource group inherits the rule. With the effect set to Deny, a pipeline that tries to create a non-compliant server simply fails.

Scan IaC before it merges

Catch the problem in pull requests with a policy-as-code scanner such as Checkov or tfsec. A pipeline step keeps it out of main before anything reaches Azure:

checkov -d . --check CKV_AZURE_52

---

Best practices

• Set 1.2 as the floor everywhere, not just where it is convenient. Apply it to dev and test servers too. A weak setting in a lower environment trains people to expect it and tends to leak into production templates.
• Pin it in IaC, not by hand. A manually corrected server drifts back the next time someone redeploys. The source of truth should be your template.
• Inventory your clients now. The only real blocker to enforcing 1.2 is a legacy client. Find them before they find you, and plan their upgrade.
• Combine TLS enforcement with private connectivity. A strong TLS floor protects traffic that crosses the network. Pairing it with Private Endpoints or VNet integration shrinks how much of that traffic is exposed in the first place.
• Plan ahead for 1.3. Azure SQL is moving toward TLS 1.3 support. Build your policies so the minimum version is a parameter you can raise, not a magic string scattered across a hundred files.

Enforcing a minimum TLS version is one of the cheapest security improvements available on Azure SQL. It is a single property, it has no cost, and it closes off an entire class of downgrade and protocol attacks. The only effort is confirming your clients keep up, and in 2024 nearly all of them already do.