Virtual machines guest attestation status should be healthy

What does the recommendation "Virtual machines guest attestation status should be healthy" check?

Flags any Trusted Launch virtual machine whose latest guest attestation result is not healthy. The VM sends a signed measured-boot log (TCGLog) to the Azure Attestation service, which compares the recorded firmware, boot loader and kernel measurements against known-good values and returns a verdict. This control reads that verdict, not the configuration. It only applies to Trusted Launch VMs that already have the Guest Attestation extension installed, so it does not cover whether Secure Boot, vTPM or the extension are present in the first place: those gaps surface under the separate 'Guest Attestation extension should be installed' recommendations. It also does not inspect the running OS, installed packages or in-guest malware beyond what the boot chain measurements reveal.

Why does "Virtual machines guest attestation status should be healthy" matter?

An unhealthy attestation means the measured boot chain no longer matches a trusted state, which is exactly the signature a bootkit or rootkit leaves behind when it tampers with firmware, the boot loader or early kernel modules. That class of compromise survives reboots and reimaging of the OS disk and sits below the visibility of most endpoint agents, so without remote attestation it can run undetected for months. For a regulated workload that translates into an integrity breach you cannot evidence you would have caught, and a host you can no longer trust to process data. A healthy verdict is positive proof the VM booted the code you expect.

How do I fix "Virtual machines guest attestation status should be healthy"?

1. Confirm the prerequisites are in place, because attestation cannot pass without them: the VM must be Trusted Launch with Secure Boot and vTPM enabled. On an existing VM run 'az vm update --name <vm> --resource-group <rg> --enable-secure-boot true --enable-vtpm true', then deallocate and start the VM so the settings take effect.
2. Ensure the Guest Attestation extension is installed and can reach the service: enable integrity monitoring with 'az vm update --name <vm> --resource-group <rg> --enable-integrity-monitoring' (extension type 'GuestAttestation', publisher 'Microsoft.Azure.Security.LinuxAttestation' or 'Microsoft.Azure.Security.WindowsAttestation'), and allow outbound traffic to the 'AzureAttestation' service tag in any NSG or firewall, since a blocked endpoint reports as unhealthy.
3. If the prerequisites are correct and attestation still fails, treat it as a genuine integrity event: investigate the boot-chain failure details in the Defender for Cloud alert, and recreate the VM from a clean, known-good image rather than trying to clean the existing boot chain in place.

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