(Enable if required) Storage accounts should use customer-managed key (CMK) for encryption

What does the recommendation "(Enable if required) Storage accounts should use customer-managed key (CMK) for encryption" check?

Flags any storage account whose encryption.keySource is still the default Microsoft.Storage (platform-managed keys) rather than Microsoft.Keyvault, meaning the account is not encrypting blobs and files under a key you hold in Azure Key Vault or Managed HSM. It does not check that data is encrypted at all: Azure Storage always encrypts data at rest with AES-256, so this is purely about who controls the key, not whether encryption exists. It also does not verify that your Key Vault has purge protection, soft delete or sensible key rotation, nor that the account's managed identity still has access to the key.

Why does "(Enable if required) Storage accounts should use customer-managed key (CMK) for encryption" matter?

With platform-managed keys, Microsoft owns the full key lifecycle, so you cannot independently rotate, revoke or cryptographically erase the data on your own schedule. For regulated workloads, contractual data-residency clauses or a need to prove a hard kill switch, that lack of control can be a genuine compliance gap rather than a technical weakness. Moving to a customer-managed key lets you revoke access to an entire account by disabling one key in Key Vault, and lets you satisfy auditors who require the organisation, not the provider, to hold the key encryption key. The flip side is real operational risk: lose or wrongly disable the key and the account's data becomes unreadable, which is exactly why this control is Low severity and gated behind 'Enable if required'.

How do I fix "(Enable if required) Storage accounts should use customer-managed key (CMK) for encryption"?

1. Decide whether you actually need CMK: the platform default already encrypts at rest, so only enable this where a policy, contract or data-residency rule demands you hold the key. If you do not, suppress the recommendation rather than adding key-management overhead you will not maintain.
2. Provision the key first: create a key in Azure Key Vault or Managed HSM with soft delete and purge protection enabled, then give the storage account a managed identity and grant it Get, Wrap Key and Unwrap Key permissions (or the Key Vault Crypto Service Encryption User role under RBAC) on that vault.
3. Switch the account over with 'az storage account update --encryption-key-source Microsoft.Keyvault --encryption-key-vault <vaultUri> --encryption-key-name <key> --encryption-key-version ""', leaving the version empty so Azure auto-tracks rotations, or set the equivalent encryption block in Bicep or Terraform so new accounts inherit it.

# 1. Free, universal fix: enable Transparent Data Encryption on a SQL database.
az sql db tde set \
  --resource-group rg-data \
  --server sql-fintech-prod \
  --database payments \
  --status Enabled

# 2. Free, universal fix: encrypt VM temp disks, caches and data flows.
az feature register --namespace Microsoft.Compute --name EncryptionAtHost
az vm deallocate --resource-group rg-app --name vm-tooling-01
az vm update --resource-group rg-app --name vm-tooling-01 \
  --set securityProfile.encryptionAtHost=true
az vm start --resource-group rg-app --name vm-tooling-01

# 3. Only where required: customer-managed key on a storage account.
az storage account update \
  --name stbankingprod \
  --resource-group rg-data \
  --encryption-key-source Microsoft.Keyvault \
  --encryption-key-vault "https://kv-banking-cmk.vault.azure.net" \
  --encryption-key-name sa-cmk

echo "TDE on, host encryption on, CMK applied to the one regulated store."