Minimum TLS version quietly lowered from 1.2 to 1.0 on Storage, SQL, or App Service

Why it happens

Someone integrates a legacy client, a runtime, or an appliance that can't negotiate TLS 1.2, and the fastest way to make the connection succeed is to lower the floor rather than fix the client. The change is a one-line property edit and it works immediately, so it ships and stays.

Because the endpoint still serves modern clients over TLS 1.2 exactly as before, nothing looks broken. The weakening is invisible unless someone is comparing the setting against its prior, stronger value. Each service spells the property differently, which makes it easy to miss in a review that only knows one of them.

What it costs / blast radius

This is a transport-security regression, not a cost. TLS 1.0 and 1.1 are deprecated and carry known weaknesses; accepting them means a network attacker able to influence the handshake can push a client onto weaker encryption, and it typically breaks compliance baselines (PCI DSS, and Azure's own hardening guidance) that require TLS 1.2 or higher. The blast radius is every client that connects to that endpoint. (Azure behavior; the setting is off the happy path only when someone downgrades it.)

See it

resource sa 'Microsoft.Storage/storageAccounts@2023-05-01' = {
  name: 'corpdata'
  location: location
  kind: 'StorageV2'
  sku: { name: 'Standard_LRS' }
  properties: {
    minimumTlsVersion: 'TLS1_0'   // was TLS1_2 — now accepts deprecated handshakes
  }
}

resource sa 'Microsoft.Storage/storageAccounts@2023-05-01' = {
  name: 'corpdata'
  location: location
  kind: 'StorageV2'
  sku: { name: 'Standard_LRS' }
  properties: {
    minimumTlsVersion: 'TLS1_2'   // fix the legacy client instead of lowering the floor
  }
}