Trusted Launch for Azure virtual machines

Applies to: ✔️ Linux VMs ✔️ Windows VMs ✔️ Flexible scale sets ✔️ Uniform scale sets

Azure Trusted Launch provides an easy way to improve the security of Generation 2 virtual machines (VMs). Trusted Launch protects against advanced and persistent attack techniques by providing enhanced protection against bootkits, rootkits, and low-level malware attacks. It uses several coordinated infrastructure technologies that you can enable independently. Each technology adds another layer of defense against sophisticated threats.

Trusted Launch is supported for both x64 and Arm64 architectures.

Benefits

• Securely deploy VMs with verified boot loaders, operating system (OS) kernels, and drivers.
• Securely protect keys, certificates, and secrets in the VMs.
• Gain insights and confidence of the entire boot chain's integrity.
• Ensure that workloads are trusted and verifiable.

Virtual machines sizes

¹Arm64 Cobalt 100-based sizes that support Trusted Launch.

²HBv2-series is currently supported for Trusted Launch but is scheduled for retirement on May 31, 2027. For new HPC Trusted Launch deployments, prefer HBv5-series, HX-series, HBv4-series, or HBv3-series sizes.

³HC-series sizes (Standard_HC44rs, Standard_HC44-16rs, Standard_HC44-32rs) are scheduled for retirement on May 31, 2027. After this date, remaining HC-series VMs will be deallocated and stop incurring charges, and HC-series will no longer have SLA or support. Sales of 1-year and 3-year Reserved Instances ended April 2, 2026. For new HPC Trusted Launch deployments, consider HBv5-series for higher performance and better price-performance, or HX-series for high-memory HPC workloads. Plan to transition off HC-series well before the retirement date to avoid disruption.

Operating systems supported

* Variations of this OS are supported.

More information

Regions:

• All public regions
• All Azure Government regions
• All Azure China regions

Pricing: Trusted Launch doesn't increase existing VM pricing costs.

Unsupported features

Currently, the following VM features aren't supported with Trusted Launch:

• Managed Image (customers are encouraged to use Azure Compute Gallery).
• Linux VM Hibernation

Secure Boot

At the root of Trusted Launch is Secure Boot for your VM. Secure Boot, which is implemented in platform firmware, protects against the execution of malware-based rootkits and boot kits. Secure Boot works to ensure that only signed operating systems and drivers can boot. It establishes a "root of trust" for the software stack on your VM.

With Secure Boot enabled, all OS boot components (boot loader, kernel, kernel drivers) require trusted publishers signing. Both Windows and major Linux distributions support Secure Boot. If Secure Boot fails to authenticate that the image is signed by a trusted publisher, the VM fails to boot. For more information, see Secure Boot.

vTPM

Trusted Launch also introduces virtual Trusted Platform Module (vTPM) for Azure VMs. This virtualized version of a hardware Trusted Platform Module is compliant with the TPM2.0 spec. It serves as a dedicated secure vault for keys and measurements.

Trusted Launch provides your VM with its own dedicated TPM instance that runs in a secure environment outside the reach of any VM. The vTPM enables attestation by measuring the entire boot chain of your VM (UEFI, OS, system, and drivers).

Trusted Launch uses the vTPM to perform remote attestation through the cloud. Attestations enable platform health checks and are used for making trust-based decisions. As a health check, Trusted Launch can cryptographically certify that your VM booted correctly.

If the process fails, possibly because your VM is running an unauthorized component, Microsoft Defender for Cloud issues integrity alerts. The alerts include details on which components failed to pass integrity checks.

Virtualization-based security

Virtualization-based security (VBS) uses the hypervisor to create a secure and isolated region of memory. Windows uses these regions to run various security solutions with increased protection against vulnerabilities and malicious exploits. Trusted Launch lets you enable hypervisor code integrity (HVCI) and Windows Defender Credential Guard.

HVCI is a powerful system mitigation that protects Windows kernel-mode processes against injection and execution of malicious or unverified code. It checks kernel mode drivers and binaries before they run, preventing unsigned files from loading into memory. Checks ensure that executable code can't be modified after it's allowed by HVCI to load. For more information about VBS and HVCI, see Virtualization-based security and hypervisor-enforced code integrity.

With Trusted Launch and VBS, you can enable Windows Defender Credential Guard. Credential Guard isolates and protects secrets so that only privileged system software can access them. It helps prevent unauthorized access to secrets and credential theft attacks, like Pass-the-Hash attacks. For more information, see Credential Guard.

Microsoft Defender for Cloud integration

Trusted Launch is integrated with Defender for Cloud to ensure that your VMs are properly configured. Defender for Cloud continually assesses compatible VMs and issues relevant recommendations:

• Recommendation to enable Secure Boot: The Secure Boot recommendation only applies for VMs that support Trusted Launch. Defender for Cloud identifies VMs that have Secure boot disabled. It issues a low-severity recommendation to enable it.

• Recommendation to enable vTPM: If vTPM is enabled for VM, Defender for Cloud can use it to perform guest attestation and identify advanced threat patterns. If Defender for Cloud identifies VMs that support Trusted Launch with vTPM disabled, it issues a low-severity recommendation to enable it.

• Recommendation to install guest attestation extension: If your VM has Secure Boot and vTPM enabled but it doesn't have the Guest Attestation extension installed, Defender for Cloud issues low-severity recommendations to install the Guest Attestation extension on it. This extension allows Defender for Cloud to proactively attest and monitor the boot integrity of your VMs. Boot integrity is attested via remote attestation.

• Attestation health assessment or boot integrity monitoring: If your VM has Secure Boot and vTPM enabled and the Attestation extension installed, Defender for Cloud can remotely validate that your VM booted in a healthy way. This practice is known as boot integrity monitoring. Defender for Cloud issues an assessment that indicates the status of remote attestation.

  If your VMs are properly set up with Trusted Launch, Defender for Cloud can detect and alert you of VM health problems.

• Alert for VM attestation failure: Defender for Cloud periodically performs attestation on your VMs. The attestation also happens after your VM boots. If the attestation fails, it triggers a medium-severity alert.

  Note

  VM client boot attestation alerts surfaced in Microsoft Defender for Cloud are informational and are not currently presented in the Defender portal.

  VM attestation can fail for the following reasons:

  • The attested information, which includes a boot log, deviates from a trusted baseline. Any deviation can indicate that untrusted modules are loaded, and the OS could be compromised.

  • The attestation quote couldn't be verified to originate from the vTPM of the attested VM. An unverified origin can indicate that malware is present and could be intercepting traffic to the vTPM.

    Note

    Alerts are available for VMs with vTPM enabled and the Attestation extension installed. Secure Boot must be enabled for attestation to pass. Attestation fails if Secure Boot is disabled. If you must disable Secure Boot, you can suppress this alert to avoid false positives.

• Alert for untrusted Linux kernel module: For Trusted Launch with Secure Boot enabled, it's possible for a VM to boot even if a kernel driver fails validation and is prohibited from loading. If kernel driver validation failure happens, Defender for Cloud issues low-severity alerts. While there's no immediate threat, because the untrusted driver didn't load, these events should be investigated. Ask yourself:

  • Which kernel driver failed? Am I familiar with the failed kernel driver and do I expect it to load?
  • Is the exact version of the driver same as expected? Are the driver binaries intact? If failed driver is a partner driver, did the partner pass the OS compliance tests to get it signed?

(General Availability) Trusted Launch as default

Azure portal, PowerShell, and CLI customers get Trusted Launch enabled by default.

Enable TLaD (Trusted Launch as default)

To make this feature available for all VMs you create for your workloads by default, first register the feature TrustedLaunchByDefaultPreview under the Microsoft.Compute namespace on your virtual machine subscription. For more information, see Set up preview features in Azure subscription.

To create a new Gen2 VM or scale set with Trusted Launch default, run your existing deployment script through Azure SDK, Terraform, or another method.

VM and scale set deployments with TLaD

Existing behavior

To create Trusted launch VM & scale set, you need to add following securityProfile element in deployment:

"securityProfile": {
    "securityType": "TrustedLaunch",
    "uefiSettings": {
        "secureBootEnabled": true,
        "vTpmEnabled": true,
    }
}

Absence of securityProfile element in deployment code deploys VM & scale set without enabling Trusted launch.

Examples

• vm-windows-admincenter – The Azure Resource Manager (ARM) template deploys Gen2 VM without enabling Trusted launch.
• vm-simple-windows – The ARM template deploys Trusted launch VM (without default as securityProfile is explicitly added to ARM template)

New behavior

By using API version 2025-11-01 or higher, Trusted Launch is enabled by default for new VMs and scale sets deployed if the following conditions are met:

• Source Marketplace OS image supports Trusted launch.
• Source ACG OS image supports and is validated for Trusted launch.
• Source disk supports Trusted launch.
• VM size supports Trusted launch.

The deployment doesn't default to Trusted Launch if one or more of the listed conditions aren't met, and completes successfully to create a new Gen2 VM and scale set without Trusted Launch.

You can choose to explicitly bypass the default for VM and scale set deployment by setting Standard as value of parameter securityType and using API version 2025-11-01 or higher. For more information, see Can I disable Trusted Launch for a new VM deployment.

Known limitations

Unable to re-size VM or VMSS to un-supported Trusted launch VM size family (like M-Series) post default to Trusted launch.

Re-sizing Trusted launch VM to VM size family not supported with Trusted launch will not be supported.

As mitigation, please register feature flag UseStandardSecurityType under Microsoft.Compute namespace AND roll-back VM from Trusted launch to Gen2-only (Non-Trusted launch) by setting securityType = Standard using available client tools (except Azure portal).

After a VM or VM scale set is created with Trusted Launch, you can't resize it to a VM size family that doesn't support Trusted Launch, such as an unsupported M-series size. To use an unsupported size, first deallocate the resource and change securityType to Standard by using Microsoft.Compute API version 2025-11-01 or later through a supported client tool. This operation isn't available in the Azure portal.

Disable TLaD

To disable TLaD, unregister the preview feature TrustedLaunchByDefaultPreview under the Microsoft.Compute namespace on the virtual machine subscription. For specific VMs, you can bypass TLaD by setting the security type to Standard. For more information, see Unregister preview feature.

Related content

• Deploy a Trusted Launch VM.