Microsoft Defender for Cloud · Virtual Machines
Virtual machines and virtual machine scale sets should have encryption at host enabled
Written and reviewed by Emnode · Last reviewed
What does the recommendation "Virtual machines and virtual machine scale sets should have encryption at host enabled" check?
Flags any virtual machine or virtual machine scale set where the 'securityProfile.encryptionAtHost' property is not set to true. Encryption at host encrypts the temporary disk, the ephemeral OS disk and the OS and data disk caches at rest on the physical host, and keeps that data encrypted as it flows to the Storage service. It is a separate control from Azure Disk Encryption, which encrypts the guest volumes from inside the VM using BitLocker on Windows or dm-crypt on Linux, so a VM can pass guest-level encryption and still flag here. The check covers only the at-rest, host-side layer: it does not verify in-guest encryption, network encryption or whether a customer-managed key is used rather than a platform-managed one.
Why does "Virtual machines and virtual machine scale sets should have encryption at host enabled" matter?
By default Azure server-side encryption protects the persisted managed disks, but the temporary disk and the disk caches that sit on the host are left unencrypted. Sensitive data routinely lands in those places: page and swap files, scratch space and cached blocks of the OS and data disks. Anyone able to recover that host-side storage could read application data and secrets that the organisation believed were encrypted everywhere. Enabling encryption at host closes that gap end to end without consuming guest CPU, which matters for regulated workloads where 'encrypted at rest' has to mean every surface, not just the persisted disk. The business consequence of leaving it off is a data-at-rest control that quietly has a hole in it, the kind auditors and breach investigators find after the fact.
How do I fix "Virtual machines and virtual machine scale sets should have encryption at host enabled"?
- Register the feature once per subscription before it can be used: 'az feature register --namespace Microsoft.Compute --name EncryptionAtHost', wait for the state to read Registered, then 'az provider register --namespace Microsoft.Compute' to propagate it.
- Enable it on the resource. For an existing VM it must be deallocated first: 'az vm deallocate -g <rg> -n <vm>' then 'az vm update -g <rg> -n <vm> --set securityProfile.encryptionAtHost=true'. For a scale set use 'az vmss update -g <rg> -n <vmss> --set virtualMachineProfile.securityProfile.encryptionAtHost=true' and roll the instances. New VMs can set it at create time with the '--encryption-at-host true' flag.
- Make it the default in templates: in Bicep set 'securityProfile: { encryptionAtHost: true }' on Microsoft.Compute/virtualMachines (and under virtualMachineProfile for scale sets) so every new deployment is covered. To enforce it estate-wide, assign the built-in audit policy by display name rather than a hardcoded GUID: pid=$(az policy definition list --query "[?displayName=='Virtual machines and virtual machine scale sets should have encryption at host enabled'].name" -o tsv); az policy assignment create --name eah-audit --policy "$pid" --scope <scope>.
Remediation script · bash
# 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." Full walkthrough (console steps, edge cases and verification) in the lesson Encrypt Azure data at rest, including customer-managed keys.
Is "Virtual machines and virtual machine scale sets should have encryption at host enabled" a false positive?
Encryption at host is supported on Ultra disks and Premium SSD v2 disks (generally available since November 2023), so a flag on those disk types is not a false positive and should be remediated, not excepted. The one caveat for those disk types is a sector-size one: a disk using a 512e sector size must have been created after 13 May 2023, so an older 512e disk needs a snapshot-and-recreate before encryption at host can be enabled. A separate feature, double encryption at rest, genuinely is not supported on Ultra or Premium SSD v2, but that is not what this recommendation checks. Encryption at host also cannot be combined with Azure Disk Encryption on the same VM, so a VM currently or previously using Azure Disk Encryption must move off it before encryption at host can be enabled.
More Virtual Machines controls
- Adaptive application controls for defining safe applications should be enabled on your machines
- Allow list rules in your adaptive application control policy should be updated
- Authentication to Linux machines should require SSH keys
- Azure Backup should be enabled for virtual machines
- EDR configuration issues should be resolved on virtual machines
- EDR solution should be installed on Virtual Machines
- File integrity monitoring should be enabled on machines
- Guest Attestation extension should be installed on supported Linux virtual machines
- Guest Attestation extension should be installed on supported Windows virtual machines
- Linux virtual machines should enable Azure Disk Encryption or EncryptionAtHost
- Linux virtual machines should enforce kernel module signature validation
- Linux virtual machines should use only signed and trusted boot components