Azure Cosmos DB accounts should use customer-managed keys to encrypt data at rest

What does the recommendation "Azure Cosmos DB accounts should use customer-managed keys to encrypt data at rest" check?

Flags any Azure Cosmos DB account whose data at rest is encrypted only with the platform-managed (service-managed) key rather than a customer-managed key (CMK) held in your own Azure Key Vault. The check passes once the account carries a 'keyVaultKeyUri' that points at a key you control. It looks only at the account-level encryption key for the database engine: it does not assess key rotation cadence, the Key Vault's own soft-delete or purge-protection settings, network exposure of the account, or backups, each of which is governed by separate recommendations. By default this control is not assessed, because all Cosmos DB data is already encrypted at rest with a Microsoft-managed key, so it surfaces only where a regulatory or internal policy requires you to own the key.

Why does "Azure Cosmos DB accounts should use customer-managed keys to encrypt data at rest" matter?

With the default service-managed key, Microsoft holds the encryption key and you cannot independently revoke it, prove key custody to an auditor, or sever access during an incident. A customer-managed key moves that control to your Key Vault: you set the rotation schedule, you hold the audit trail, and revoking or disabling the key renders the account's data unreadable on demand. For organisations under PCI DSS, HIPAA or similar regimes, the ability to demonstrate sole custody of the key and to cryptographically shred data by destroying it is often a hard contractual or legal requirement. Without CMK, a data-residency or key-revocation obligation simply cannot be satisfied, which can block a launch or fail an audit.

How do I fix "Azure Cosmos DB accounts should use customer-managed keys to encrypt data at rest"?

1. Create or pick an Azure Key Vault key with soft-delete and purge protection enabled, then grant the Azure Cosmos DB principal the Get, Unwrap Key and Wrap Key key permissions on the vault (via access policy or the equivalent RBAC role) so the service can use your key.
2. Apply the key to the account by setting its key URI: 'az cosmosdb update --name <account> --resource-group <rg> --key-uri https://<vault>.vault.azure.net/keys/<key>'. CMK can now be enabled on existing accounts as well as at creation time; allow time for the account to re-key.
3. Assign the built-in audit policy by display name so new accounts are caught: pid=$(az policy definition list --query "[?displayName=='Azure Cosmos DB accounts should use customer-managed keys to encrypt data at rest'].name" -o tsv); az policy assignment create --name cosmos-cmk --policy "$pid" --scope <scope>.

# 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."