Guest Attestation extension should be installed on supported Windows virtual machines

Written and reviewed by Emnode · Last reviewed 18 June 2026

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

Flags any Trusted Launch or Confidential Windows VM that has Secure Boot and vTPM enabled but is missing the GuestAttestation extension (publisher Microsoft.Azure.Security.WindowsAttestation, type GuestAttestation). With the extension present, Defender for Cloud can remotely attest the boot chain (UEFI, OS loader, kernel and drivers) measured by the vTPM. It only assesses whether the extension is installed and reporting: it does not check whether attestation is currently passing, nor does it apply to standard (non Trusted Launch) VMs, Linux VMs, or scale sets, which are covered by separate recommendations. This is an audit-only control and never installs the extension for you.

Why does "Guest Attestation extension should be installed on supported Windows virtual machines" matter?

Secure Boot and vTPM measure the boot sequence, but without the attestation extension nobody is reading those measurements, so a rootkit or bootkit that subverts the boot chain leaves no signal in Defender for Cloud. The extension closes that gap by sending the vTPM evidence to an Azure Attestation endpoint, giving you a remotely verifiable, tamper-evident record that each VM booted in a healthy state. For regulated workloads that depend on platform integrity, an unattested fleet means you cannot actually prove the assurance you are claiming, which is the kind of gap that surfaces in an audit rather than in a console alert.

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

Confirm the VM is Trusted Launch with Secure Boot and vTPM both enabled, since the extension cannot install otherwise: 'az vm show -g <rg> -n <vm> --query "securityProfile"'. If integrity monitoring is off, turn it on with 'az vm update -g <rg> -n <vm> --enable-integrity-monitoring', which installs the GuestAttestation extension.
To install the extension directly on an existing VM, run 'az vm extension set -g <rg> --vm-name <vm> -n GuestAttestation --publisher Microsoft.Azure.Security.WindowsAttestation --enable-auto-upgrade true', or in Bicep declare a Microsoft.Compute/virtualMachines/extensions resource with publisher 'Microsoft.Azure.Security.WindowsAttestation', type 'GuestAttestation' and enableAutomaticUpgrade set to true.
Enforce it at scale by assigning the built-in audit policy. Look the definition up by display name so you never hardcode a GUID: 'pid=$(az policy definition list --query "[?displayName=='\''[Preview]: Guest Attestation extension should be installed on supported Windows virtual machines'\''].name" -o tsv)' then 'az policy assignment create --name guest-attest-win --policy "$pid" --scope <scope>'.

Remediation script · bash

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

Full walkthrough (console steps, edge cases and verification) in the lesson Enable secure boot and attestation.

Is "Guest Attestation extension should be installed on supported Windows virtual machines" a false positive?

If a network security group or firewall blocks outbound traffic to the AzureAttestation service tag, the extension can install but provisioning fails, so the VM may still flag even though you have done the right thing. The correct fix is not to suppress the recommendation but to add an outbound rule allowing the AzureAttestation service tag, then let attestation report. A genuine deliberate exception is a Trusted Launch VM intentionally kept air-gapped from the attestation endpoint for a sensitive isolated workload: exclude that single resource from the policy assignment and record why, rather than leaving the finding silently unaddressed.

Full lesson Enable secure boot and attestation Step-by-step remediation with CLI, code and persona-specific context.

Defender for Cloud recommendations ↗ Check your own account →

Part of the learning path Manage Azure posture and patching