Trusted launch for Azure virtual machines
Applies to: ✔️ Linux VMs ✔️ Windows VMs ✔️ Flexible scale sets ✔️ Uniform scale sets
Azure offers trusted launch as a seamless way to improve the security of generation 2 VMs. Trusted launch protects against advanced and persistent attack techniques. Trusted launch is composed of several, coordinated infrastructure technologies that can be enabled independently. Each technology provides another layer of defense against sophisticated threats.
- Trusted Launch is selected as the default state for newly created Azure VMs. If your new VM requires features which are not supported by trusted launch, see the Trusted Launch FAQs
- Existing Azure Generation 2 VMs can have trusted launch enabled after being created. For more information, see Enable Trusted Launch on existing VMs
- You cannot enable trusted launch on an existing virtual machine scale set (VMSS) that was initially created without it. Trusted launch requires the creation of new VMSS.
- Securely deploy virtual machines with verified boot loaders, OS kernels, and drivers.
- Securely protect keys, certificates, and secrets in the virtual machines.
- Gain insights and confidence of the entire boot chain's integrity.
- Ensure workloads are trusted and verifiable.
Virtual Machines sizes
- Installation of the CUDA & GRID drivers on Secure Boot enabled Windows VMs does not require any extra steps.
- Installation of the CUDA driver on Secure Boot enabled Ubuntu VMs requires extra steps documented at Install NVIDIA GPU drivers on N-series VMs running Linux. Secure Boot should be disabled for installing CUDA Drivers on other Linux VMs.
- Installation of the GRID driver requires secure boot to be disabled for Linux VMs.
- Not Supported size families do not support generation 2 VMs. Change VM Size to equivalent Supported size families for enabling Trusted Launch.
Operating systems supported
|8.7, 8.8, 9.0
|8.3, 8.4, 8.5, 8.6, 8.7, 8.8 LVM, 9.0, 9.1 LVM
|RedHat Enterprise Linux
|8.4, 8.5, 8.6, 8.7, 8.8, 9.0, 9.1 LVM, 9.2
|SUSE Enterprise Linux
|15SP3, 15SP4, 15SP5
|18.04 LTS, 20.04 LTS, 22.04 LTS, 23.04, 23.10
|Pro, Enterprise, Enterprise Multi-Session *
|Pro, Enterprise, Enterprise Multi-Session *
|2016, 2019, 2022 *
|Window Server (Azure Edition)
* Variations of this operating system are supported.
- All public regions
- All Azure Government regions
- All Azure China regions
Pricing: Trusted launch does not increase existing VM pricing costs.
The following Virtual Machine features are currently not supported with Trusted Launch.
- Azure Site Recovery
- Managed Image (Customers are encouraged to use Azure Compute Gallery)
- Nested Virtualization (most v5 VM size families supported)
At the root of trusted launch is Secure Boot for your VM. Secure Boot, which is implemented in platform firmware, protects against the installation 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 select 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.
Trusted launch also introduces vTPM for Azure VMs. vTPM is a virtualized version of a hardware Trusted Platform Module, 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, running 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 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 (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 executable code can't be modified once it's allowed to load. For more information about VBS and HVCI, see Virtualization Based Security (VBS) and Hypervisor Enforced Code Integrity (HVCI).
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 (PtH) attacks. For more information, see Credential Guard.
Microsoft Defender for Cloud integration
Trusted launch is integrated with Microsoft Defender for Cloud to ensure your VMs are properly configured. Microsoft Defender for Cloud continually assesses compatible VMs and issue relevant recommendations.
- Recommendation to enable Secure Boot - Secure Boot recommendation only applies for VMs that support trusted launch. Microsoft Defender for Cloud identifies VMs that can enable Secure Boot, but have it disabled. It issues a low severity recommendation to enable it.
- Recommendation to enable vTPM - If your VM has vTPM enabled, Microsoft Defender for Cloud can use it to perform Guest Attestation and identify advanced threat patterns. If Microsoft Defender for Cloud identifies VMs that support trusted launch and have 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, Microsoft Defender for Cloud issues low severity recommendations to install the guest attestation extension on it. This extension allows Microsoft 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 attestation extension installed, Microsoft Defender for Cloud can remotely validate that your VM booted in a healthy way. This is known as boot integrity monitoring. Microsoft Defender for Cloud issues an assessment, indicating the status of remote attestation.
If your VMs are properly set up with trusted launch, Microsoft Defender for Cloud can detect and alert you of VM health problems.
Alert for VM attestation failure: Microsoft 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. 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 have been 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.
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 this happens, Microsoft Defender for Cloud issues low severity alerts. While there's no immediate threat, because the untrusted driver hasn't been loaded, these events should be investigated.
- Which kernel driver failed? Am I familiar with this driver and expect it to be loaded?
- Is this the exact version of the driver I'm expecting? Are the driver binaries intact? If this is a third party driver, did the vendor pass the OS compliance tests to get it signed?
Deploy a trusted launch VM.