Guest Attestation extension should be installed on supported Windows virtual machine scale sets

What does the recommendation "Guest Attestation extension should be installed on supported Windows virtual machine scale sets" check?

Flags any supported Windows virtual machine scale set that has Secure Boot and a virtual TPM enabled but is missing the Guest Attestation extension (publisher Microsoft.Azure.Security.WindowsAttestation, type GuestAttestation). With the extension present, Defender for Cloud can remotely attest that each instance booted a healthy, unmodified boot chain. It only evaluates Generation 2, Trusted Launch capable scale sets where vTPM is already on: it does not enable Secure Boot or vTPM for you, does not cover Linux scale sets or single VMs, and does not itself detect malware. A missing attestation extension means boot integrity is simply never measured, not that a rootkit was found.

Why does "Guest Attestation extension should be installed on supported Windows virtual machine scale sets" matter?

Secure Boot and vTPM measure the UEFI firmware, kernel and early drivers, but those measurements are worthless if nothing reads them. Without the Guest Attestation extension the scale set can be booting with a tampered loader or a kernel-level rootkit and you would have no signal at all. Boot-level implants survive OS reinstalls and sit below most agents, so they are exactly the persistence an attacker wants on a fleet that scales horizontally and is reimaged often. Installing the extension turns that silent blind spot into a continuous Defender for Cloud attestation, giving you a verifiable record that each instance came up clean.

How do I fix "Guest Attestation extension should be installed on supported Windows virtual machine scale sets"?

1. Confirm the scale set is Trusted Launch capable with Secure Boot and vTPM enabled, since the extension fails to attest without them: check the securityProfile uefiSettings on the model, and enable both before proceeding if they are off.
2. Install the extension on the scale set with 'az vmss extension set --resource-group <rg> --vmss-name <vmss> --name GuestAttestation --publisher Microsoft.Azure.Security.WindowsAttestation --version 1.0 --enable-auto-upgrade true', then roll the change to existing instances by upgrading the model so every node gains attestation.
3. To enforce this estate-wide, assign the built-in remediation policy by exact display name rather than a hardcoded GUID: pid=$(az policy definition list --query "[?displayName=='[Preview]: Configure supported Windows virtual machine scale sets to automatically install the Guest Attestation extension'].name" -o tsv); az policy assignment create --name install-ga-vmss --policy "$pid" --scope <scope>, so newly created scale sets are configured automatically.

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