Trusted Launch Is Now the Default for Every New Gen2 VM

For most of Azure's history, security on a new VM was something you opted into. You created the machine, and somewhere in the Security section of the blade there was a dropdown: Standard, or Trusted launch. Most people left it on Standard, because Standard was the default and defaults are what people ship.That default just changed. As of July 2026, Trusted Launch as Default (TLaD) is generally available for new Gen2 virtual machines and VM scale sets. Trusted Launch is now the default state for newly created Azure Gen2 VMs and scale sets. If you create a Gen2 VM through the Azure Portal, CLI, or PowerShell today, it comes up with Secure Boot and vTPM already switched on, whether you asked for them or not.

That sounds like a small dashboard change. It's really a statement about who owns the security posture of a VM on day one — and it's worth understanding both what you're getting for free and where the automation stops.

What Trusted Launch is actually doing under the hood

Trusted Launch isn't one feature, it's a bundle of boot-time protections layered on top of a Gen2 VM. It gives your VM its own dedicated vTPM instance running in a secure environment outside the reach of the VM itself, and that vTPM enables attestation by measuring the entire boot chain — UEFI, OS, system, and drivers. Two pieces do most of the work:

Secure Boot — only signed, trusted bootloaders and kernels are allowed to run, closing off a whole class of rootkit and bootkit attacks that plant themselves before the OS even loads.

vTPM — a virtual Trusted Platform Module that lets the platform cryptographically prove the VM booted with the components it's supposed to have, not something tampered with.

Who actually gets it automatically

This is the part worth reading twice, because “generally available” doesn't mean every path into Azure behaves the same way yet. Trusted Launch as default is generally available for the Azure Portal, PowerShell, and CLI — but it's still in preview for other clients.

If your org provisions VMs mostly by hand through the portal, you're already covered. If you provision through Terraform or a CI/CD pipeline running ARM/Bicep — which is most engineering orgs — this is a subscription-level setting you need to go turn on deliberately, or your IaC deployments will quietly keep shipping unprotected VMs while your click-ops VMs get the new default for free.

What doesn't change

Existing infrastructure is untouched. If you've got a fleet of Gen2 VMs already running as Standard security type, TLaD does nothing to them — it only applies at creation time. Nothing about your currently running workloads changes, and any VM where you've explicitly and deliberately set the security type continues to honor that choice going forward.

If you do want existing Gen2 VMs upgraded, that's a separate, manual action: stop the VM, flip Security type from Standard to Trusted launch in the portal, and re-enable it. Secure Boot isn't turned on by default in that flow, so it's worth checking that box explicitly rather than assuming it followed along.

Where you're expected to opt out

Trusted Launch isn't universally compatible with every VM workflow, and Microsoft is explicit that a handful of scenarios need you to deliberately bypass the new default rather than fight it after the fact. You need to opt out if any of the following applies to your deployment:

For the managed-image case specifically, Microsoft's guidance isn't really “bypass it,” it's “stop using managed images.” All new features going forward — Arm64, Trusted Launch, Confidential VM — ship only through Azure Compute Gallery, so managed images are effectively the legacy path here.

The actual takeaway

Trusted Launch as Default isn't a new product, it's Azure moving the security baseline out of the “things engineers forget to configure” pile and into infrastructure. That's a genuinely good trade for the vast majority of workloads — Secure Boot and vTPM cost nothing extra and close off real attack surface.

The catch isn't the feature, it's the rollout being uneven across tooling. If your team ships VMs through the Portal, you already have this. If you ship through Terraform, Bicep, or an SDK, go register the subscription-level preview feature deliberately rather than assuming parity — and check your image-building and managed-image pipelines against the bypass list before your next Packer run fails in a way nobody expected.

References

Trusted launch for Azure virtual machines: https://learn.microsoft.com/en-us/azure/virtual-machines/trusted-launch

Enable Trusted launch on existing Gen2 VMs:

https://learn.microsoft.com/en-us/azure/virtual-machines/trusted-launch-existing-vm