Enable and Verify Secure Boot on Hyper-V Generation 2 Virtual Machines

Desired Outcome

Configure a Hyper-V Generation 2 virtual machine to use UEFI Secure Boot, ensuring that only digitally signed boot components load during startup. This meets baseline compliance requirements for Windows Server 2016, 2019, and 2022 workloads and protects against boot-level rootkits.

Prerequisites

• Generation 2 VM — Secure Boot is unavailable on Generation 1 (BIOS) VMs. Confirm the VM generation before proceeding.
• Host OS — Windows Server 2016 or later, or Windows 10/11 with Hyper-V enabled.
• Integration Services — Version 8.0 or newer inside the guest for full Secure Boot compatibility (inbox on supported Windows guests; update via Windows Update on older builds).
• Administrative rights — Hyper-V Administrator or local Administrators group on the host.

Verify VM Generation

Before changing firmware settings, confirm the VM is Generation 2. In Hyper-V Manager, select the VM and inspect Summary > Generation. Alternatively, run the following PowerShell command on the host (requires elevated session):

Get-VM -Name 'VMName' | Select-Object Name, Generation

Output showing Generation : 2 means you can proceed. A value of 1 requires recreating the VM as Generation 2; migration is not supported.

Enable Secure Boot via Hyper-V Manager

1. Shut down the target VM (Right-click > Shut Down). Secure Boot state cannot be changed while the VM is running or saved.
2. Open Settings for the VM.
3. Navigate to Security under the Hardware list.
4. Ensure Enable Secure Boot is checked. The default template Microsoft UEFI Certificate Authority is appropriate for Windows guests and most mainstream Linux distributions that ship Microsoft-signed shim loaders.
5. Click OK and start the VM.

Enable Secure Boot via PowerShell

For automation or remote management, use the Set-VMFirmware cmdlet. Run in an elevated PowerShell session on the Hyper-V host:

Set-VMFirmware -VMName 'VMName' -EnableSecureBoot On -SecureBootTemplate MicrosoftUEFICertificateAuthority

The -SecureBootTemplate parameter accepts MicrosoftUEFICertificateAuthority (default) or MicrosoftWindows for Windows-only workloads. Custom templates require a pre-enrolled certificate in the VM's firmware variable store.

Verify Secure Boot State

Inside the Guest (Windows)

After the VM boots, confirm Secure Boot is active from within the guest OS:

Confirm-SecureBootUEFI

Returns True when Secure Boot is enabled and the boot chain validated. Returns False if disabled or unsupported. Requires elevated PowerShell in the guest.

From the Host (PowerShell)

Query the VM firmware object without logging into the guest:

Get-VMFirmware -VMName 'VMName' | Select-Object SecureBoot, SecureBootTemplate

Expected output:

SecureBoot         SecureBootTemplate
----------         ----------------
True               MicrosoftUEFICertificateAuthority

Common Compatibility Scenarios

Linux Guests

Most enterprise distributions (RHEL 8+, Ubuntu 20.04+, SLES 15+) boot with the Microsoft UEFI CA template enabled. If a distribution fails to boot (typically stopping at the shim or GRUB stage), you have two options:

• Disable Secure Boot for that VM only: Set-VMFirmware -VMName 'VMName' -EnableSecureBoot Off
• Enroll the distribution's own signing certificate (MOK enrollment) — consult the vendor's documentation.

Disabling Secure Boot reduces the security posture and may violate compliance baselines (e.g., PCI-DSS, STIG). Document the exception and track remediation.

Unsigned Drivers or Custom Kernels

Windows guests loading unsigned kernel-mode drivers (test-signed or legacy) will fail to boot with Secure Boot enabled. Options:

• Sign drivers with a trusted EV code-signing certificate.
• Temporarily disable Secure Boot during development, re-enable for production.

Recovery and Rollback

If a VM fails to boot after enabling Secure Boot:

1. Shut down the VM (force off if hung).
2. Disable Secure Boot via PowerShell (works while VM is off):

   Set-VMFirmware -VMName 'VMName' -EnableSecureBoot Off

3. Start the VM and collect boot logs (C:\Windows\Panther\setupact.log for Windows; journalctl -b for Linux).
4. Re-enable Secure Boot after resolving the signature issue.

No host-level rollback is required; the change is per-VM and non-destructive to virtual disks.

Limitations

• Generation 1 VMs cannot use Secure Boot — recreate as Generation 2 if required.
• Shielded VMs (guarded fabric) enforce Secure Boot automatically; manual changes are blocked.
• Nested virtualization hosts (Hyper-V inside a VM) expose Secure Boot to L2 guests only when the L1 VM runs on a physical host with virtualization extensions exposed.

Quick Validation Checklist

• VM Generation = 2
• Host = Windows Server 2016+ or Windows 10/11
• Get-VMFirmware shows SecureBoot = True
• Guest reports Confirm-SecureBootUEFI = True
• No unsigned boot components in the chain