# Azure VM Disk Encryption Not Enabled

> Every Azure managed disk is already encrypted at rest with a platform-managed key, so RC-1300 does not hunt for "unencrypted" disks. Instead the rule fires when no diskEncryptionSet is attached to the OS disk, a customer-managed-key gap relevant to PCI-DSS, HIPAA, and ISO 27001 key-control requirements. A secondary path covers ADE explicitly disabled.

Source: https://zop.dev/integrations/azure/recommendations/azure-vm-disk-encryption-not-enabled
Updated: 2026-08-19

---

## Encryption is not the question, key custody is

Azure's server-side encryption is always on: no managed disk exists unencrypted at rest. A
naive "disk encryption not enabled" check therefore flags nothing real, or worse, flags every
VM that hasn't layered guest-level encryption on top. The meaningful compliance question on
Azure is who controls the key. With a platform-managed key (PMK), Microsoft operates the
entire key lifecycle. With a customer-managed key (CMK) in Key Vault via a Disk Encryption
Set, your organisation controls rotation, access policy, and, decisively, revocation.
Frameworks like PCI-DSS, HIPAA, and ISO 27001 often require exactly that control.

## The two firing paths and the one abstain rule

The primary signal is `os_disk_cmk_enabled`, which the discoverer derives from whether a
`diskEncryptionSet` is attached to the OS disk's managed-disk properties. An explicit
`"false"` means PMK-only and fires the CMK-gap finding; any other value skips. The secondary
path catches `ade_enabled` set to `"false"`, meaning Azure Disk Encryption
(BitLocker/dm-crypt) explicitly turned off in ARM, which the discoverer only records when `encryptionSettings`
carries a literal false. Absent metadata always abstains: an earlier revision treated missing
`encryptionSettings` as "not encrypted" and false-flagged every non-ADE VM in the fleet,
because absent simply means ADE was never configured while SSE kept doing its job.

## Reading a disk's encryption type

```bash
az disk show -g <rg> -n <os-disk-name> \
  --query "{type:encryption.type, des:encryption.diskEncryptionSetId}"
```

`EncryptionAtRestWithPlatformKey` with a null DES confirms the PMK-only state this rule
flags; `EncryptionAtRestWithCustomerKey` clears it.

## Moving a disk onto your own key

Create a Key Vault key and a Disk Encryption Set backed by it, then attach:
`az disk update -g <rg> -n <disk> --disk-encryption-set <des-id>`. Unlike some cloud
encryption migrations, no data copy is required. Azure re-wraps the data-encryption key under
the new key hierarchy. Budget the operational side instead: a deleted or disabled Key Vault
key makes every disk under that DES unreadable, so key rotation and soft-delete policies
deserve more design time than the attachment itself. Detection is Reader-only; ZopNight
changes no key configuration.