Azure Local machine(s) should meet Secured-core requirements

What does the recommendation "Azure Local machine(s) should meet Secured-core requirements" check?

Audits each physical machine in an Azure Local instance (formerly Azure Stack HCI) for the Secured-core server hardware and firmware features: TPM 2.0 as a hardware root of trust, UEFI Secure Boot, virtualisation-based security (VBS), hypervisor-enforced code integrity (HVCI), System Guard with Dynamic Root of Trust for Measurement (DRTM), and the IOMMU-backed kernel DMA protection. The check reads the 'securedCoreCompliance' state reported by the host through Defender for Cloud, so it tells you whether every node satisfies the baseline, not just one. It does not verify your guest VMs, your Arc-enabled servers elsewhere, or BitLocker volume encryption, those are separate controls. The policy behind it ('Azure Stack HCI servers should meet Secured-core requirements', definition 5e6bf724-0154-49bc-985f-27b2e07e636b) runs as AuditIfNotExists and is still in Preview, so it reports but never blocks.

Why does "Azure Local machine(s) should meet Secured-core requirements" matter?

Azure Local nodes run your on-premises virtualisation fabric, so a compromised host means every workload on it is exposed. Without Secured-core, a firmware rootkit or unsigned kernel driver can persist beneath the operating system where antivirus cannot see it and survive a reinstall. Secure Boot, HVCI and DRTM close that gap by measuring and attesting the boot chain and refusing to execute unsigned code in the kernel. For a regulated business this is often a hard requirement: losing the hardware root of trust can fail a PCI DSS or sovereignty assessment and force unplanned hardware spend mid-audit, because the only remediation for missing features may be a BIOS update or a node replacement.

How do I fix "Azure Local machine(s) should meet Secured-core requirements"?

1. On each node enable the firmware prerequisites in BIOS/UEFI: TPM 2.0, Secure Boot, the CPU virtualisation extensions (Intel VT-x or AMD-V) and IOMMU (Intel VT-d or AMD-Vi). These cannot be set from Azure and must be done per machine before the software features will turn on.
2. Turn on the Secured-core software features through the security baseline. Use the AzureStackOSConfigAgent cmdlets on the cluster, for example 'Enable-AzSSecurity -FeatureName HVCI' and 'Enable-AzSSecurity -FeatureName DRTM', or enable them in the Windows Admin Center Security tool under Secured-core. Drift control then refreshes these settings roughly every 90 minutes to keep nodes in the known-good state.
3. Assign the audit policy at the resource group or subscription scope so new nodes are tracked automatically, looking the definition up by name rather than hardcoding the GUID: pid=$(az policy definition list --query "[?displayName=='[Preview]: Azure Stack HCI servers should meet Secured-core requirements'].name" -o tsv); az policy assignment create --name secured-core-audit --policy "$pid" --scope <scope>

# Upgrade one VM in place to a verified boot chain.
# Secure Boot + vTPM is a security-profile change, so the VM must be deallocated first.
RG="workloads-rg"
VM="payments-api-prod"

az vm deallocate --resource-group "$RG" --name "$VM"

az vm update --resource-group "$RG" --name "$VM" \
  --security-type TrustedLaunch \
  --enable-secure-boot true \
  --enable-vtpm true

az vm start --resource-group "$RG" --name "$VM"

# Install the guest attestation extension so Defender can read the boot remotely.
# Publisher is Microsoft.Azure.Security.LinuxAttestation for Linux,
# Microsoft.Azure.Security.WindowsAttestation for Windows.
az vm extension set \
  --resource-group "$RG" --vm-name "$VM" \
  --name GuestAttestation \
  --publisher Microsoft.Azure.Security.LinuxAttestation \
  --enable-auto-upgrade true

# Ratchet it shut: audit any future machine that lacks Secure Boot.
# Look the built-in policy up by its exact display name; never paste a guessed GUID.
pid=$(az policy definition list \
  --query "[?displayName=='Secure Boot should be enabled on supported Windows virtual machines'].name" -o tsv)

az policy assignment create \
  --name audit-secure-boot \
  --policy "$pid" \
  --scope "/subscriptions/00000000-0000-0000-0000-000000000000"