Azure App Service Supports Insecure TLS Version: Why It Matters and How to Fix It

If your Azure App Service still negotiates TLS 1.0 or 1.1, you are leaving a door open that the rest of the industry closed years ago. The appservice_oldtls check looks at the minimum TLS version configured on each App Service and raises a finding when that floor is set below 1.2. It is one of the quieter misconfigurations because everything keeps working, clients still connect, and nothing breaks. That is exactly what makes it easy to miss.

This post walks through what the check detects, why old TLS versions are a real liability, and how to fix and prevent it across the console, CLI, and infrastructure as code.

---

What this check detects

Azure App Service has a setting called Minimum Inbound TLS Version. It controls the lowest TLS protocol version a client is allowed to use when connecting to your app over HTTPS. The Lensix check inspects this value for every App Service in scope and flags any app where the minimum is set to 1.0 or 1.1.

When the minimum is set to 1.0, the service will happily complete a handshake with a client speaking TLS 1.0, 1.1, or 1.2. The setting is a floor, not a ceiling, so a low floor means weak connections are permitted even if most clients use something stronger.

---

Why it matters

The risk here is not theoretical. TLS 1.0 and 1.1 carry known cryptographic weaknesses that have been weaponized in real attacks.

• BEAST exploited a flaw in the CBC cipher mode used by TLS 1.0, allowing attackers to recover session cookies and other plaintext from an encrypted stream.
• POODLE and downgrade attacks let an attacker force a connection to fall back to weaker protocols, then break the encryption.
• Both versions rely on outdated hash functions like MD5 and SHA-1 for handshake integrity, which are no longer considered safe.

An attacker positioned on the network path, for example on shared Wi-Fi or a compromised upstream router, can intercept traffic and attempt these attacks against any client still negotiating the old protocols. The result can be stolen session tokens, leaked credentials, or tampered responses.

Beyond the direct attack surface, this is a compliance problem. PCI DSS has prohibited TLS 1.0 since mid-2018 and discourages 1.1. HIPAA, SOC 2, and most internal security baselines expect TLS 1.2 or higher. An auditor running a scan will find this in minutes, and it is the kind of finding that shows up in penetration test reports with an embarrassing severity rating.

---

How to fix it

The fix is to set the minimum inbound TLS version to 1.2. App Service supports 1.2 universally, and TLS 1.3 is available in newer regions and stacks.

Azure Portal

1. Open the Azure Portal and navigate to your App Service.
2. In the left menu, go to Settings > Configuration.
3. Select the General settings tab.
4. Find Minimum Inbound TLS Version and set it to 1.2 (or 1.3 if shown).
5. Click Save.

Azure CLI

To check the current minimum TLS version for an app:

az webapp config show \
  --name my-app-service \
  --resource-group my-resource-group \
  --query minTlsVersion -o tsv

To raise it to 1.2:

az webapp config set \
  --name my-app-service \
  --resource-group my-resource-group \
  --min-tls-version 1.2

To sweep every App Service in a subscription and report any below 1.2:

az webapp list --query "[].{name:name, rg:resourceGroup}" -o tsv | \
while read name rg; do
  tls=$(az webapp config show --name "$name" --resource-group "$rg" \
    --query minTlsVersion -o tsv)
  if [ "$tls" != "1.2" ] && [ "$tls" != "1.3" ]; then
    echo "INSECURE: $name ($rg) -> $tls"
  fi
done

PowerShell

Set-AzWebApp `
  -ResourceGroupName "my-resource-group" `
  -Name "my-app-service" `
  -MinTlsVersion "1.2"

Terraform

For the azurerm_linux_web_app or azurerm_windows_web_app resource, set the value inside the site_config block:

resource "azurerm_linux_web_app" "example" {
  name                = "my-app-service"
  resource_group_name = azurerm_resource_group.example.name
  location            = azurerm_resource_group.example.location
  service_plan_id     = azurerm_service_plan.example.id

  site_config {
    minimum_tls_version = "1.2"
  }
}

Bicep / ARM

{
  "type": "Microsoft.Web/sites/config",
  "apiVersion": "2022-09-01",
  "name": "[concat(parameters('appName'), '/web')]",
  "properties": {
    "minTlsVersion": "1.2"
  }
}

---

How to prevent it from happening again

Fixing one app is easy. Keeping every new app compliant is the real work. The minimum TLS default has historically been 1.2 on newer App Services, but older apps, cloned templates, and manual portal clicks can all reintroduce a weak floor. Catch it before it ships.

Azure Policy

Azure provides a built-in policy that audits or enforces the minimum TLS version. Assign it at the subscription or management group level to cover everything automatically.

# Built-in policy: "App Service apps should use the latest TLS version"
az policy assignment create \
  --name "appservice-min-tls-12" \
  --display-name "App Service apps should use TLS 1.2 minimum" \
  --policy "f0e6e85b-9b9f-4a4b-b67b-f730d42f1b0b" \
  --scope "/subscriptions/"

You can run the policy in Audit mode first to find existing violators, then switch a custom Deny policy on once your estate is clean. A deny policy will block deployment of any App Service that tries to set a TLS version below 1.2.

CI/CD gate

If you deploy with Terraform, add a check to your pipeline that scans plans for weak TLS settings. Tools like tfsec and checkov flag this out of the box:

# Checkov catches azure_app_service min TLS findings
checkov -d . --framework terraform \
  --check CKV_AZURE_15

Fail the build when the check fails. That turns a security finding into a code review comment instead of a production incident.

---

Best practices

• Set 1.2 as the organization-wide floor, 1.3 where supported. TLS 1.3 drops legacy ciphers entirely and completes handshakes faster. Use it on any region and stack that offers it.
• Enforce HTTPS-only. A strong TLS floor means little if the app still serves plaintext HTTP. Set httpsOnly to true so HTTP requests are redirected to HTTPS.
• Cover the SCM endpoint. Apply the same minimum TLS version to the Kudu deployment site, not just the main app.
• Audit before enforce. Run policies in audit mode, review access logs for legacy clients, then move to deny. This avoids surprise outages.
• Re-scan regularly. Configuration drifts. A scheduled scan with Lensix or Azure Policy catches the app someone span up last week with a stale template.

TLS version hardening is one of the highest-value, lowest-effort security fixes available on App Service. There is no extra cost, no downtime for modern clients, and a measurable reduction in attack surface. Set the floor to 1.2, enforce it with policy, and gate it in CI so it never slips back.