Linux virtual machines should use only signed and trusted boot components

What does the recommendation "Linux virtual machines should use only signed and trusted boot components" check?

Flags Trusted Launch Linux VMs where Microsoft Defender for Cloud's guest attestation has detected one or more OS boot components (boot loader, kernel or a kernel driver) that are not signed by a trusted publisher. The check reads attestation telemetry from the VM's vTPM, so it only evaluates machines that already have Secure Boot, vTPM and the Guest Attestation extension in place. It does not turn Trusted Launch on, does not cover Windows VMs, and is a separate finding from 'Guest Attestation extension should be installed', which fires earlier when the extension is missing.

Why does "Linux virtual machines should use only signed and trusted boot components" matter?

An unsigned component in the boot chain is the signature of a bootkit or rootkit: malware that loads before the kernel and the security stack, so it survives reboots and reimaging and stays invisible to ordinary endpoint tooling. Because attestation measures the whole boot path against trusted publishers, an untrusted component here means either a real early-boot compromise or an unsanctioned out-of-tree driver that nobody has reviewed. Left unresolved it undermines every later defence on that host: disk encryption, EDR and patch state all assume the kernel underneath them is honest. In a regulated estate it also breaks the secure-configuration baseline auditors expect from a Trusted Launch fleet, and because the severity is low it is easy to ignore until an incident forces the question of how far back the compromise reaches.

How do I fix "Linux virtual machines should use only signed and trusted boot components"?

1. Open the recommendation in Defender for Cloud and read the attested boot log to see exactly which component failed: confirm whether it is a known, intentionally installed driver or genuinely unexpected, and if unexpected treat the VM as potentially compromised and isolate it.
2. For a legitimate component, get it signed by a trusted publisher (or rebuild from a signed image) so it passes Secure Boot; for an unwanted one, remove it and reboot so guest attestation re-measures a clean chain.
3. Enforce the baseline fleet-wide by assigning the built-in policy at the subscription scope: pid=$(az policy definition list --query "[?displayName=='[Preview]: Linux virtual machines should use only signed and trusted boot components'].name" -o tsv); az policy assignment create --name signed-boot-linux --policy "$pid" --scope /subscriptions/<sub-id>. The policy is AuditIfNotExists, so it reports drift rather than blocking boots.

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