Storage infrastructure encryption silently drops your second at-rest layer

Why it happens

Infrastructure encryption is off by default and can only be enabled when the storage account is created. There is no toggle to turn it on later, so an account provisioned without it never gets the second layer unless someone recreates the account.

Because the default single layer already reports the account as "encrypted," dashboards and quick reviews show a green check and nobody notices the second layer was never there. The control also flips false in drift if an account is re-templated from a definition that omits the property, and Azure treats that as a perfectly valid configuration.

What it costs / blast radius

There is no direct dollar cost — infrastructure encryption is free. The blast radius is a reduced defense-in-depth posture: a single flaw in the default encryption layer (an implementation bug, a key-management mistake) is no longer backstopped by an independent second layer. (Azure behavior; authored assessment.) For workloads under regulatory or contractual double-encryption requirements, the account is simply non-compliant, and because the setting is creation-time only, fixing it means migrating data to a new account.

See it

resource sa 'Microsoft.Storage/storageAccounts@2023-05-01' = {
  name: 'corpdata001'
  location: location
  sku: { name: 'Standard_LRS' }
  kind: 'StorageV2'
  properties: {
    // requireInfrastructureEncryption omitted -> defaults to false
    // single default at-rest layer only
  }
}

resource sa 'Microsoft.Storage/storageAccounts@2023-05-01' = {
  name: 'corpdata001'
  location: location
  sku: { name: 'Standard_LRS' }
  kind: 'StorageV2'
  properties: {
    encryption: {
      requireInfrastructureEncryption: true   // second, independent at-rest layer
      services: {
        blob: { enabled: true }
        file: { enabled: true }
      }
    }
  }
}