CMK, Managed HSM & at-rest

Own the key, the rotation, and the kill switch.

All Azure data at rest is encrypted by default with platform-managed keys, so the security decision is whether you need to control the keys yourself. Customer-managed keys in Key Vault (or Managed HSM) are how you gain rotation control, access governance, and a revocation switch.

Platform keys vs CMK vs Managed HSM

Platform-managed keys are invisible and uncontrollable. Customer-managed keys (CMK) let you supply a Key Vault key for Storage, managed-disk, SQL TDE, and more — you own the rotation schedule, the access policy, and the ability to disable the key, which instantly makes the encrypted data unreadable. Managed HSM goes further: a single-tenant, FIPS 140-2 Level 3 hardware-backed pool for keys that must never leave certified hardware, the right choice for regulated workloads needing attestable custody. Infrastructure (double) encryption adds a second layer for the most sensitive data.

# Point a storage account at a customer-managed key in Key Vault.
az storage account update -g rg -n acmedata \
  --encryption-key-source Microsoft.Keyvault \
  --encryption-key-vault https://app-kv.vault.azure.net \
  --encryption-key-name storage-cmk --encryption-key-version ""   # "" = auto-follow rotations
 
# Rotating the key in Key Vault re-wraps the data key; existing data stays
# readable and no bulk re-encryption is needed (envelope encryption).

The control CMK actually buys

The point of CMK is not stronger cryptography — platform keys are already strong — it is governance: you can prove custody, rotate on your schedule, separate the key admin from the data admin, and revoke access by disabling the key during an incident. Under the hood it is envelope encryption, so rotating the key-encryption key re-wraps the data key without re-encrypting the data. For sovereignty regimes, Confidential Computing (encryption in use) and region/personnel controls extend the model to data in memory.