Secure Boot should be enabled on supported Windows virtual machines

What does the recommendation "Secure Boot should be enabled on supported Windows virtual machines" check?

Audits Trusted Launch enabled Generation 2 Windows VMs and flags any where 'secureBootEnabled' under securityProfile.uefiSettings is not set to true. Secure Boot validates the UEFI signature of every bootloader, kernel and boot driver against trusted certificates, so only signed components run at start-up. The control only looks at the Secure Boot flag: it does not check that vTPM or boot integrity monitoring is on, and it ignores Generation 1 VMs, Linux VMs and any VM that has never been moved to a Trusted Launch security type, because those cannot host the setting at all.

Why does "Secure Boot should be enabled on supported Windows virtual machines" matter?

Without Secure Boot a rootkit or bootkit can tamper with the boot chain and load before the operating system and its security agents, giving an attacker persistence that survives reboots and reimaging and is invisible to anti-malware running inside the guest. That turns a single compromised VM into a long-lived foothold and, on regulated workloads, into a reportable control failure during audit. Turning Secure Boot on closes the gap cheaply: the platform refuses to boot unsigned or modified boot components, so the most durable class of compromise simply cannot start.

How do I fix "Secure Boot should be enabled on supported Windows virtual machines"?

1. Confirm the VM is Generation 2 and is using custom-signed kernels or drivers nowhere, because Secure Boot blocks unsigned boot components. Stop and deallocate the VM first, as the security type cannot change while it is running.
2. Set the security type to Trusted Launch and enable Secure Boot, for example 'az vm update --resource-group <rg> --name <vm> --security-type TrustedLaunch --enable-secure-boot true --enable-vtpm true', then start the VM. In Bicep, set 'securityProfile.securityType' to 'TrustedLaunch' and 'securityProfile.uefiSettings.secureBootEnabled' to true.
3. To enforce the setting at scale, assign the built-in policy by its exact display name rather than a hardcoded GUID: pid=$(az policy definition list --query "[?displayName=='[Preview]: Secure Boot should be enabled on supported Windows virtual machines'].name" -o tsv) then 'az policy assignment create --name require-secure-boot --policy "$pid" --scope <scope>'. Note this is an audit-only preview policy, so it reports non-compliance but does not remediate.

# 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"