Service Bus Namespace Uses Insecure TLS

Azure Service Bus sits in the middle of a lot of important plumbing: order processing, payment events, IoT telemetry, cross-service commands. Anything moving through it is usually business-critical and often sensitive. So the transport security that protects those messages in flight matters more than people tend to assume.

The servicebus_oldtls check looks at whether a namespace enforces a minimum TLS version of 1.2. If a namespace still accepts TLS 1.0 or 1.1 connections, Lensix flags it.

---

What this check detects

Every Service Bus namespace has a minimumTlsVersion property. It controls the lowest TLS version a client is allowed to negotiate when connecting to the namespace endpoint. The valid values are 1.0, 1.1, and 1.2.

This check fails when the property is set to 1.0 or 1.1. Namespaces created before the property existed, or created without explicitly setting it, may default to a lower version depending on when and how they were provisioned, so older namespaces are the usual offenders.

---

Why it matters

TLS 1.0 and 1.1 are deprecated. The IETF formally deprecated both in RFC 8996, and the PCI Security Standards Council pushed organizations off TLS 1.0 years ago. They carry a list of practical problems that newer versions fixed:

• Weak cipher suites. TLS 1.0 and 1.1 support cipher suites and constructions that are no longer considered safe, including ones vulnerable to BEAST and similar attacks.
• Downgrade attacks. If a namespace accepts old protocol versions, an attacker positioned on the network path can attempt to force a client and server to negotiate the weaker version, then attack that.
• No modern integrity guarantees. The older versions lack the authenticated encryption and stronger MAC handling that TLS 1.2 brought in.

For a messaging backbone, the realistic risk is interception or tampering of message payloads in transit. If those messages carry order details, personal data, or auth tokens, a successful downgrade and decrypt turns into a data exposure incident. There is also the compliance angle: frameworks like PCI DSS, HIPAA-aligned controls, and most internal security baselines explicitly require TLS 1.2 or higher. An auditor finding TLS 1.0 enabled on a production namespace is an easy finding to write up and an awkward one to explain.

The cost of fixing this is close to zero. The cost of explaining a downgrade incident on a payment event bus is not.

---

How to fix it

Set the minimum TLS version to 1.2. This is a metadata change on the namespace and does not recreate any queues, topics, or subscriptions.

Azure CLI

az servicebus namespace update \
  --resource-group my-resource-group \
  --name my-servicebus-namespace \
  --minimum-tls-version 1.2

Confirm the change took effect:

az servicebus namespace show \
  --resource-group my-resource-group \
  --name my-servicebus-namespace \
  --query minimumTlsVersion \
  --output tsv

Azure Portal

1. Open the Service Bus namespace in the Azure Portal.
2. Under Settings, select Configuration (or Networking depending on the current portal layout).
3. Find Minimum TLS Version.
4. Set it to 1.2 and click Save.

Bicep

resource sbNamespace 'Microsoft.ServiceBus/namespaces@2022-10-01-preview' = {
  name: 'my-servicebus-namespace'
  location: resourceGroup().location
  sku: {
    name: 'Standard'
    tier: 'Standard'
  }
  properties: {
    minimumTlsVersion: '1.2'
  }
}

Terraform

resource "azurerm_servicebus_namespace" "main" {
  name                = "my-servicebus-namespace"
  location            = azurerm_resource_group.main.location
  resource_group_name = azurerm_resource_group.main.name
  sku                 = "Standard"

  minimum_tls_version = "1.2"
}

az servicebus namespace list \
  --query "[?minimumTlsVersion!='1.2'].{name:name, rg:resourceGroup, tls:minimumTlsVersion}" \
  --output table

---

How to prevent it from happening again

Fixing the namespaces you have today is the easy part. Keeping new ones from drifting back is where policy-as-code earns its place.

Azure Policy

Use a deny or audit policy that checks the minimumTlsVersion field on Service Bus namespaces. A deny effect stops a non-compliant namespace from being created at all.

{
  "if": {
    "allOf": [
      {
        "field": "type",
        "equals": "Microsoft.ServiceBus/namespaces"
      },
      {
        "anyOf": [
          {
            "field": "Microsoft.ServiceBus/namespaces/minimumTlsVersion",
            "exists": "false"
          },
          {
            "field": "Microsoft.ServiceBus/namespaces/minimumTlsVersion",
            "notEquals": "1.2"
          }
        ]
      }
    ]
  },
  "then": {
    "effect": "deny"
  }
}

CI/CD gates

If you provision Service Bus through Terraform or Bicep, lint the templates before they ever reach Azure. A few options:

• Run Checkov or tfsec against your Terraform in the pipeline to catch missing minimum_tls_version settings.
• Use az deployment group what-if or a Bicep linter step to surface the property before deploy.
• Keep Lensix scanning the live environment so anything created out-of-band, through the portal or a one-off script, still gets caught.

---

Best practices

• Always set minimumTlsVersion explicitly in your IaC. Relying on defaults leaves the value at the mercy of whatever the resource provider chooses, which has changed over time.
• Pair TLS enforcement with network restrictions. Transport security protects data in flight, but it does not control who can reach the namespace. Use private endpoints or IP firewall rules so only trusted networks connect at all.
• Disable local SAS-only auth where you can and prefer Azure AD (Microsoft Entra ID) authentication with managed identities. Strong transport plus strong identity is the combination you want.
• Audit the whole estate, not one namespace. A single fixed namespace means little if a forgotten dev namespace in another resource group is still on TLS 1.0 and exposed.
• Plan for the next deprecation. TLS 1.2 is the floor today. Build the habit of pinning a minimum version so that when 1.3 enforcement becomes the expectation, raising it is a one-line change rather than an archaeology project.

This is one of the cheapest security wins in the Azure messaging stack. One property, set once per namespace, with a policy behind it to keep it set. Make the change, lock it in with policy, and move on.