Microsoft has made Trusted Launch as Default generally available for eligible new Azure Generation 2 virtual machines and virtual machine scale sets, changing the security baseline for deployments created through the Azure portal, Azure CLI, and Azure PowerShell. The immediate practical result is that a supported new Windows Server, Windows 11, or Linux Gen2 VM now starts with Secure Boot and a virtual TPM enabled unless an administrator explicitly requests the older Standard security type.
Petri first reported the general-availability change on August 6. Microsoft’s Azure Virtual Machines documentation, updated August 3, confirms the wider shift: Trusted Launch is now the default state for new Gen2 VMs and scale sets, across public Azure regions as well as Azure Government and Azure China. There is no added VM charge for the feature.
The important qualification is that this is not a blanket conversion of Azure compute. Existing VMs and existing scale sets remain as they are. Generation 1 machines are also outside the default because Trusted Launch depends on Gen2’s UEFI-based boot architecture. Administrators who want the protections on current Gen2 VMs must deliberately upgrade them, validate compatibility, and accept different rollback constraints.
The headline sounds simple, but the operational behavior varies by how a VM is deployed.
For Azure portal, CLI, and PowerShell users, Microsoft says new eligible Gen2 VM deployments default to Trusted Launch without a subscription registration. For infrastructure-as-code pipelines—ARM templates, Bicep, Terraform, Azure SDKs, and similar clients—the subscription must be registered for the
Automation must also use Microsoft.Compute API version
Microsoft also preserves an explicit
That means the safest interpretation is not “all Gen2 VMs are now protected.” It is: new compatible Gen2 deployments with no contradictory instruction now receive Trusted Launch automatically. Teams should treat that as a configuration change to test in their build pipelines, rather than assuming security posture from a VM’s generation alone.
The source OS image must support Trusted Launch. The selected VM size must support it. A source disk must support it. For Azure Compute Gallery images, the image must support Trusted Launch and complete Azure’s validation process. If one of those conditions is not met, Microsoft says deployment completes successfully as a standard Gen2 VM rather than failing.
That is sensible for availability, especially in automation that provisions many VMs. It also means a successful deployment is no longer proof that the intended default security setting applied. An organization adopting Trusted Launch as its baseline should add a post-deployment check for the VM
The gap is particularly relevant to custom Windows Server images. Microsoft supports current Windows Server releases including Windows Server 2016, 2019, 2022, Windows Server 2022 Azure Edition, Windows Server 2025, and Windows Server 2025 Azure Edition when the applicable image variations are supported. But an internally captured image, an old gallery image definition, or an imported disk still needs to meet the relevant Gen2 and Trusted Launch requirements. “Windows Server 2022” in the operating-system field is not, by itself, a guarantee that a particular image will qualify.
Microsoft’s documentation says Azure Compute Gallery validation is still preview functionality and can take at least an hour to complete for an image version. That creates a timing issue for image pipelines: publishing a gallery version and deploying it immediately may not produce the expected Trusted Launch default until validation has succeeded.
Secure Boot verifies signatures across the boot chain, preventing unsigned or untrusted UEFI, bootloader, kernel, and driver components from loading. The vTPM provides a dedicated TPM 2.0-compatible store for cryptographic keys and boot measurements outside the guest VM. Together, they establish the hardened startup state Microsoft is making the default.
The boot-integrity-monitoring claim needs more care. Microsoft’s documentation says Defender for Cloud can remotely attest a VM’s boot integrity when Secure Boot and vTPM are enabled and the Guest Attestation extension is installed. Defender for Cloud can then surface health assessments and alerts when attestation fails.
Trusted Launch as Default does not mean every new VM is automatically enrolled in continuous Defender for Cloud monitoring. The default provides the prerequisites. Organizations that want attestation results and alerts need to ensure the Guest Attestation extension and the relevant Defender for Cloud configuration are present. This distinction matters because a secure boot configuration prevents a class of changes; remote attestation provides evidence about whether the measured boot state remains trustworthy.
For Windows administrators, vTPM also creates a foundation for features such as Virtualization-based Security, Hypervisor-protected Code Integrity, and Microsoft Defender Credential Guard. Those workloads are not automatically enabled merely because a VM has Trusted Launch. The default removes a platform prerequisite; it does not silently turn on every Windows security feature that can use it.
The clearest documented reasons are compatibility. Trusted Launch does not support Managed Images, and Microsoft recommends Azure Compute Gallery in their place. Linux hibernation is also unsupported. Some GPU scenarios need Secure Boot disabled: Microsoft says CUDA and GRID drivers require no extra setup on Secure Boot-enabled Windows VMs, but CUDA installation on most Linux VMs and GRID drivers on Linux require Secure Boot to be disabled.
Size selection is another constraint. Microsoft lists broad B-, D-, E-, F-, L-, NC-, ND-, NV-, HB-, HC-, and HX-family coverage, but not every SKU qualifies. M-series availability is especially important for memory-heavy workloads: Microsoft warns that a Trusted Launch VM or scale set cannot be resized to a size family that does not support Trusted Launch. An administrator must first deallocate it and change its security type to Standard through a supported client tool; Azure portal does not support that rollback workflow.
Microsoft’s current Gen2 Trusted Launch documentation also identifies Managed Images, Linux hibernation, creation of certain Trusted Launch-capable gallery images through Azure Image Builder or Packer, and unsupported VM sizes as reasons to bypass the default. The right response is to make that exception explicit in code. Relying on compatibility fallback will create inconsistent VM security states that are harder to inventory later.
Microsoft instructs administrators to validate the OS image and VM size, create restore points, deallocate the VM, apply the Trusted Launch security type, and verify that the workload can start and accept RDP or SSH connections. Secure Boot can prevent a VM from booting when it encounters unsigned firmware components, bootloaders, kernels, or boot drivers. That is the desired security outcome, but it makes pre-production validation essential for custom images and specialized drivers.
The rollback path is more consequential than the new-VM opt-out. Microsoft says rolling an existing VM back from Trusted Launch to non-Trusted Gen2 is a one-way operation: once reverted to Standard, Trusted Launch cannot be enabled again on that same VM. The rollback also requires deallocation and must be performed using an ARM template, Azure CLI, or Azure PowerShell rather than Azure portal.
For most new Azure VM deployments, Microsoft has made the secure choice easier. The work now shifts to platform teams: update API versions, register IaC subscriptions where necessary, test custom images and specialty drivers, and audit the resulting
The important qualification is that this is not a blanket conversion of Azure compute. Existing VMs and existing scale sets remain as they are. Generation 1 machines are also outside the default because Trusted Launch depends on Gen2’s UEFI-based boot architecture. Administrators who want the protections on current Gen2 VMs must deliberately upgrade them, validate compatibility, and accept different rollback constraints.
The default changes by deployment path
The headline sounds simple, but the operational behavior varies by how a VM is deployed.For Azure portal, CLI, and PowerShell users, Microsoft says new eligible Gen2 VM deployments default to Trusted Launch without a subscription registration. For infrastructure-as-code pipelines—ARM templates, Bicep, Terraform, Azure SDKs, and similar clients—the subscription must be registered for the
TrustedLaunchByDefaultPreview feature under the Microsoft.Compute provider. The feature name is a leftover from its preview period, even though Microsoft now labels Trusted Launch as Default generally available.Automation must also use Microsoft.Compute API version
2025-11-01 or later. That version requirement is the detail most likely to be missed in long-lived enterprise templates. A team can register the subscription, run an old template, omit securityProfile, and still fail to receive the new default behavior because its API version predates the GA implementation.Microsoft also preserves an explicit
securityProfile in deployment code. In other words, an ARM or Bicep template that already specifies securityType: Standard remains Standard; one that explicitly selects TrustedLaunch remains Trusted Launch. The changed behavior applies when the configuration is absent, the subscription and API requirements are met, and the platform determines that the VM is eligible.That means the safest interpretation is not “all Gen2 VMs are now protected.” It is: new compatible Gen2 deployments with no contradictory instruction now receive Trusted Launch automatically. Teams should treat that as a configuration change to test in their build pipelines, rather than assuming security posture from a VM’s generation alone.
Azure will fall back to Standard rather than block a deployment
Microsoft’s compatibility design avoids an immediate deployment outage, but it introduces a quieter risk: a new VM can be created without Trusted Launch when one of its dependencies does not support it.The source OS image must support Trusted Launch. The selected VM size must support it. A source disk must support it. For Azure Compute Gallery images, the image must support Trusted Launch and complete Azure’s validation process. If one of those conditions is not met, Microsoft says deployment completes successfully as a standard Gen2 VM rather than failing.
That is sensible for availability, especially in automation that provisions many VMs. It also means a successful deployment is no longer proof that the intended default security setting applied. An organization adopting Trusted Launch as its baseline should add a post-deployment check for the VM
securityProfile, Secure Boot state, and vTPM state.The gap is particularly relevant to custom Windows Server images. Microsoft supports current Windows Server releases including Windows Server 2016, 2019, 2022, Windows Server 2022 Azure Edition, Windows Server 2025, and Windows Server 2025 Azure Edition when the applicable image variations are supported. But an internally captured image, an old gallery image definition, or an imported disk still needs to meet the relevant Gen2 and Trusted Launch requirements. “Windows Server 2022” in the operating-system field is not, by itself, a guarantee that a particular image will qualify.
Microsoft’s documentation says Azure Compute Gallery validation is still preview functionality and can take at least an hour to complete for an image version. That creates a timing issue for image pipelines: publishing a gallery version and deploying it immediately may not produce the expected Trusted Launch default until validation has succeeded.
Secure Boot and vTPM are automatic; attestation monitoring is not the same thing
Trusted Launch combines several capabilities that are often described together but should not be confused.Secure Boot verifies signatures across the boot chain, preventing unsigned or untrusted UEFI, bootloader, kernel, and driver components from loading. The vTPM provides a dedicated TPM 2.0-compatible store for cryptographic keys and boot measurements outside the guest VM. Together, they establish the hardened startup state Microsoft is making the default.
The boot-integrity-monitoring claim needs more care. Microsoft’s documentation says Defender for Cloud can remotely attest a VM’s boot integrity when Secure Boot and vTPM are enabled and the Guest Attestation extension is installed. Defender for Cloud can then surface health assessments and alerts when attestation fails.
Trusted Launch as Default does not mean every new VM is automatically enrolled in continuous Defender for Cloud monitoring. The default provides the prerequisites. Organizations that want attestation results and alerts need to ensure the Guest Attestation extension and the relevant Defender for Cloud configuration are present. This distinction matters because a secure boot configuration prevents a class of changes; remote attestation provides evidence about whether the measured boot state remains trustworthy.
For Windows administrators, vTPM also creates a foundation for features such as Virtualization-based Security, Hypervisor-protected Code Integrity, and Microsoft Defender Credential Guard. Those workloads are not automatically enabled merely because a VM has Trusted Launch. The default removes a platform prerequisite; it does not silently turn on every Windows security feature that can use it.
The opt-out is real, but it has technical costs
Microsoft permits administrators to opt out per workload by settingsecurityType to Standard. The supported tooling matters: Microsoft specifies Compute API version 2025-11-01 or newer, Azure CLI 2.86.0 or newer, and Azure PowerShell 15.6.1 or newer for this configuration.The clearest documented reasons are compatibility. Trusted Launch does not support Managed Images, and Microsoft recommends Azure Compute Gallery in their place. Linux hibernation is also unsupported. Some GPU scenarios need Secure Boot disabled: Microsoft says CUDA and GRID drivers require no extra setup on Secure Boot-enabled Windows VMs, but CUDA installation on most Linux VMs and GRID drivers on Linux require Secure Boot to be disabled.
Size selection is another constraint. Microsoft lists broad B-, D-, E-, F-, L-, NC-, ND-, NV-, HB-, HC-, and HX-family coverage, but not every SKU qualifies. M-series availability is especially important for memory-heavy workloads: Microsoft warns that a Trusted Launch VM or scale set cannot be resized to a size family that does not support Trusted Launch. An administrator must first deallocate it and change its security type to Standard through a supported client tool; Azure portal does not support that rollback workflow.
Microsoft’s current Gen2 Trusted Launch documentation also identifies Managed Images, Linux hibernation, creation of certain Trusted Launch-capable gallery images through Azure Image Builder or Packer, and unsupported VM sizes as reasons to bypass the default. The right response is to make that exception explicit in code. Relying on compatibility fallback will create inconsistent VM security states that are harder to inventory later.
Existing VMs require a deliberate migration decision
The GA announcement leaves existing deployments untouched, which avoids surprise reboots and compatibility problems but preserves the older security posture for most established Azure estates. Microsoft’s Azure Advisor now recommends enabling Trusted Launch on eligible existing Gen2 VMs, but an upgrade should not be treated as a cosmetic portal setting.Microsoft instructs administrators to validate the OS image and VM size, create restore points, deallocate the VM, apply the Trusted Launch security type, and verify that the workload can start and accept RDP or SSH connections. Secure Boot can prevent a VM from booting when it encounters unsigned firmware components, bootloaders, kernels, or boot drivers. That is the desired security outcome, but it makes pre-production validation essential for custom images and specialized drivers.
The rollback path is more consequential than the new-VM opt-out. Microsoft says rolling an existing VM back from Trusted Launch to non-Trusted Gen2 is a one-way operation: once reverted to Standard, Trusted Launch cannot be enabled again on that same VM. The rollback also requires deallocation and must be performed using an ARM template, Azure CLI, or Azure PowerShell rather than Azure portal.
For most new Azure VM deployments, Microsoft has made the secure choice easier. The work now shifts to platform teams: update API versions, register IaC subscriptions where necessary, test custom images and specialty drivers, and audit the resulting
securityProfile. Otherwise, the new default can either alter a known-good image pipeline or quietly fail open to Standard on the very deployments that security teams expected to harden.
References
- Primary source: Petri IT Knowledgebase
Published: 2026-08-06T13:05:22+00:00
Trusted Launch Becomes the Default for New Gen2 Azure VMs
Microsoft has made Trusted Launch the default for new Azure Gen2 virtual machines, enabling Secure Boot and vTPM protections automatically.
petri.com
- Related coverage: learn.microsoft.com
Enable Trusted launch on existing Gen2 VMs - Azure Virtual Machines | Microsoft Learn
Learn how to enable Trusted launch on existing Azure Gen2 virtual machines (VMs).learn.microsoft.com - Related coverage: learn.microsoft.com
Trusted Launch for Azure VMs - Azure Virtual Machines | Microsoft Learn
Learn about Trusted Launch for Azure virtual machines.learn.microsoft.com - Related coverage: techcommunity.microsoft.com
- Related coverage: petri.com
Azure VMs Get Support for Trusted Launch In-Place Upgrade
Microsoft now supports Trusted Launch in-place upgrades for Azure VMs and VM Scale Sets.
petri.com
- Related coverage: techcommunity.microsoft.com
- Related coverage: devblogs.microsoft.com
Improve the security of Generation 2 VMs via Trusted Launch in Azure DevTest Labs | Develop from the cloud
Secure your Generation 2 virtual machines with Trusted Launch in Azure DevTest Labs and experience enhanced security features.
devblogs.microsoft.com
- Related coverage: microsoft.com
- Related coverage: microsoft.com
- Related coverage: pulse.microsoft.com
- Related coverage: cdn-dynmedia-1.microsoft.com
