Azure API Management May Allow Insecure TLS: Detection, Fix, and Prevention

Azure API Management (APIM) sits in front of your backend services as the public entry point for your APIs. Because it terminates TLS for inbound client traffic, the protocols and ciphers it negotiates directly determine how secure those connections actually are. When an APIM instance is configured to accept TLS 1.0 or TLS 1.1, it advertises support for protocols that have known structural weaknesses and have been formally deprecated across the industry.

The apimgmt_oldtls check inspects your APIM gateway protocol settings and raises a finding when insecure TLS versions are still enabled.

---

What this check detects

API Management exposes a set of toggles that control which TLS protocol versions and cipher suites the gateway will negotiate with clients and backends. These live under the service's customProperties. The check looks for any of the following being enabled:

• TLS 1.0 for inbound (client to gateway) requests
• TLS 1.1 for inbound requests
• TLS 1.0 or 1.1 for outbound (gateway to backend) requests
• Legacy and weak cipher suites such as 3DES and the older RSA key exchange ciphers

If any of these are turned on, a client or an on-path attacker can negotiate a downgraded, weaker connection even when stronger options are available.

---

Why it matters

TLS 1.0 dates back to 1999 and TLS 1.1 to 2006. Both were deprecated by the IETF in RFC 8996, and major browsers dropped support for them in 2020. They remain enabled in many environments only for backward compatibility with ancient clients, and that compatibility comes at a real cost.

The concrete risks:

• Downgrade attacks. An attacker positioned between the client and gateway can strip the connection down to the weakest mutually supported protocol. If TLS 1.0 is on the menu, that is what they will force.
• Known cryptographic weaknesses. TLS 1.0 and 1.1 are vulnerable to attacks like BEAST and POODLE, and they rely on weak MAC constructions (MD5/SHA-1) that modern attacks can exploit.
• Weak ciphers. 3DES is susceptible to the Sweet32 birthday attack, which can recover plaintext from long-lived connections.
• Compliance failures. PCI DSS has required TLS 1.0 be disabled since 2018. HIPAA, SOC 2, and FedRAMP assessors all expect TLS 1.2 or higher. An APIM gateway accepting legacy TLS is an easy audit finding.

Because APIM is internet-facing by design for most teams, this is not a theoretical edge case. The gateway is exactly the surface an attacker probes first.

---

How to fix it

Option 1: Azure Portal

1. Open your API Management service in the Azure Portal.
2. Under Deployment + infrastructure, select Protocols + ciphers (older portals label this Custom domains or Transport layer security).
3. Disable TLS 1.0 and TLS 1.1 for both client and backend connections.
4. Disable the legacy ciphers, especially 3DES.
5. Save. The change can take 15 to 45 minutes to apply because APIM updates the gateway configuration.

Option 2: Azure CLI

You update the protocol settings through the service's custom properties. Set each legacy protocol to False.

RG="my-resource-group"
APIM="my-apim-service"

az apim update \
  --resource-group "$RG" \
  --name "$APIM" \
  --set "properties.customProperties.\"Microsoft.WindowsAzure.ApiManagement.Gateway.Security.Protocols.Tls10\"=False" \
        "properties.customProperties.\"Microsoft.WindowsAzure.ApiManagement.Gateway.Security.Protocols.Tls11\"=False" \
        "properties.customProperties.\"Microsoft.WindowsAzure.ApiManagement.Gateway.Security.Backend.Protocols.Tls10\"=False" \
        "properties.customProperties.\"Microsoft.WindowsAzure.ApiManagement.Gateway.Security.Backend.Protocols.Tls11\"=False" \
        "properties.customProperties.\"Microsoft.WindowsAzure.ApiManagement.Gateway.Security.Ciphers.TripleDes168\"=False"

Verify the result:

az apim show \
  --resource-group "$RG" \
  --name "$APIM" \
  --query "customProperties" -o json

Every legacy protocol and cipher property should report "False".

Option 3: Bicep

resource apim 'Microsoft.ApiManagement/service@2023-05-01-preview' = {
  name: apimName
  location: location
  sku: {
    name: 'Standard'
    capacity: 1
  }
  properties: {
    publisherEmail: '[email protected]'
    publisherName: 'Example Ops'
    customProperties: {
      'Microsoft.WindowsAzure.ApiManagement.Gateway.Security.Protocols.Tls10': 'False'
      'Microsoft.WindowsAzure.ApiManagement.Gateway.Security.Protocols.Tls11': 'False'
      'Microsoft.WindowsAzure.ApiManagement.Gateway.Security.Backend.Protocols.Tls10': 'False'
      'Microsoft.WindowsAzure.ApiManagement.Gateway.Security.Backend.Protocols.Tls11': 'False'
      'Microsoft.WindowsAzure.ApiManagement.Gateway.Security.Ciphers.TripleDes168': 'False'
    }
  }
}

Option 4: Terraform

resource "azurerm_api_management" "this" {
  name                = "my-apim-service"
  location            = azurerm_resource_group.this.location
  resource_group_name = azurerm_resource_group.this.name
  publisher_name      = "Example Ops"
  publisher_email     = "[email protected]"
  sku_name            = "Standard_1"

  security {
    enable_backend_tls10 = false
    enable_backend_tls11 = false
    enable_frontend_tls10 = false
    enable_frontend_tls11 = false
    triple_des_ciphers_enabled = false
  }
}

---

How to prevent it from happening again

Fixing one APIM instance is the easy part. Keeping the setting correct across every service and every new deployment is where teams slip. Bake the requirement into the pipeline.

Enforce with Azure Policy

Azure Policy can audit or deny APIM services that have insecure protocols enabled. A custom policy that inspects customProperties works well because the built-in coverage here is thin.

{
  "if": {
    "allOf": [
      {
        "field": "type",
        "equals": "Microsoft.ApiManagement/service"
      },
      {
        "anyOf": [
          {
            "field": "Microsoft.ApiManagement/service/customProperties.Microsoft.WindowsAzure.ApiManagement.Gateway.Security.Protocols.Tls10",
            "equals": "True"
          },
          {
            "field": "Microsoft.ApiManagement/service/customProperties.Microsoft.WindowsAzure.ApiManagement.Gateway.Security.Protocols.Tls11",
            "equals": "True"
          }
        ]
      }
    ]
  },
  "then": {
    "effect": "deny"
  }
}

Assign it at the subscription or management group level so it covers every team. Start with an audit effect to find existing violations, then switch to deny once you have remediated them.

Gate it in CI/CD

If you deploy APIM through Terraform or Bicep, add a static analysis step that fails the build when the insecure properties are present. Tools like Checkov, tfsec, and Conftest all fit cleanly into a pull request check.

# Run Checkov against your Terraform plan in CI
checkov -d ./infra --framework terraform --compact

# Or enforce a custom OPA policy with Conftest
conftest test ./infra/apim.tf --policy ./policy/tls.rego

---

Best practices

• Default to TLS 1.2 minimum, prefer 1.3. APIM supports TLS 1.3 on most tiers. Enable it for the strongest negotiation and best performance.
• Disable both frontend and backend legacy protocols. Securing client connections while leaving the gateway-to-backend hop on TLS 1.0 just moves the weakness, it does not remove it.
• Audit your client base before tightening. Use APIM diagnostic logs sent to Log Analytics to see which TLS versions clients actually negotiate, then make the change with confidence.
• Standardize new instances from a hardened template. Ship a Bicep or Terraform module with secure defaults so no one creates an APIM service the insecure way.
• Review after every platform change. Tier upgrades, migrations, and restores can reset custom properties. Re-run the check after major operations.

Disabling legacy TLS on API Management is a small, well-understood change with a large security payoff. Get one instance right, encode that into policy, and the entire estate stays compliant without anyone having to remember the property names.