Event details
187 Comments
is VM snapshots or checkpoints can restore the VMs OS if it can't boot during or after the secure boot cert update? full VM back up is needed as restoration steps?
Your question boils down to whether a VM snapshot will include a copy of the UEFI variables and/or UEFI NVRAM. I cannot answer this question for all available virtualization solutions, but for those I have been using (Hyper-V, Virt-ualBox, and QEMU/KVM based ones like Proxmox) I can confirm that at least in their latest version, the VM snapshot includes all of this, so it is sufficient to create a VM snapshot to protect against incorrect Secure Boot configuration changes.
That being said, I don't know of any likely scenario where a Secure Boot certificate update can screw your VM so badly that you need to revert to a previous snapshot. In case you use BitLocker in the VM, make sure to have your Recovery Key handy just in case.
(There used to be an older version of Vir-tualBox where not all UEFI variables - like dual-boot configurations - were part of the snapshot, which could cause confusion when restoring snapshots after an OS install - not only related to Secure Boot settings. But I believe this was before Vir-tualBox supported Secure Boot for VMs).
[Ouch, naming of competitor products is not allowed in this community?]
I am running legacy hyper V machine on Windows server 2012 R2 and guest VMs on server 2016 and 2019. DO i need to install secureboot 2023 cert on both hyper V and VMs? what happen if I dont update the secureboot cert to both ?
I assume all those machines have Secure Boot enabled? If not, there is no option nor need to update the secure boot certs.
If Secure Boot is enabled, not updating them (on both) will have the same effect as on any other (physical or virtual) machine: The bootloader will remain stuck on the June 2026 version and Secure boot blacklist will not get updated. So an attacker who gets admin access on either the host or the guests could install a bootkit on the (host or guest) machine they had access to once there is any public exploit for that bootloader or any other blacklisted bootloader. In any case the system will continue working and will still receive security updates for all other Windows components.
thanks for the reply , yes its secure boot is enabled on however Hyper-V is still on unsupported OS server 2012 r2. is there way I can manually /offline install the new secureboot certificate without going to Windows update?
Hey, I came across this Dell Pro 16 Plus, that is missing the UEFICA2023Status registry key. It has the Task Scheduler and all other keys except that one. Should I move forward as normal or is there a scenario where another route is required in this case?
Let me guess, the device came with all the 2023 certificates from the factory already (Or it has been updated before the OS got reinstalled)? In that case it can happen that the key has not been created at all. I cannot tell what exactly causes the key not being created, but everything is fine if the certificates are there.
I checked to see if Event 1808 existed on the system and it did not. Is there another way to check and confirm if the all the 2023 certificates are already installed in the system?
hi,
i work for a public school department. we have a lot of devices (from pretty old to brand new). our resources are limited so we use wds for deployment. is there a manual or procedure? what must we do to ensure that the wds works? how can we integrate the new signed files into the wim's for deployment?
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.
yes, at min sortable, preference would be also option to filter.
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?
