Storage accounts encrypted with Microsoft-managed keys instead of CMK
What does ZopNight detect here?
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.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1321 |
| Category | security |
| Severity | medium |
| Metric | none — pure configuration read |
| Source | storage_encryption.go |
Where it applies
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
az storage account list \ --query "[?encryption.keySource != 'Microsoft.Keyvault'].{name:name, rg:resourceGroup, keySource:encryption.keySource}" \ -o tableMoving 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.