TLS should be updated to the latest version for API apps

What does the recommendation "TLS should be updated to the latest version for API apps" check?

Flags any App Service API app (the legacy 'kind' of api) whose inbound minimum TLS version is still set to 1.0 or 1.1 rather than 1.2 or later. It reads the minTlsVersion value in the app's siteConfig and reports anything below 1.2 as non-compliant. It only governs the minimum floor for client connections to the app's default host; it does not check scmMinTlsVersion on the Kudu or SCM endpoint, it does not cover regular web apps or Function apps (those have their own recommendations), and it says nothing about the cipher suites negotiated above that floor or about TLS on any custom domain certificate.

Why does "TLS should be updated to the latest version for API apps" matter?

TLS 1.0 and 1.1 carry known weaknesses such as BEAST and POODLE and rely on outdated cipher and hashing primitives, so a client speaking them to your API can have its session downgraded or its traffic decrypted by an attacker positioned on the path. For an API app that is often the data plane other services and partners call, that exposes request bodies, tokens and keys in transit. Beyond the breach risk, leaving 1.0 or 1.1 enabled fails PCI DSS and most baseline audits, and Azure retires inbound TLS 1.0 and 1.1 for App Service on 31 May 2027, so apps left on the old floor will eventually break as well as fail compliance.

How do I fix "TLS should be updated to the latest version for API apps"?

1. In the portal open the API app, go to Settings then Configuration, and on the General settings tab set Minimum Inbound TLS Version to 1.2 (or 1.3 where supported). The equivalent CLI is: az webapp config set --resource-group <rg> --name <app> --min-tls-version 1.2
2. Bake the floor into your infrastructure so it cannot drift: in Bicep set the siteConfig property, for example siteConfig: { minTlsVersion: '1.2' } on the Microsoft.Web/sites resource, and redeploy.
3. To enforce this across the subscription, assign the built-in policy by its display name rather than a hardcoded GUID: pid=$(az policy definition list --query "[?displayName=='Latest TLS version should be used in your API App'].name" -o tsv); az policy assignment create --name require-apiapp-tls --policy "$pid" --scope <scope>

# Close the highest-impact plaintext doors first: the Redis non-SSL port,
# then HTTPS-only + a modern TLS floor on every web app.

# Redis: disable the non-SSL port 6379 and require TLS 1.2 (clients use 6380).
for cache in $(az redis list --query "[?enableNonSslPort].name" -o tsv); do
  rg=$(az redis list --query "[?name=='$cache'].resourceGroup" -o tsv)
  az redis update --name "$cache" --resource-group "$rg" \
    --set enableNonSslPort=false minimumTlsVersion=1.2
  echo "$cache: non-SSL port disabled, min TLS 1.2"
done

# Web apps: enforce HTTPS only and raise the TLS floor.
for app in $(az webapp list --query "[?httpsOnly==\`false\`].name" -o tsv); do
  rg=$(az webapp list --query "[?name=='$app'].resourceGroup" -o tsv)
  az webapp update --name "$app" --resource-group "$rg" --https-only true
  az webapp config set --name "$app" --resource-group "$rg" --min-tls-version 1.2
  echo "$app: HTTPS only, min TLS 1.2"
done

# Functions follow the same pattern with az functionapp update --set httpsOnly=true.

# Ratchet it shut: assign the built-in deny policy for web apps over HTTPS only.
az policy assignment create \
  --name require-https-webapp \
  --policy a4af4a39-4135-47fb-b175-47fbdf85311d \
  --scope "/subscriptions/00000000-0000-0000-0000-000000000000"