There is some ongoing work to allow OEMs to ship a Platform Key (PK) in a capsule firmware update. This is a large and complicated change and getting it right is paramount. OEMs with lost or expired keys will be able to ship a capsule update that includes a PK with special handling.

It's not clear exactly what's going on. I'll outline some things:

• Ensure the March updates are on both the host and guest
• Trigger the updates to the firmware by setting AvailableUpdates registry key on guests (or use GPO, WinCS, or other method to deploy).
• Monitor event log events - should see success events and may see 1800 that device needs a reboot to allow it to apply the boot manager.

The events can be very helpful.

Secure Boot DB and DBX variable update events - Microsoft Support

On a Hyper-V guest, if you see a 1795 that likely indicates the host needs to be updates. If you see an 1803, that likely means the guest needs to be updated.

The PK on the machines that now successfully updated the KEK is also expired. But probably it does not matter anyway.

Especially when there is a TPM present and Bitlocker is active against PCR 7 (among others), there is no way to change the Platform Key without triggering Bitlocker recovery. On machines that have no TPM, it would be possible, but on those machines you can also just flip the Secure Boot template twice to get the latest certificates anyway (which, for me, still includes the expired Platform Key).

Well, installed the 2026-03 Cumulative update on a host and some VMs.

The PK key on the server is fine, on the VMs the Hyper-V PK key is still the expired (4/24/2014) .

The KEK and DB are fine.

Is this the way it "should" be?

Yes, it should be fine to leave them "InProgress". Once the March updates are installed on the Hyper-V host, this should allow the guests to update the KEK.

Thank you both, this is what I needed to know.

Let the machines that are "InProgress" remain like that until the March update?