Thanks for your participation in the AMA! Panelists covered this topic at around 9:10.

Q1: In the common case (no firmware bugs) it does not matter whether the firmware update is installed before or after updating the certificates. The firmware update will provide new certificates in case the UEFI variables are reset, and the certificate update will provide new certificates for the currently running system. If there is a firmware bug that lets the certificate update run into an error, obviously you need to install the firmware updates.

Q5: You will have to update the certificates at a later date, either from the system or via securebootrecovery.efi, or the system will stop booting in case it got a newer bootloader signed with the new certificates. As UEFI generally cannot securely validate timestamps, the update will either (most likely) just work or will require to switch back the system time before applying securebootrecovery.efi, and fix the system time again afterwards. So, as a worst case, a few more manual steps required.

That's how we have interpreted it - by configuring those RKs on devices, you're giving MS the greenlight to deploy the certs automatically to them.

Hi renzobaronti​ I have posted a script in the comments. This allows you to identify the situation at scale.

Ask Microsoft Anything: Secure Boot - February 5, 2026 - Windows Tech Community

Event ID 1795 should include an error code that might be useful to diagnose this (Not all 1795 are equal).

For the KEK update to work, the OEM needs to submit a signed variable update with the new KEK that is signed with the Platform Key. and upload to Microsoft's secureboot_objects repo on GitHub. A list of all platform keys they have received (even those that did not make it into the January CU) with their thumbprint is available at 

https://github.com/microsoft/secureboot_objects/blob/main/PostSignedObjects/KEK/kek_update_map.json

You can check the Subject and Thumbprint of the used platform key on affected machines that did not reload the factory keys, by installing and importing UEFIv2 Powershell module and running:

(Get-UEFISecureBootCerts pk).Signature | Format-List Subject,Thumbprint

If the thumbprint has already been submitted to Microsoft, it will probably be part in one of the subsequent updates and therefore the KEK update may work. If the KEK update causes a firmware error, the OEM might push a firmware update to fix this. So time can fix this.

The most likely case for a vendor like Lenovo to release a firmware update but not submit a signed KEK to Microsoft would be that they simply lost the private key to the PK used in those firmware versions. You can check on a machine that already uses the new factory keys (or by looking at pkdefault instead of pk if the firmware exposes that variable) if it uses a PK with different thumbprint. If yes, that is a telltale sign.

In that case, automated fixing is not possible (if the machine has an active TPM, which it probably has if it is Win11-supported). If Lenovo pushed a firmware update that either updated PK or KEK, it would invalidate PCR7 of the TPM and in case Bitlocker uses that PCR to seal their keys you would end up in Bitlocker recovery (which is a tedious manual step as well). And as long as they cannot sign a new KEK update with the PK as they lost it, Microsoft cannot do anything either.

That's exactly what Secure Boot tries to prevent.

I found these two articles on the Broadcom site that might be helpful.

https://knowledge.broadcom.com/external/article/423893/secure-boot-certificate-expirations-and.html

https://knowledge.broadcom.com/external/article/423919 

Arden - Microsoft

I am not sure why on my Server 2022 testing, but you can just update the KEK the same way you did the PK via EFI and broadcom instructions. they had it on their KB before, then was removed.

you just select enroll PK, then enroll KEK and select the cert on your drive you added to the VM.

now the PK and KEK is updated, start the reg key and updating process, goes to Updated status. you can verify the certs are there after

As for the likeliness of the scenarios, I'd also like to hear feedback from Microsoft. But at least I can list a few scenarios I am aware of:

• Everything works flawlessly. Hopefully the most likely one
• One of the updates runs into a defined error, which is logged to event log and reflected in registry values. You are not off worse than not trying
• Bitlocker Recovery key required: This can only happen if Bitlocker is used and uses PCR7 in TPM in a key protector. In two possible scenarios: 
  • (1) Measured Boot cannot properly reseal the PCR after adding key to DB or KEK database.
  • (2) One of the variables does not persist on boot, but the PCR has already been resealed to the new value
  • In any case, this issue can be totally avoided by suspending Bitlocker before the attempted update for a few reboots. When resuming Bitlocker after the changes has happened and the system rebooted, the new PCR7 value can be obtained and used to re-seal PCR.
• The system freezes/hangs and requires a full power cycle to boot up again (with the old keys). Only a nuisance when deploying the changes remotely.
• The system reboots after apparently having applied the update but one of the values does not persist. As the bootloader is replaced after the first reboot, this will not cause any Secure Boot violations. It may (see above) result in Bitlocker Recovery key as PCR7 has been sealed to new keys but actually present keys are old keys.
• The system reboots, has applied the keys, but the boot fails with a Secure Boot violation due to a firmware bug. In that case, enter Setup, restore the values back to setup defaults, boot up again (again taking care of BitLocker as the PCR7 will not match or was cleared due to the UEFI reset) and best do not try applying the keys before getting the firmware updated (if available)
• The system reboots, but then is "bricked" (freezes on every reboot even before being able to enter the BIOS/UEFI setup). On some old systems, this has been a known, very rarely happening issue for any UEFI variable updates (not just DB/DBX/KEK), when the EFI variable store is almost full. There have been reports about this issue years ago, on very old firmware (think about the age of when Windows 8 came out), only happening very rarely, but if your machine is affected it could have as well happened during a normal DBX update. Probably less likely to encounter this in a corporate environment as machines are newer. And I would assume Microsoft would by now have applied safeguards not to apply any UEFI variables updates (neither DBX updates nor the new Secure Boot Certificate updates) on such devices if the UEFI variable store is almost full.

As the new bootloader on disk will be signed with 2023 certs, it will deny the boot with a Secure Boot violation. But you can boot external media from "C:\Windows\Boot\EFI\SecureBootRecovery.efi" which will add back (just) the 2023 Windows CA certificate to DB, so that the system can boot again and fix up the rest. In this process, PCR7 sealing of TPM will cause a mismatch (if not already the resetting of the UEFI did so), so if you use Bitlocker sealed against PCR7, you'd also need the Recovery Key. Afterwards, the booted system will restore the rest of the KEK/DB/DBX certificates.

Booting from PXE would also require to boot from a different image (signed with the old keys) and chainloading securebootrecovery.efi.