Linux virtual machines should use Secure Boot

What does the recommendation "Linux virtual machines should use Secure Boot" check?

Flags any in-scope Linux VM that is not running with Secure Boot enabled. This is an in-guest assessment: it only applies to Linux virtual machines that have the Azure Monitor Agent installed, and it inspects the boot state reported from inside the guest rather than reading an Azure resource property. Secure Boot is delivered through Trusted Launch on a generation 2, UEFI-based VM, where it is turned on by setting securityType to TrustedLaunch and secureBootEnabled to true under uefiSettings, but the recommendation reports against what the agent observes the machine actually doing, not just the platform flag. It is one of a family of Trusted Launch checks and does not cover the companion features that round out the posture, namely vTPM, boot integrity monitoring and guest attestation, each of which has its own recommendation. Linux VMs without the Azure Monitor Agent, generation 1 VMs, and images that do not support Trusted Launch fall outside its scope rather than failing, because the assessment cannot collect a result or Secure Boot cannot be applied without first moving to a UEFI, Trusted Launch capable VM.

Why does "Linux virtual machines should use Secure Boot" matter?

Without Secure Boot the firmware will load any boot loader, kernel or driver regardless of who signed it, which is exactly the gap rootkits and bootkits exploit to persist beneath the operating system. Malware that takes hold in the boot chain survives a reinstall, hides from in-guest agents and antivirus, and is expensive and slow to evict because the trusted base it should rest on is itself compromised. Secure Boot establishes a cryptographic root of trust in the platform firmware and rejects unsigned or tampered boot components before the kernel even runs, so a poisoned image, a supply-chain compromise or a malicious driver cannot quietly establish persistence at the most privileged layer. The business consequence of skipping it is concrete: a fleet of VMs without this baseline is a finding auditors will raise against the Microsoft cloud security benchmark, a control gap that weakens your defence in depth, and a low-noise foothold an attacker will prize precisely because so few tools can see it.

How do I fix "Linux virtual machines should use Secure Boot"?

1. Confirm the VM is generation 2 and UEFI based, then deallocate it so the security profile can change: 'az vm deallocate --resource-group <rg> --name <vm>'.
2. Enable Trusted Launch with Secure Boot: 'az vm update --resource-group <rg> --name <vm> --security-type TrustedLaunch --enable-secure-boot true --enable-vtpm true'; the update triggers a reboot, so plan a maintenance window.
3. Enforce the baseline going forward by assigning the built-in policy by its display name rather than a hardcoded id: 'pid=$(az policy definition list --query "[?displayName=='Linux virtual machines should use Secure Boot'].name" -o tsv); az policy assignment create --name require-linux-secure-boot --policy "$pid" --scope <scope>', and create new VMs with securityType TrustedLaunch in your Bicep or Terraform modules so the safe setting is the default.

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