Skip to main content
emnode
Sign up
Compliance High severity MCSB DP-5

Microsoft Defender for Cloud · Azure Local

(Preview) Azure Local systems should have encrypted volumes

Written and reviewed by Emnode · Last reviewed

What does the recommendation "(Preview) Azure Local systems should have encrypted volumes" check?

Flags any Azure Local instance (formerly Azure Stack HCI) whose nodes do not report BitLocker encryption on their OS and data volumes. The recommendation advises using BitLocker to encrypt the boot and Cluster Shared Volumes that hold your infrastructure and workload data, and it surfaces that state through the Guest Configuration extension on the machines (its related policy is 'Guest Configuration extension should be installed on machines'), so the Microsoft Cloud Security Benchmark initiative must be applied before the status appears in Azure. This is a preview recommendation: it only assesses the on-premises Azure Local nodes, not Azure managed disks, not the guest VM operating-system disks running on the cluster, and not the older Azure Stack Hub product. It also will not detect a volume you encrypted with a non-BitLocker mechanism, because it only recognises the platform's own BitLocker status.

Why does "(Preview) Azure Local systems should have encrypted volumes" matter?

Azure Local nodes are physical servers that live in your own building, not in a hardened Azure datacentre, so a stolen, decommissioned or improperly disposed drive is a realistic path to your data. Without BitLocker, anyone who removes a disk can read every byte of the infrastructure and workload volumes in plain text, including tenant VMs, backups and credentials cached on disk. For regulated organisations that breaches the data-at-rest obligations in standards such as ISO 27001, PCI DSS and HIPAA, turning a recoverable hardware loss into a reportable data breach with the fines, customer notifications and audit findings that follow. Encryption is the one control that makes a lost drive a non-event rather than an incident, and on hardware you physically own it is the difference between a maintenance ticket and a board-level disclosure.

How do I fix "(Preview) Azure Local systems should have encrypted volumes"?

  1. Check the current state per volume with 'Get-ASBitLocker -VolumeType ClusterSharedVolume' (and '-VolumeType BootVolume') from an elevated PowerShell session on a node, so you know exactly which volumes are unprotected before you change anything.
  2. Enable encryption cluster-wide with 'Enable-ASBitLocker -VolumeType ClusterSharedVolume -Cluster' (which requires CredSSP), and 'Enable-ASBitLocker -VolumeType BootVolume -Cluster' where TPM 2.0 is present. Schedule a maintenance window: encrypting a CSV puts it in redirected mode and briefly pauses workload VMs.
  3. Back up the recovery keys off the system. Retrieve them with 'Get-AsRecoveryKeyInfo' and store them in a secure external location such as an Azure Key Vault, so a node that boots into recovery is never a dead end. Re-run 'Get-ASBitLocker' afterwards to confirm every volume now reports as encrypted.

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 "(Preview) Azure Local systems should have encrypted volumes" a false positive?

A brand-new instance can show as non-compliant before Microsoft Defender for Cloud's Foundational CSPM plan and the Microsoft Cloud Security Benchmark initiative are applied, because the BitLocker status is not yet surfaced to Azure even though deployment enables data-at-rest encryption by default. If 'Get-ASBitLocker' on the nodes already reports every boot and Cluster Shared Volume as fully encrypted, the volumes are protected and the finding is a reporting lag, not a real exposure. Suppress it only after you have confirmed the on-node state directly, never on the assumption that the default held.

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

More Azure Local controls