In the Azure tenants I work with, Azure Trusted Launch has quietly become standard for new virtual machines, at least for Gen2 VMs. It used to be an optional security toggle. Today it's enabled by default for most modern Windows and Linux machines provisioned through the Azure portal, and you get Secure Boot, vTPM and boot integrity monitoring through Defender for Cloud without doing anything extra. Still, a few questions keep coming up in projects. Older VMs are often left unprotected, backup and image handling changes, and moving Gen1 machines to Trusted Launch has some real-world gotchas that I want to cover here.

Azure Trusted Launch brings Secure Boot and vTPM to your Gen2 VMs

Trusted Launch adds UEFI Secure Boot, a virtual TPM and a verified boot process to Azure VMs. That closes gaps that used to be routine in cloud deployments. Modern workloads depend on Secure Boot and vTPM: they make features like BitLocker possible and protect against boot kits and rootkits at the virtualization layer. On top of that, Defender for Cloud can monitor startup integrity, so manipulation or corruption (malware, misconfiguration, failed updates) shows up and can be acted on. Trusted Launch applies to all supported Gen2 VM sizes, which are gradually replacing the old Gen1 sizes. For prerequisites and compatibility, Microsoft's Trusted Launch overview is the place to start.

New VMs get it by default while legacy Gen1 machines need a project

The big recent change is that Trusted Launch is now the default for most new Gen2 VMs created via the portal or ARM templates. In the Azure portal, the option sits in the VM creation workflow on the Security tab and is usually pre-selected. Gen1 VMs are a different story. The path is clear, but it isn't a one-click upgrade. First, the OS disk has to be converted from MBR to GPT, typically with the MBR2GPT.exe tool inside Windows or with distro-specific tools on Linux. Once that's done, you switch the VM's security type to Trusted Launch in Azure portal → VM → Configuration → Security type. Microsoft's migration guide for Gen1 VMs walks through the details. Not every VM size is supported, and in my experience old or custom images (especially with legacy agents or older Linux distros) cause the most trouble. Legacy workloads and third-party agents are where I run into compatibility problems again and again.

Before you upgrade, check every backup agent or monitoring extension that hooks into the boot process. These are the usual reasons a migration stalls.

Defender for Cloud monitors boot integrity on Trusted Launch VMs

One clear advantage of Trusted Launch is how closely boot integrity monitoring ties into Microsoft Defender for Cloud. With Secure Boot and vTPM enabled, you can turn on boot integrity checks, and Defender verifies the bootloader, kernel and drivers at startup. If something has been tampered with or changed unexpectedly, whether through malware, an update or plain human error, you get an alert and an investigation workflow.

This simple Mermaid flowchart shows how Trusted Launch, Defender and the VM lifecycle fit together:

flowchart TD
    CreateVM["Create new Gen2 VM"] --> EnableTL["Enable Trusted Launch"]
    EnableTL --> SecureBoot["Secure Boot and vTPM active"]
    SecureBoot --> DefenderBootMon["Defender boot integrity monitoring"]
    DefenderBootMon --> Alert["Alert on manipulation"]
    Alert --> Remediation["Investigation or response"]

Figure: Trusted Launch turns on security features and Defender for Cloud boot integrity monitoring for Gen2 VMs.

You enable boot integrity monitoring in Defender for Cloud → Workloads → Virtual Machines, from the VM details panel. This integration requires at least Defender for Servers Plan 2.

Practical tip: "If you use Azure Backup with Trusted Launch, check whether your older restore points actually boot under Gen2 with vTPM. Restoring a legacy MBR-based disk onto a Trusted Launch VM fails a lot, so do a test restore before you switch."

Azure Policy finds the VMs that still lack Trusted Launch

In large environments it's often unclear which VMs are already protected. Azure Policy gives you the fastest overview, since Microsoft ships a built-in policy definition that audits all VMs without Trusted Launch. Assign it (search for "Trusted Launch audit") at subscription or management group level and the compliance view tells you where to act. In the portal you can also filter VMs by "security type" directly.

If you prefer PowerShell (Az module 10.0 or newer, Reader role or higher), this query gives you a quick audit:

Get-AzVM | Where-Object { $_.SecurityProfile.SecurityType -ne "TrustedLaunch" }

I use the output as the basis for reports and for planning remediation in bulk.

Trusted Launch affects your images and backups across the VM lifecycle

Once Trusted Launch is your baseline, your backup and image routines need a second look. Not every backup or image restores to a Trusted Launch VM, particularly if it's based on Gen1/MBR disks. Before a large migration, use the Azure Backup Center to check the disk layout of your restore points. On the image side, the Azure Compute Gallery now supports Trusted Launch for Gen2 images, so you can build images that are secure by default and distribute them across your tenant. I now consider that best practice for standardization and compliance. If you manage hybrid environments, I also cover Trusted Launch in my post on what Windows Server 2025 changes for hybrid admins.

I treat Trusted Launch as the new normal when it's done right

For Gen2 VMs, Azure Trusted Launch is a baseline now, not an add-on, at least in any environment I'd call production-ready. Turning it on is easy. Doing it properly means cleaning up legacy partition tables, updating your images, confirming agent compatibility and reviewing your backup strategy. You end up with better security, and you also get more standardized and predictable operations. In every deployment I work on, Trusted Launch is a must for new Gen2 VMs, and I don't expect that to change anytime soon.