Microsoft Defender for Cloud · Azure Local
Host and VM networking should be protected on Azure Local systems
Written and reviewed by Emnode · Last reviewed
What does the recommendation "Host and VM networking should be protected on Azure Local systems" check?
Flags Azure Local systems (formerly Azure Stack HCI) where data in transit on the host network and on virtual machine network connections is not protected. The underlying preview policy inspects the cluster's 'securityComplianceStatus.dataInTransitProtected' property, which reports whether SMB signing and encryption are enforced on external host traffic between cluster nodes and VM connections. It does not assess Network Security Groups, firewall rules, host firewall configuration or whether individual guest VMs encrypt their own application traffic. It is an audit-only check scoped to the Azure Local instance resource, not to the workloads running on it.
Why does "Host and VM networking should be protected on Azure Local systems" matter?
Azure Local clusters carry storage replication, live migration and management traffic over the same physical fabric as tenant VM networking. If that traffic is not signed and encrypted, an attacker with a foothold on the network can intercept or tamper with it: relay attacks, SMB downgrade and on-path modification of cluster data all become viable. For a platform that often runs in branch sites or factories with weaker physical controls, unprotected in-transit data is a direct route to data disclosure and integrity loss, and it undermines the regulatory posture (CIS and DISA STIG alignment) that Azure Local is meant to certify against. Because the same fabric handles east-west storage and migration traffic, a single unprotected link can expose far more than one workload, and the blast radius grows with every VM you place on the cluster.
How do I fix "Host and VM networking should be protected on Azure Local systems"?
- In Windows Admin Center, open the cluster, go to the Security extension, select the Azure Local system security settings and enable 'Signing for external SMB traffic' so host and VM network connections are protected in transit, then apply the change across all nodes.
- Confirm the resulting state by checking that the instance reports 'dataInTransitProtected' as compliant in Defender for Cloud, and keep the WDAC base policy in enforced mode and consistent across every node in the cluster so the security baseline is not partially applied.
- To enforce the control at scale, look the preview policy up by display name rather than pasting its GUID, then assign it: pid=$(az policy definition list --query "[?displayName=='[Preview]: Host and VM networking should be protected on Azure Local systems'].name" -o tsv); az policy assignment create --name protect-azlocal-networking --policy "$pid" --scope <subscription-or-mg-scope>.
Remediation script · bash
# Create one shared DDoS protection plan, then bring the internet-facing
# virtual networks under it. A single plan can be shared across every
# subscription in the tenant; its fixed monthly charge covers up to 100
# public IP addresses.
RG=net-hub-rg
LOC=uksouth
az network ddos-protection create \
--resource-group "$RG" \
--name ddos-plan-shared \
--location "$LOC"
for vnet in vnet-payments-prod vnet-web-prod; do
az network vnet update \
--resource-group "$RG" \
--name "$vnet" \
--ddos-protection true \
--ddos-protection-plan ddos-plan-shared
echo "$vnet: associated with shared DDoS Network Protection plan"
done
# Stand up a Premium Azure Firewall policy in the hub with IDPS and
# threat intelligence both in Deny mode (deploy the firewall + route
# 0.0.0.0/0 to its private IP from each spoke to complete the path).
az network firewall policy create \
--resource-group "$RG" \
--name hub-fw-policy \
--location "$LOC" \
--sku Premium \
--threat-intel-mode Deny \
--idps-mode Deny
# Ratchet it shut: assign the built-in policy that requires DDoS protection
# on virtual networks. Look the definition up by its exact display name so
# no GUID is hardcoded.
pid=$(az policy definition list \
--query "[?displayName=='Virtual networks should be protected by Azure DDoS Protection'].name" -o tsv)
az policy assignment create \
--name require-vnet-ddos \
--policy "$pid" \
--scope "/subscriptions/00000000-0000-0000-0000-000000000000" Full walkthrough (console steps, edge cases and verification) in the lesson Protect Azure networks with DDoS and firewalls.
Is "Host and VM networking should be protected on Azure Local systems" a false positive?
A lab or proof-of-concept Azure Local cluster running on an isolated, air-gapped management segment with no production data may legitimately leave the setting unconfigured while you validate hardware. It still flags, because the check reports the configured state of in-transit protection, not your risk acceptance. Document the exception and exclude that single instance from the assignment scope rather than disabling the policy organisation-wide.