We received a security advisory stating that Microsoft deployed an infrastructure-level protection update for Azure virtual machines using Trusted Launch and that affected running VMs must be restarted before the protection becomes active. The notice says a normal VM restart is sufficient and that workloads will experience the usual planned interruption.
However, the advisory's impacted-resources list is empty for our subscriptions. We also have multiple tenants, and only some received the notification. The message appears to list every region as affected, even though some tenants operate in only one region.
Has anyone determined whether this was sent broadly to customers who use Trusted Launch, or whether the impacted-resource display is incomplete? Also, is a restart from the Azure control plane required, or is restarting the operating system enough?
5 Answers
The notification does not appear to mean that every Trusted Launch VM is affected. It is usually targeted based on subscription, region, VM generation, and the infrastructure update itself. If the advisory’s Account information or impacted-resources section is empty, there may be nothing requiring action in that subscription, even if the wording sounds broad. I would check Service Health separately in each tenant and subscription, since the alert may be visible only at the scope where it was generated.
The fact that a tenant has Trusted Launch enabled is not, by itself, proof that all of its VMs need restarting. The absence of the alert in another tenant is also useful evidence that this is not a universal action for every Trusted Launch deployment. Treat the advisory as scoped to the resources Microsoft identifies, rather than applying it globally.
Be careful about what kind of restart you use. A reboot initiated inside the guest operating system may not be equivalent to an Azure host-level restart. For a confirmed affected VM, use the Azure portal, Azure CLI, PowerShell, or REST operation so the platform records the VM restart. Schedule it like any other maintenance event because the workload will be interrupted.
The alerting itself appears inconsistent: Partner or administrative notifications may show only one subscription, while the tenant’s Service Health view can contain more detail. Check the advisory at the tenant, subscription, and region scopes, and compare the resource IDs listed in the notification with the actual VM inventory. If no resources are listed anywhere, Microsoft support is the best way to confirm whether the advisory was generated in error or whether resource targeting failed.
This looks like an infrastructure maintenance or security advisory rather than a vulnerability that requires rebuilding the machines. Microsoft’s wording specifically says a standard Azure VM restart is enough, with no redeployment or configuration change required. I would not restart every Trusted Launch VM blindly; first export or record the affected-resource list and open a support case if the list is blank but the notification still demands action.
That matches what we have seen: some subscriptions received the advisory while others with Trusted Launch VMs did not. The regional wording also seems broader than the actual resource scope.