Azure VM boot loop after enabling Secure Boot: fix

1. The most common cause: Secure Boot enabled on a VM that doesn't support it

This is the one I see 8 out of 10 times. You or someone in your team goes into the Azure portal, clicks the VM, finds the Secure Boot toggle under Security type in the Disks blade, and flips it to On. Then the VM restarts and never comes back. The boot diagnostics show VMGuestStateReportFailed and the VM sits there like a brick.

Why? Because most Azure VMs—especially Linux ones—ship with the Trusted Launch security type, which includes Secure Boot disabled by default. The VM’s kernel or bootloader (GRUB, for example) wasn’t signed for Secure Boot. Enabling it breaks the chain. The VM can’t even get far enough to report a proper error.

Last month I had a client whose entire dev team’s Ubuntu 22.04 VM died because someone “checked a box” during a security audit. Took me 10 minutes to fix. Here’s how.

The fix: disable Secure Boot via boot diagnostics

1. Stop the stuck VM from the Azure portal (if it’s not already stopped).
2. Go to Help > Boot diagnostics (or Serial console if you can’t get to boot diags).
3. If boot diagnostics are enabled, you’ll see a screenshot or serial log. If the VM is truly stuck, you might need to use the Reset password blade to reset the VM’s OS disk’s security settings. But the faster way is to use the Azure CLI or PowerShell to disable Secure Boot directly.
4. Run this Azure CLI command (replace myVM and myResourceGroup):
   az vm update --resource-group myResourceGroup --name myVM --set securityProfile.uefiSettings.secureBootEnabled=false
5. Then start the VM. It should boot cleanly.

If you don’t have the Azure CLI handy, you can also do this via the portal: Go to the VM’s Disks blade, click the OS disk, and under Security turn off Secure Boot. But I’ve found the CLI command works even when the portal UI gets confused.

2. Second cause: Guest OS kernel or bootloader not Secure Boot compliant

This is the subtler version of the first cause. The VM supports Secure Boot in theory—it’s a Windows VM or a Linux VM with a signed kernel—but the specific kernel version or custom bootloader you’re using isn’t signed. For instance, a custom compiled kernel on Ubuntu, or an older RHEL 7 kernel that predates Secure Boot support in Azure.

I saw this on a CentOS 7 VM where someone installed a custom kernel for a GPU driver. Secure Boot was enabled, but the custom kernel wasn’t signed. Same error: VMGuestStateReportFailed.

Fix: Boot into a known-good kernel or disable Secure Boot temporarily

1. Use the Azure Serial Console (you’ll need to enable it first, but it’s often available).
2. At the GRUB prompt, press Esc or Shift during boot to get the GRUB menu. If you can’t get there, use the Reset password blade in Azure to reset the VM’s boot order to a known-good kernel (this actually works).
3. Select an older kernel that you know worked before you enabled Secure Boot.
4. Once booted, remove the custom kernel or recompile it with a signed shim.
5. If you just want to get back to work, disable Secure Boot as in fix #1.

3. Third cause: Azure VM’s Secure Boot state got corrupted during update

Less common, but I’ve seen it twice. The VM had Secure Boot enabled and working for months. Then an Azure platform update or a guest OS patch triggered a boot failure. The VM tries to report its state to the Azure fabric, can’t, and throws VMGuestStateReportFailed.

This is a bug in the Azure Hyper-V stack or the UEFI firmware. It’s rare but real.

Fix: Redeploy the VM to a different host node

1. Stop the VM.
2. In the Azure portal, go to the VM’s Overview blade and click Redeploy.
3. This moves the VM to a different physical host. Sometimes that’s all it takes.
4. If that fails, delete the VM (keep the disks) and re-create it from the OS disk. That’s a nuclear option, but it works.

Quick-reference summary

Bottom line: If you see VMGuestStateReportFailed after enabling Secure Boot, the fix is almost always turning it back off. Don’t waste time rebuilding the VM until you’ve tried that first. And next time, test Secure Boot on a non-production VM before flipping it on production boxes. Your future self will thank you.