Microsoft has made Trusted Launch as Default generally available for new Azure Generation 2 virtual machines and virtual machine scale sets. It is a quiet change to the security baseline of the platform, but it is the kind of default that saves people from themselves.
Trusted Launch as Default, usually shortened to TLaD, automatically turns on Secure Boot and the virtual Trusted Platform Module (vTPM) for supported new deployments. Instead of asking you to harden a freshly provisioned VM, Azure gives you the hardened version out of the box. For anyone who has ever kicked off a VM and then spent an afternoon locking it down, the shift is meaningful.
What Trusted Launch actually does
Trusted Launch is a bundle of boot-time protections that close a real gap. A standard VM boots through firmware and a bootloader that are easy to tamper with, which is exactly the path bootkits and rootkits use to slip in before the operating system has a chance to defend itself. Secure Boot checks that every stage of the boot chain is signed and trusted, so an attacker cannot swap in a malicious bootloader or kernel-level driver. The vTPM does something different: it holds platform integrity measurements and keys in a hardware-backed space, giving you a root of trust that can report on what actually booted.
Together those two pieces let you verify a machine is running the software you expect, not something an attacker injected during an earlier boot. TLaD also enables remote attestation through the vTPM, so you can check platform health and integrity from outside the machine.
The important detail is that this is now the default for new Gen2 VMs and scale sets. The security controls are no longer optional extras you have to remember to switch on. They are part of the initial configuration.
Why the default matters more than the feature
Security defaults are where the real wins live. A feature that protects only the people who already know to enable it protects very few people. Mandatory or default security shifts the burden from the operator to the platform, which is exactly where a cloud provider is best positioned to act.
Consider how many breaches start with a misconfigured resource rather than an exotic exploit. A default-on boot protection removes one entire class of those misconfigurations. It does not stop every attack, but it removes the low-hanging fruit that attackers rely on when they scan for weak targets at scale.
There is also a story here about Azure’s broader direction. Microsoft has been pushing toward hardware-rooted security and confidential computing for years, and Trusted Launch is a stepping stone on that path. By making vTPM and Secure Boot the baseline, the platform gets closer to a model where the hardware itself is part of the trust boundary rather than an afterthought.
What you should do with this
If you create new Gen2 VMs, the smart move is to leave Trusted Launch on rather than fight it. There are a few practical checks worth doing:
- Confirm your VM images and sizes support Trusted Launch. Generation 2 images and the supported size families are needed, and most current catalog images already qualify.
- Review your VM scale sets. TLaD applies there too, so your fleet gets the benefit at the same time as individual VMs.
- If you have a compliance or attestation requirement, start using the vTPM measurements for remote attestation instead of treating it as a dormant feature.
For existing workloads, the bigger question is whether to migrate. Microsoft has documented the process for enabling Trusted Launch on existing VMs, and for security-sensitive workloads it is usually worth the effort. Standard Gen2 VMs that were created before this default can be converted, though you should test imaging and migration on a non-production instance first.
What about older VMs
Generation 1 VMs do not get the same treatment here. TLaD targets Generation 2 architecture, which is where the secure boot and measured boot capabilities actually live. If you are still running Gen1 VMs, the medium-term plan should be moving them to Gen2, not just for Trusted Launch but because Gen2 is where the platform keeps investing.
There is also value in being deliberate about the images you deploy. Trusted Launch protects the boot chain, but a hardened boot does not help if the image itself is outdated and full of known vulnerabilities. Default security and good patch hygiene are complementary, not substitutes.
Bottom line
Trusted Launch as Default is a small announcement with a big effect: the secure configuration is now the one you get automatically. For teams creating new Azure VMs, that means a stronger starting point with zero extra effort. For the platform, it is another step toward security being something the cloud does for you rather than something you have to make it do.