Virtual machines should encrypt temp disks, caches, and data flows between Compute and Storage resources

Written and reviewed by Emnode · Last reviewed 18 June 2026

What does the recommendation "Virtual machines should encrypt temp disks, caches, and data flows between Compute and Storage resources" check?

Flags any virtual machine that relies only on Azure's default platform server-side encryption (SSE) and does not have Azure Disk Encryption (ADE) enabled. Default SSE encrypts the managed OS and data disks at rest but leaves the temporary disk, the OS and data disk caches, and the data flowing between the VM host and the Storage cluster unencrypted. Important: this specific recommendation, backed by built-in policy 0961003e-5a0a-4549-abde-af6a37f2724d, only detects Azure Disk Encryption. It does not recognise encryption at host, so a VM that has only encryption at host enabled (and no ADE) still reports as Unhealthy here. Encryption at host is assessed by a separate recommendation, 'Virtual machines and virtual machine scale sets should have encryption at host enabled' (policy fc4d8e41-e223-45ea-9bf5-eada37891d87). This control also does not verify that you used a customer-managed key, that Key Vault is hardened, or that any unmanaged or ephemeral OS disks are covered.

Why does "Virtual machines should encrypt temp disks, caches, and data flows between Compute and Storage resources" matter?

Sensitive data routinely lands on exactly the surfaces default SSE skips: page files and swap on the temp disk, write-back disk caches, and the wire between Compute and Storage. An attacker with host-adjacent access or anyone who recovers a decommissioned temp disk can read that data in the clear. For regulated workloads this is a direct gap against PCI DSS, HIPAA and similar regimes that mandate end-to-end encryption, so a single unencrypted VM can fail an audit and stall a release. Both Azure Disk Encryption and encryption at host close the underlying exposure, but be aware that only ADE clears this particular recommendation; encryption at host is credited by its own separate recommendation instead.

How do I fix "Virtual machines should encrypt temp disks, caches, and data flows between Compute and Storage resources"?

For new and most existing VMs, prefer encryption at host: it covers temp disks, caches and Compute-to-Storage flows with no guest agent and no CPU cost. Register the feature once per subscription, then enable it with 'az vm update --name <vm> --resource-group <rg> --set securityProfile.encryptionAtHost=true' (the VM must be deallocated first). Note that enabling only encryption at host satisfies the underlying requirement but does not clear this recommendation; it is credited by the separate 'encryption at host' recommendation, so expect this one to stay flagged unless you also apply ADE.
Where you need in-guest encryption with your own keys, or where you specifically want to clear this recommendation, use Azure Disk Encryption, which applies BitLocker on Windows or DM-Crypt on Linux and stores secrets in Azure Key Vault: 'az vm encryption enable --name <vm> --resource-group <rg> --disk-encryption-keyvault <kv>'. Note Microsoft has set ADE for retirement on 15 September 2028, so favour encryption at host for anything new and accept that this specific recommendation may remain open.
To enforce a safe default at scale, do not assign the policy behind this recommendation: built-in policy 0961003e-5a0a-4549-abde-af6a37f2724d is deprecated (version 2.1.0-deprecated) and supports only the 'AuditIfNotExists' and 'Disabled' effects (default Disabled), so it can only audit. It cannot deploy, remediate or block. Microsoft now recommends the replacement policies 'Windows virtual machines should enable Azure Disk Encryption or EncryptionAtHost' (3dc5edcd-002d-444c-b216-e123bbfa37c0) and 'Linux virtual machines should enable Azure Disk Encryption or EncryptionAtHost' (ca88aadc-6e2b-416c-9de2-5a0f01d1693f), which audit either encryption layer and avoid the host-encryption false flag described above.

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 should encrypt temp disks, caches, and data flows between Compute and Storage resources" a false positive?

The most common over-flag here is a VM that already has encryption at host enabled but no Azure Disk Encryption. Its data is genuinely protected, yet this recommendation still reports it as Unhealthy, because the underlying policy (0961003e-5a0a-4549-abde-af6a37f2724d) only detects ADE. The fix is not to encrypt it again but to track that VM under the separate 'encryption at host' recommendation, or to assign the replacement 'Azure Disk Encryption or EncryptionAtHost' policies that credit either layer. Separately, a throwaway VM that stores no sensitive data and is rebuilt from code can be a deliberate exception; if you accept that risk, exempt the specific resource through a Defender for Cloud exemption rather than disabling the recommendation, so every other VM stays covered.

Full lesson Encrypt Azure data at rest, including customer-managed keys Step-by-step remediation with CLI, code and persona-specific context.

Defender for Cloud recommendations ↗ Check your own account →

Part of the learning path Encrypt across Azure