Secure Boot certificates and Hyper-V: why your Gen 2 VMs are not updating and what breaks in 2026

1. The host firmware question

A Generation 2 VM's Secure Boot is fully virtualised. Hyper-V provides each Gen 2 VM with its own virtual UEFI firmware, and Microsoft is explicit that this firmware is independent of what is on the physical host. Secure Boot and UEFI firmware are not required on the host itself. The VM's key stores live in the VM's own NVRAM, which is part of the VM configuration, not on the physical motherboard, and not shared with any other VM.

Two consequences follow, and they are the reason for this whole topic.

First, the physical host does not need hardware Secure Boot enabled, and does not need a BIOS or system firmware update, for its guests to receive the 2023 certificates. A host running old system firmware with hardware Secure Boot switched off can still present and update current certificates to its Gen 2 guests. State this the other way round, because it is the part people get wrong: a Gen 2 VM with Secure Boot enabled is fully in scope for the 2023 certificate work even when the host has Secure Boot disabled or unsupported. The host's own posture neither protects the VM nor excuses it. If you have been assuming that hosts without Secure Boot put their VMs out of scope, the opposite is true.

Second, because every VM carries its own independent NVRAM, no single action on the host fixes all guests at once. Patching the host does not reach into a running VM's NVRAM. Every guest, and every template, is a separate certificate store that can be in a different state and must be checked on its own.

So the two questions that get mixed up are unrelated:

• Host hardware Secure Boot and system firmware: irrelevant to whether guests can take the 2023 certificates.
• Host OS patch level, guest OS patch level, and per-VM NVRAM state: this is the entire problem.

The dependency is software, all the way down, and it is per-VM.

2. The certificate stores, and the 2011 to 2023 mapping

Secure Boot keeps its trust in four UEFI variables, and the event-log messages make no sense until you know what each one is.

PK, the Platform Key, is the single root key that authorises changes to the KEK list. KEK, the Key Exchange Key, holds the keys that are allowed to update the two signature databases below it. DB is the database of allowed signatures, the certificates a boot component must be signed against to be permitted to run. DBX is the opposite, the forbidden database, a revocation list of signatures that must be refused even if otherwise valid.

The replacement is not a clean one-to-one swap, which is why the output looks busy. In the KEK, Microsoft Corporation KEK CA 2011 is succeeded by Microsoft Corporation KEK 2K CA 2023. This one key is the gate: without the 2023 KEK in place, the guest cannot authorise the DB updates that follow. In the DB, the third-party Microsoft Corporation UEFI CA 2011 is replaced by two 2023 certificates, Windows UEFI CA 2023 and Microsoft UEFI CA 2023, the latter covering option ROMs, and the Windows Boot Manager signer Microsoft Windows Production PCA 2011 moves to the 2023 boot path.

The practical takeaway is short: the boot-critical certificate to confirm is Windows UEFI CA 2023 in the DB, and it is gated by KEK 2K CA 2023 in the KEK. If the 2023 KEK is missing, nothing downstream lands no matter what you set inside the guest.

3. What the 2026 and 2027 deadlines actually break

Be precise here, because the headlines overstate the immediate impact and understate the eventual one, and the real picture is what lets you plan rather than panic.

A VM that still trusts only the 2011 certificates after June 2026 does not stop booting on that date. It continues to start and run normally, and ordinary Windows updates continue to install. Nothing fails on the day.

What it loses is the early-boot security pipeline: updates to the Windows Boot Manager, Secure Boot DB updates, DBX revocation-list updates, and mitigations for future boot-level vulnerabilities of the BlackLotus class (CVE-2023-24932). The system is pinned at its current boot-path security posture with no way to advance it.

The consequences are staged, which is the good news for planning. Microsoft has indicated that security fixes for the Windows Boot Manager stop reaching systems on the old certificate by October 2026, and the Windows Production PCA 2011 expiry follows in 2027. The forward-looking risk that matters most is boot media: an OS image, WinPE build, or recovery medium signed only against the 2023 certificates will not boot on a VM whose DB never received them. That is the scenario that turns a deferred housekeeping item into a Sev-1 during a recovery, precisely when you reach for media that a stranded VM refuses to trust.

None of these dates are this week. All of them are close enough that a clustered estate with hundreds of guests should be inventorying now and remediating over the next maintenance windows, not next year. Treat it as scheduled work with a real end date, not as an emergency and not as something optional.

4. Why Windows Server does not behave like Windows 11

This is the single most important operational difference, and it is where general guidance fails server operators.

On Windows 11, the 2023 certificates are increasingly delivered and applied automatically through servicing. On Windows Server, and therefore on your Gen 2 Windows Server guests, they ship inside the cumulative updates from 2024 onward but are not applied automatically. Server requires an explicit opt-in, because applying certificate changes unattended on server and virtual workloads carries a boot-risk that Microsoft chose not to take on your behalf. The conservative default is deliberate, and it means nothing happens until you act inside each guest.

The opt-in is a single registry value that tells Windows to deploy the 2023 certificates and update the boot manager to the 2023-signed version, while leaving the old 2011 certificate in place rather than revoking it. Leaving 2011 in place is exactly what you want at this stage.

# Inside the guest. Opt in to Secure Boot certificate deployment.
# This adds the 2023 certificates and updates the boot manager.
# It does NOT revoke the 2011 certificate (revocation is a later step).
$p = "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot"
Set-ItemProperty -Path $p -Name AvailableUpdates -Value 0x5944 -Type DWord

A background scheduled task processes the change on its own cycle. Trigger it rather than wait:

# Inside the guest. Run the servicing task that applies the update now.
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"

A reboot is then required for the boot manager to switch to the 2023-signed version. All of this runs inside each guest. None of it is done for you by patching the host.

5. The trap: existing Gen 2 VMs fail the KEK update with Event ID 1795

This is the part that is genuinely under-reported, and the reason this article exists.

New VMs created on a fully patched host, Windows Server 2025 or a current Windows 11 Hyper-V host, are initialised at creation with both the 2011 and 2023 certificates, including the 2023 KEK. They are in good shape from day one.

Existing VMs are not updated when you patch the host, because their certificate state lives in their own NVRAM. So you do the sensible thing, set the registry opt-in inside the guest exactly as you would on physical hardware, run the task, reboot, and on a large proportion of existing Server 2019 and Server 2022 Gen 2 VMs it fails.

The signature is Event ID 1795 in the guest System log, with wording to the effect that the system firmware returned an error, the media is write protected, when attempting to update a Secure Boot variable KEK 2023. The virtual UEFI is refusing the KEK write. Because the 2023 KEK is the gate for the DB updates, the entire chain stalls. The opt-in looks configured, the task runs, and yet Windows UEFI CA 2023 never appears in the DB.

What makes this risky is that nothing is broken at the time. The VM boots and runs. You will not notice unless you go looking, or until a post-deadline failure forces the issue. An entire cluster can sit in this state, opt-in set, certificates not actually applied, and look completely healthy on every dashboard you have.

6. Diagnosing the real state across a cluster

Check this programmatically from your management server, the box that already has WMI access to every cluster node, such as your VMM server. This works cleanly for the host-side enumeration below. The per-guest checks are a different matter: reading a guest's firmware variables means remoting into the guest, so run those guest-local where you can, or through your existing configuration-management channel, rather than fanning them out over nested remoting. Driving management server to host to guest in one hop runs into Kerberos double-hop and credential-delegation limits that most estates have not configured for ad-hoc work, and it tends to fail quietly. Do not walk the VMs one at a time in the GUI, and do not trust the registry value as proof, since it records only intent.

First, from the management server, enumerate which VMs are in scope across all nodes. Only Gen 2 VMs have UEFI and Secure Boot; Gen 1 VMs are out of scope entirely.

# From the management server. Gen 2 VMs and their Secure Boot state, all nodes.
Get-ClusterNode -Cluster "HVCLUSTER01" | ForEach-Object {
  Get-VM -ComputerName $_.Name |
    Where-Object Generation -eq 2 |
    Get-VMFirmware |
    Select-Object @{n='Node';e={$_.ComputerName}}, VMName, SecureBoot, SecureBootTemplate
}

The authoritative check has to run inside the guest, because the host cannot see into the VM's applied DB and KEK. Confirm both the boot-critical DB certificate and the KEK gate in one pass:

# Inside the guest. True/True means on track. A False KEK is the 1795 signature.
$db  = [Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes)
$kek = [Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI KEK).bytes)
[pscustomobject]@{
  DB_2023  = $db  -match 'Windows UEFI CA 2023'
  KEK_2023 = $kek -match 'KEK 2K CA 2023'
}

Run that check guest-local across the estate, gathering the results centrally, so you get one table instead of a manual tour. If you do reach in with Invoke-Command, mind the double-hop limit noted above. The VMs where KEK_2023 is false are your remediation targets. Where you want the cause confirmed rather than inferred, pull the event directly:

# Inside the guest. Surface the write-protected KEK failure if present.
Get-WinEvent -FilterHashtable @{LogName='System'; Id=1795} -MaxEvents 5 -EA SilentlyContinue |
  Select-Object TimeCreated, Message

7. Remediation: the template toggle, the opt-in, the verification

When a guest hits the 1795 write-protected failure, the fix is not inside the guest. It is a Secure Boot template toggle performed on the host, which resets the VM's UEFI key store to the template defaults. On a current host those defaults include the 2023 certificates, which clears the stuck KEK store.

With the VM shut down, run this against the owning node:

# On the owning node. Reset the Secure Boot key store via template defaults.
# Toggle to the open CA template, then straight back to the Windows template.
Stop-VM -Name "VM01"
Set-VMFirmware -VMName "VM01" -SecureBootTemplate MicrosoftUEFICertificateAuthority
Set-VMFirmware -VMName "VM01" -SecureBootTemplate MicrosoftWindows
Start-VM -Name "VM01"

The full sequence that works reliably on existing Server 2019 and 2022 Gen 2 VMs is: shut down the VM, toggle the template on the host, start the VM, set the registry opt-in inside the guest if it is not already there, run the Secure-Boot-Update task, reboot the guest, then verify with the section 6 check. KEK_2023 should now return true and DB_2023 should follow. Skipping the host-side template toggle is exactly why the in-guest-only approach fails on these VMs.

8. The vTPM caveat and the DBX revocation trap

Two warnings that will save a bad afternoon, possibly a bad quarter.

First, virtual TPM. If a Gen 2 VM uses a vTPM, you cannot update its certificates in place. The TPM measurements taken during boot incorporate the certificate state, so changing the certificates invalidates those measurements, with direct consequences for BitLocker and any attestation that relies on them. These VMs must be reprovisioned onto a current image rather than toggled. Identify them at inventory time, because reprovisioning is a planned activity involving data and key-protector handling, not a five-minute task. In a clustered estate this is usually the largest single line item in the remediation plan, which is another reason to start inventory early.

Second, do not rush the DBX revocation. Microsoft documents a manual procedure that revokes the old 2011 certificate by adding it to the DBX, the forbidden database. Do not apply that revocation as part of this exercise. Revoking 2011 prematurely can render existing boot media, WinPE images, recovery drives, and provisioning targets unbootable, because they are still signed against 2011. The safe order is strict: add the 2023 certificates, validate that everything boots from both the OS and your recovery media, and leave revocation to a much later, deliberate phase once the entire estate and all media are confirmed on 2023. Adding trust is reversible and safe. Removing it is where estates brick themselves.

9. Templates, golden images, and version-specific behaviour

The highest-leverage single action is to fix your templates and golden images before you touch another running VM. An unpatched template spawns new VMs that are already behind, so the problem regenerates faster than you can remediate it.

Bring every template to a current patch level, apply the template-toggle and opt-in treatment if it is Server 2019 or 2022, confirm Windows UEFI CA 2023 is present in its DB with the section 6 check, then re-seal and resume deploying from it.

Behaviour by version, briefly. Windows Server 2025 hosts initialise new VMs with both certificate sets at creation, so freshly built VMs are clean, but existing VMs migrated onto 2025 hosts are not retroactively fixed and still need the per-guest work. Windows Server 2022 and 2019 carry the certificates in cumulative updates from 2024 onward, apply nothing automatically, require the opt-in, and are the versions most prone to the 1795 KEK failure on existing VMs. Windows Server 2016 is the weakest position, with the thinnest tooling and servicing support for this transition, so treat any 2016 Gen 2 VM as requiring individual validation and, where you can, fold it into a migration plan rather than a certificate fix. Generation 1 VMs of any version are unaffected, without exception.

The pattern behind the list

This is a familiar shape. A long-lived cryptographic artefact, issued and forgotten in 2011, quietly reaches the end of its life and turns into a fleet-wide operational deadline. Nothing is on fire today, which is what makes it easy to defer: the cost of inaction stays invisible right up to the moment a VM will not boot from new media, or a boot-path vulnerability lands with no patch path on a fleet that can no longer take the fix.

The host firmware question compounds it, because it sends people to inspect the motherboard when the answer lives in patch parity and per-VM NVRAM state. In a clustered Hyper-V estate that is dozens or hundreds of independent certificate stores, each able to fail quietly with the opt-in set and the certificates still absent. The work is methodical rather than heroic, and there is time to do it methodically: inventory every Gen 2 guest and template from your management server, verify the actual DB and KEK state rather than trusting the registry, remediate existing VMs with the template toggle, plan the vTPM reprovisioning as its own stream, and leave the DBX revocation for last.

Plan a Hyper-V cluster assessment introduction →