Security · Medium severity

Azure Storage Account Not Using Customer-Managed Key Encryption

Encryption keys are held entirely by the platform, so you cannot revoke access to the data independently or evidence key custody to an auditor.

Free to start. No card. The playground just needs your work email.

Azureprovider

Mediumseverity

Riskwhere it shows up

Manualfix, steps written out

Azure

Found, explained, handed over.

Exposure and fragility, security posture and single points of failure.

ZopNight checks this automatically across Azure, with read-only access to the account.

Every finding says exactly what to change: Use a customer-managed key for storage account.

The finding opens with the fix already written out, step by step, so it is one ticket, not an investigation.

Applies to

Storage Accounts on Azure

The fix, by hand

Storage account → the resource → Security + networking → Encryption.
Confirm Encryption type = Microsoft-managed keys (default; already SSE on at rest).
For higher compliance, switch to Customer-managed keys; pick or create a Key Vault key with soft-delete + purge protection enabled.
Enable Infrastructure encryption for a second layer (must be set at account creation; for existing accounts plan a migration).
Verify the active key version in the Encryption blade after the change.

These are the steps the finding carries in the product.

Category

Security. Risky configurations: privileged containers, containers running as root, host networking, ingress without TLS.

Where it appears

The Risk tab of Recommendations, with every affected resource listed.

Rule ID

RC-1321

Full reference

Connect a read-only role and the first pass runs on your own estate. This check, and the rest of the catalogue, with it.

Prefer to talk it through first? Book 20 minutes with the team.

Figures published on zop.dev.