Ensure Trusted Launch is enabled on Virtual Machines

Overview

When Secure Boot and vTPM are enabled together, they provide a strong foundation for protecting your VM from boot attacks. For example, if an attacker attempts to replace the bootloader with a malicious version, Secure Boot will prevent the VM from booting. If the attacker is able to bypass Secure Boot and install a malicious bootloader, vTPM can detect the intrusion and alert you.

Rationale

Secure Boot and vTPM work together to protect your VM from various boot attacks, including bootkits, rootkits, and firmware rootkits. Not enabling Trusted Launch in Azure VM can lead to increased vulnerability to rootkits and boot-level malware, reduced ability to detect and prevent unauthorized changes to the boot process, and a potential compromise of system integrity and data security.

Impact

Secure Boot and vTPM are not currently supported for Azure Generation 1 VMs.

IMPORTANT: Before enabling Secure Boot and vTPM on a Generation 2 VM that does not already have both enabled, it is highly recommended to create a restore point of the VM before remediation.

Remediation guidance

Remediate from Azure Portal

Go to Virtual Machines.
For each VM, under Settings, click on Configuration on the left blade.
Under Security Type, select 'Trusted Launch Virtual Machines'.
Make sure Enable Secure Boot & Enable vTPM are checked.
Click on Apply.

Note: Trusted launch on existing virtual machines (VMs) is currently not supported for Azure Generation 1 VMs

Multiple Remediation Paths

Azure

SERVICE-WIDE (RECOMMENDED when many resources are affected): Assign Azure Policy initiatives at management group/subscription scope and trigger remediation tasks.

az policy assignment create --name <assignment-name> --scope /subscriptions/<subscription-id> --policy-set-definition <initiative-id>
az policy remediation create --name <remediation-name> --policy-assignment <assignment-id>

ASSET-LEVEL: Apply the resource-specific remediation steps above to the listed non-compliant resources.

PREVENTIVE: Embed Azure Policy checks into landing zones and IaC workflows to block or auto-remediate drift.

References for Service-Wide Patterns

Azure Policy overview: https://learn.microsoft.com/en-us/azure/governance/policy/overview
Azure Policy remediation: https://learn.microsoft.com/en-us/azure/governance/policy/how-to/remediate-resources
Azure Policy initiative structure: https://learn.microsoft.com/en-us/azure/governance/policy/concepts/initiative-definition-structure

Operational Rollout Workflow

Use this sequence to reduce risk and avoid repeated drift.

1. Contain at Service-Wide Scope First (Recommended)

Azure: assign policy initiatives at management group/subscription scope and run remediation tasks.

az policy assignment create --name <assignment-name> --scope /subscriptions/<subscription-id> --policy-set-definition <initiative-id>
az policy remediation create --name <remediation-name> --policy-assignment <assignment-id>

2. Remediate Existing Affected Assets

Execute the control-specific Console/CLI steps documented above for each flagged resource.
Prioritize internet-exposed and production assets first.

3. Validate and Prevent Recurrence

Re-scan after each remediation batch.
Track exceptions with owner and expiry date.
Add preventive checks in IaC/CI pipelines.

Query logic

These are the stored checks tied to this control.

Azure VMs without boot security settings

Connectors

Microsoft Azure

Covered asset types

Expected check: eq []

{
  vms(
    where: {
      OR: [
        { securityProfileUefiSettingsSecureBootEnabled: false }
        { securityProfileUefiSettingsVTpmEnabled: false }
      ]
    }
  ) {
    ...AssetFragment
  }
}