• Yes. Everything will continue to work as it is now, except that you won't receive the latest boot components in upcoming Windows updates, booting from newer external media (or via network) created after the certificates expired (or before but with new certificates in boot.wim) may fail, and the blocklist used to prevent booting older bootloaders or bootkits is no longer updated.
• I guess that is a yes too (I don't know of what kind of packages you talk, but I cannot think of any sense of that word that would touch the boot process in any way)
• It's all in the FAQ. When you have a booting system, set the AvailableUpdates registry key and run the scheduled task. If not, get securebootrecovery.efi from a working machine, copy it to a USB key and boot from it, which should be enough to help get the system installed from any install media, then proceed with the booting system.
• When you try to reimage a system by booting via network or from media, the system that does the reimaging will not boot if Secure Boot is enabled and the boot.wim on the media or the PXE server contains the new certificate. Boot once from securebootrecovery.efi and then it will work again. [On an incompatible device where certificates cannot be installed, securebootrecovery.efi will not work either. In that case, you would have to boot from different media or do the install with disabled Secure Boot, then switch the bootloader to the old one, and enable Secure Boot again.

You do not need a PK installed if Secure Boot is working fine without (depending on firmware) and you have all the required KEKs in the KEK store. The PK is only needed to update PK or KEK stores.

Yesterday I had a test in a similar scenario. Windows 2025 fully up to date and VMware 8.0.2.
Setting the AvailableUpdates registry value to 0x5944 and running manually the Secure-Boot-Update scheduled task, after two run and two reboots I could see the DB updated with the new 2023 certificates. After these reboots I had AvailableUpdates=0x4004 and running the scheduled task again and rebooting the VM again did not change it anymore, the KEK could not be updated (I can see only event id 1801 in the registry, no other errors).
So I guess that if the VM finds the PK null, as is common in VMware environments today, the automatic process could not be completed (https://knowledge.broadcom.com/external/article/423893/secure-boot-certificate-expirations-and.html). PK and KEK must be updated manually as described in the Broadcom KB https://knowledge.broadcom.com/external/article/423919. Only after PK and KEK are up to date the automatic process can be completed and DB and Bootloader can be updated by the Microsoft scheduled task.

Hi Jamie, 

We were hoping to use Intune to manage our SB certs deployment and we use Hotpatch. When we configured the Intune SB policy settings we kept getting the infamous 65000 error on all devices:

Originally this error was attributed to a Windows licensing issue, which Microsoft advised has now been resolved, but we're still seeing the above.

Not seen anything confirmed yet by Microsoft, but there are rumours going around from strong sources (e.g. Rudy Ooms) about Hotpatch being the root cause. We logged a support ticket to MS for help 6+ weeks ago but not had any response on it.

So we resorted to using Group Policy to deploy the above settings, which has worked well in our testing so far. Others have resorted to using Intune Remediations to overcome the Intune policy issue.

It is already possible to deploy the latest Bucket confidence data to a machine without having to install the update it came with (avoiding the reboot). This is commonly used to use the Bucket confidence data shipped with a monthly non-security update without applying the rest of the changes.

https://support.microsoft.com/en-us/topic/a-closer-look-at-the-high-confidence-database-32382469-4505-4ed4-915b-982eff09b5d2#bkmk_deploying_to_other_versions

This will not include fixes of the servicing components (like the one shipped in April that addressed some Bitlocker recovery scenarios) but if your goal is to always use the latest bucket confidence data, it should solve your situation without having to fallback to regular LCU that require a restart.

It means that your firmware vendor has not provided a signed KEK to Microsoft (signed with the firmware's platform key). You have two options

• Contact your firmware vendor (probably fruitless)
• Check if there is a firmware update available, install it
• If the issue persists after installing the firmware update, and the firmware update is supposed to include the new certificates in the Default DB reset secure boot settings so that the default DB is used. Don't forget to suspend Bitlocker if you use it with TPM.

Bitlocker recovery key prompts are never expected to happen if the user does not tamper with their device or (inadvertently) boots from different boot media. During secure boot updates, Bitlocker recovery prompts have happened due to firmware bugs which should be remediated by now by Microsoft (until new ones pop up).