# Azure Storage Account Not Using Customer-Managed Key Encryption

> Azure encrypts every storage account at rest by default, so RC-1321 is about key ownership: the finding fires when encryption.keySource is Microsoft.Storage rather than Microsoft.Keyvault, meaning Microsoft, not your organisation, controls rotation and revocation. Frameworks like PCI-DSS and HIPAA often mandate customer-managed keys.

Source: https://zop.dev/integrations/azure/recommendations/azure-storage-account-not-using-customer-managed-key-encryption
Updated: 2026-08-19

---

## Key ownership, not missing encryption

Every Azure storage account is encrypted at rest, always, because service-side encryption cannot be turned off. So a finding from this rule does not mean data is sitting in plaintext. What it means is that the encryption key belongs to Microsoft: the account's `encryption.keySource` is `Microsoft.Storage`, the default, rather than `Microsoft.Keyvault`. Whoever holds the key decides when it rotates, who can use it, and, critically, when it stops working.

## What an auditor actually asks

Compliance frameworks such as PCI-DSS and HIPAA frequently require that the customer, not the cloud provider, control the encryption keys for regulated data. With a customer-managed key in Key Vault you gain three things a Microsoft-managed key cannot give you: rotation on your own schedule, an audit trail of every key operation in Key Vault's logs, and a revocation lever: disable the key and the account's data becomes cryptographically unreadable, which is the closest thing cloud storage has to a kill switch. If none of your accounts hold regulated data, this finding may be acceptable as-is; the rule reports posture, and only your compliance scope decides whether it matters.

## The rule fires on evidence, never absence

The discoverer stamps `cmk_enabled` on every storage account unconditionally, true or false, derived from the ARM `keySource` field. RC-1321 fires only on an explicit "false" and abstains when the key is missing, so the condition is proven from provider state rather than inferred. Interestingly, this rule was re-scoped from an earlier "encryption disabled" premise that was physically impossible on Azure and therefore permanently dormant. When present, a second flag, `infrastructure_encryption_enabled`, is surfaced as supporting evidence showing whether the platform's secondary "double encryption" layer is on; it is informational and never a firing condition.

## Inspect the key source

```bash
az storage account list \
  --query "[?encryption.keySource != 'Microsoft.Keyvault'].{name:name, rg:resourceGroup, keySource:encryption.keySource}" \
  -o table
```

## Moving an account to a CMK

Switch the encryption type to customer-managed keys in the account's Encryption blade, pick or create a Key Vault key, and grant the account's managed identity access to it. The change re-wraps the data encryption key without rewriting stored data. Severity is medium: no exposure exists today, but retrofitting key ownership across a fleet after an audit flags it is far slower than setting it per-account as you go.