Storage accounts encrypting data with Microsoft-managed keys instead of a key you control

Encryption is on either way; the question is who holds the key

Every storage account is encrypted at rest. The storage encryption overview says Azure Storage encryption uses 256-bit AES, is enabled for all accounts, and cannot be disabled. New accounts use Microsoft-managed keys by default, which Microsoft rotates according to its own compliance requirements.

What changes with a customer-managed key is control. The customer-managed keys overview explains that Azure Storage wraps the account’s root encryption key with your key in Azure Key Vault or Key Vault Managed HSM. You decide when the key rotates, and disabling the key revokes access: reads and writes then fail with a 403 error until you restore it. Frameworks that ask for customer control over encryption keys are looking for exactly this.

Listing the key source of each account

az storage account list \
  --query "[].{name:name, rg:resourceGroup, keySource:encryption.keySource, infraEncryption:encryption.requireInfrastructureEncryption}" \
  -o table

Microsoft.Storage means Microsoft-managed keys; Microsoft.Keyvault means a customer-managed key.

The single setting this check reads

ZopNight reads the account’s encryption key source and raises a finding only when it is present and is not Microsoft.Keyvault. The recommendation also reports whether infrastructure encryption, a second layer of encryption at the infrastructure level, is on, as supporting evidence. That value does not affect whether the finding is raised.

Accounts with no finding

Accounts already on a customer-managed key are compliant. When the key source cannot be read, the account is not flagged; ZopNight does not treat missing data as a failure. This rule does not judge encryption scopes set on individual containers, only the account-level key.

A compliance finding with no dollar figure

There is no saving here and none is shown. Moving to a customer-managed key adds work rather than removing cost: a key vault to run, a key rotation process, and a managed identity to keep healthy. The value is audit evidence and the ability to revoke access to the data yourself.

Switching the account to a customer-managed key

1. Prepare a key vault or Managed HSM that meets Microsoft’s requirements: soft delete and purge protection enabled, and an RSA or RSA-HSM key of 2048, 3072 or 4096 bits.
2. Give the account’s managed identity at least the get, wrapkey and unwrapkey key permissions.
3. Point the account at the key, for example az storage account update --resource-group my-rg --name mystorageacct --encryption-key-source Microsoft.Keyvault --encryption-key-vault https://my-vault.vault.azure.net --encryption-key-name my-key --key-vault-user-identity-id <identity-resource-id>.
4. Confirm the key source now reads Microsoft.Keyvault.