Event details
43 Comments
We have rolled out a script to set the Secure Boot registry value AvailableUpdates = 0x5944 and trigger the Secure Boot update scheduled task across ~10,000 devices with Secure Boot already enabled.
The script executes successfully; however, a subset of devices prompts users for the BitLocker recovery key after reboot.
We are trying to proactively prevent this scenario for end users.
We reviewed documentation referencing Secure Boot Event ID 1032 as an indicator of possible recovery prompts, but this event is not present on affected devices prior to reboot.
Our questions:
Is there a reliable way to proactively determine whether a device will request a BitLocker recovery key during the next reboot after applying Secure Boot DB updates?
Are there supported methods to detect potential Secure Boot / firmware trust-chain update failures before reboot so they can be remediated automatically?
There is a section about that in the Secure Boot Troubleshooting document:
https://support.microsoft.com/en-us/topic/secure-boot-troubleshooting-guide-5d1bf6b4-7972-455a-a421-0184f1e1ed7d#ID0ELBP-button
For Scenario 1 (bug in firmware implementation), you cannot reliably detect it. If you have identified affected firmware vendors/versions, you can mitigate it by disabling or suspending Bitlocker before applying the Secure Boot updates, restart another time when they have been successfully applied, and re-enable Bitlocker. (Note that Microsoft does not endorse increasing your attack surface by disabling or suspending Bitlocker, you will have to do your own risk assessment on that).
For Scenario 2 (There is a PXE server early in the boot sequence which will most of the time do nothing more than trigger BOOTNEXT, and uses a bootloader signed by the 2011 certificates), you can mitigate it by moving Windows Boot Manager to spot 1 in your boot sequence or temporarily blacklist the MAC addresses of your devices from the PXE server's DHCP configuration so that PXE boot is not attempted or uses a bootloader signed by the 2023 certificate.
But in general, there is no reliable way to predict whether Measure Boot TPM resealing is working on your current firmware or not, otherwise Microsoft would probably add a safeguard lock for that :-)
We have also seen an uptick of Bitlocker recovery in our environment since performing the same steps. Can i expect that devices that have previously had Bitlocker recovery not be affected by whatever is going on with the April update?
Have you seen today's admin center notice "Users might be prompted into BitLocker recovery screen on device restart" that mentions "Connected Standby" devices, supposedly fixed in this month's (April 2026) LCU? Small possibility it could be related...
Since Microsoft can only update the active UEFI database does anyone know what the behavior will be on older systems that aren't getting a BIOS update to put the new certs in the default UEFI database? Specifically, let's say you do a "restore defaults" from within the BIOS and the 2011 certs from the default database overwrite the new certs in the active database after the 2011 certs have expired. Will the system still boot?
It does not matter whether the certs have already expired, it only matters if you already got the 2023 bootloader. If the new bootloader is already installed (which started happening for some machines with February 2026 LCU) and you reset to system default, your system will not boot but show a secure boot error. You will then need to boot from a USB key with securebootrecovery.efi which will update the one certificate needed to get the system booting again (Windows 2023 certificate in DB), the rest will be fixed from the booted system.
See "Device fails to boot after resetting Secure Boot" in the Troubleshooting Guide:
https://support.microsoft.com/en-us/topic/secure-boot-troubleshooting-guide-5d1bf6b4-7972-455a-a421-0184f1e1ed7d#bkmk_common_failure_scenarios_and_resolutions
For those of us still using SCCM and PXE boot for imaging our devices, is there an expected day of release for an updated SCCM compatible ADK as well as documentation/guidance on how to update our Boot and Image WIM's prior to the June 2026 deadline.
I'm curious about an updated ADK as well as official guidance on how to address PXE w/ WDS:
"A new checkbox, Use Windows Boot Loader signed with Windows UEFI CA 2023, is available in the Data Source tab of boot image properties. When enabled, it updates the boot image to use the boot loader signed with Windows UEFI CA 2023. The checkbox automates the mitigation steps described in KB5025885.The new functionality only works on WDS-Less PXE-enabled Distribution Points."
Importantly, related to this: is there specifically a way to ensure that newly-imaged and re-imaged computers get deployed with the new 2023 cert in their UEFI DB and applied to their boot manager as part of a CM Task Sequence, particularly if they do not already have the 2023 cert in their UEFI DB?
I might expect to continue using the older 2011 cert on the PXE boot image for some time to accommodate the transition, but want to avoid deploying new endpoints with outdated certs, or needing a supplemental update post-deployment with added restarts to address it.
Are there any Updates regarding my Question: "Will Microsoft and/or Broadcom provide a solution to automatically update ESXi VMs with missing KEK/PK?"
The last Answer from PrabhakarMSFT was: "...we are coordinating with Broadcom to bring support in Windows to update KEK on the ESXI VMs. If new VMs are created on latest versions on ESXI, VMs get created with new certificates. For pre-existing VMs, Microsoft is coordinating with Broadcom and will be enabled in the future update."FWIW I'm trying to get a conversation going over here on this: VMware by Broadcom Missing PK-signed KEK · Issue #369 · microsoft/secureboot_objects
I don't know who to bring into the conversation.
Intune's "Secure Boot Status" report has six columns. Five columns are sortable. The one column that can NOT be sorted is "Certificate Status". That seems like the most important column. I understand that we can export the data and sort within Excel, but it would be nice if we could sort by "Certificate Status" directly in Intune.
I have a large number of devices in storage, which are unlikely to be powered on before the end of June 2026. Once the devices are back on line after June 2026, will we still be able to update the certs after the appropriate bios and windows updates are installed?
Yes, the secure boot certificates will be updated when you (or the new device owner) install the next cumulative updates, or re-install a Windows version that has the updates included.
See The Secure Boot FAQ: https://support.microsoft.com/en-us/topic/frequently-asked-questions-about-the-secure-boot-update-process-b34bf675-b03a-4d34-b689-98ec117c7818
Section 1 Q1: What happens if my device doesn’t get the new Secure Boot certificates before the old ones expire?
Section 2 Q8: If the Secure Boot certificates on my device are already expired, can I still receive updated certificates?
We have several devices without 2023 cert in default db where we expect to reset secure boot and reinstall past June 2026. I understand it's possible to install 2023 cert post June 2026, but will Windows Update automatically install 2023 cert past June 2026 since you won't get security updates for boot manager and secure boot via Windows Update past that date?
When performing the reinstall, make sure that you use an ISO that still uses the old boot manager (or it won't boot). As of now, all publicly available ISOs do that, so it depends on how many months/years after June 2026 it will be. As a result, the installed Windows version will also use the old boot manager, but will boot and get LCU without issues.
Once you have done so, the machine will not be different from a machine that has been installed in the past and has not been booted for months/years. So, the next available LCU update will run the Secure Boot scheduled task again and apply the certs. (Just like it will apply any pending Secure Boot DBX updates even if the updates came out mid-2025 and you did the reinstall in 2026)
