Event details
397 Comments
We have Windows Server VMs running on ESXi that are stuck in progressl available updates registry value is 4004.
VMs are fully patched, we've run through the Broadcom documented process to update the Platform Key which allows the KEK db to be updated, and the Dell host server has had the latest BIOS applied, which specifically references the secure boot certificate firmware update.
The VM event logs state Updated Secure Boot certificates are available on this device but have not yet been applied to the firmware; we've confirmed the hosts are running the latest BIOS/firmware version.
2023 certificates are showing in the active DB but not in the default DB. How do we get this process to complete?
The default DB will not change at all by actions done by the Secure Boot updates. If there is a firmware update, it may include them (or provide an option to enable them). If not, live with the fact you will need to run securebootrecovery whenever you reset your firmware variables.
With "Broadcom documented process" you refer to article 423919 in their knowledge base, specifically to use UEFI setup to manually change PK to the one with Thumbprint 3d86...48b5? There should be a signed update available for that one (according to secureboot_objects), but when you went that far and took precautions like about TPM before, why not just repeat the process and enroll KEK available in the same way?
https://github.com/microsoft/secureboot_objects/blob/main/PreSignedObjects/KEK/Certificates/microsoft%20corporation%20kek%202k%20ca%202023.der
Yes, although the Broadcom documentation indicate KEK update as an optional step, but it is recommended to enroll KEK also. At least two VM encountered similar secure boot update failure when KEK update is not enrolled. And the registry key may need to reset to the original 0x5944 to restart the entire progress if it still stucks at 0x4004 after the KEK update.
Q1. Is there a known bug for the GPO setting "Enable Secure Boot certificate deployment" on Windows Server 2025 servers? The registry key AvailableUpdatesPolicy is applied, but the value is never transferred to the AvailableUpdates key. No problem on Windows Server 2022, and servers are updated with the January 2026 cumulative update.
Q2. According to this link: https://github.com/microsoft/secureboot_objects/issues/318#issuecomment-3662004435 applying March 2026 cumulative updates would fix so that the "Microsoft Corporation KEK 2K CA 2023" certificate would be able to apply on HyperV. Is that fix for the Host or the Virtualized VMs with the issue?
Q3. Would the same update in Q2, also help on the Azure VMs, that also have issues with applying the "Microsoft Corporation KEK 2K CA 2023" certificate. Random VMs in Azure has problem with the KEK certificate.For Q2, you'd need to apply it to the host. (By the way, that they target March update will not necessarily mean that it will make it). Apart from that, the known workarounds work without any host updates (if the host is on recent patchlevel):
- Create a new VM and attach the virtual disks to it. That new VM will have the new KEK by default. Be careful with suspending Bitlocker etc. if you use a TPM
- Change the Secure Boot Template in the VM settings twice (back to original) while the VM is powered off. This will not work (raise an error message) if you ever had a TPM attached to the VM
Im testing the Intune policy to enable Enable Secureboot Certificate Updates and Configure Microsoft Update Managed Opt In, but I can see an error on both:
The test device is a Windows 11 24h2 Enterprise.
Interesting. This is a known issue on PRO devices: Microsoft Intune method of Secure Boot for Windows devices with IT-managed updates - Microsoft Support
Did your device do a step-up from Pro via subscription activation? Or is it an Enterprise base image?
Because it also impacts Windows 11 Business - which is also a subscription activation step-up from Pro for M365 Buiness Premium.The device was upgraded from Pro to Enterprise via subscription activation.
I made a post earlier with a bunch of questions but seems the post is deleted (annoying because it took a lot of time)? Can someone pm me to tell me why? Maybe links to external sites (trusted partners I believe), PatchMyPC want to be clear before I post again what the issue is.
Thank you.
In the past I've written posts on these AMAs etc., which then seem to disappear - but if I then view the web page in InPrivate mode, or from a different account, I can see them 🙃
If you mean this post, I can see it - it's still there 🙂Thank you! That is odd for sure, I'm logged in now, can't see it. Opened an InPrivate and there it is. Even if I go to my account and look for recent activity, the post is gone there like I never posted it but InPrivate is there.
Glad of that because it took a while to think out all my questions. :')
Thanks again!
For devices that specifically require a firmware update, should we expect Windows Update to provide that firmware, or should we proactively start pushing firmware to those devices?
We have a fleet of HP EliteBook 600 series, G9/G10/G11, and initial testing has all of them throwing Event ID 1802 in the System event log - 'The Secure Boot update Option ROM CA 2023 (DB) was blocked due to a known firmware issue on the device. Check with your device vendor for a firmware update that addresses the issue.'
Updating the firmware on the devices in question allows the certificate update to complete, and we eventually get Event ID 1808 in the System event log.
tl;dr -Who is handling firmware updates? Microsoft or individual customers? If it's Microsoft, will these updates install as part of a monthly LCU? Our organization currently blocks driver updates via Windows Update.
- Kevin-Sullivan
Microsoft
For firmware updates we recommend you check with your device manufacturer (OEM) on how they are making the updates available to their customers.
Hi,
Question 1
I'd like to know when the report in Intune will be complete? You've got something in the works but no announcement on it or when it will be ready. Currently the report is not working properly (as can be expected by it not being complete), but time is moving closer to the deadline.
Info
https://patchmypc.com/blog/the-secure-boot-status-report-coming-soon-to-intune/
Link to report
https://intune.microsoft.com/#view/Microsoft_EMM_ModernWorkplace/securebootreport.reactview
Question 2
Will the report have more useful information than what is in their currently? I don't want to just see if it has the new cert or not, I want to see the steps I need to take, such as if a device does not have the certificate, is the bios up to date? This can be done to varying degrees via a custom compliance policy, but it is not easy for a few reasons.
- Intune only allows you to use a custom compliance script for one policy, we have 30+ laptop models out there, all with different minimum bios versions. Can be done anyway by making duplicated scripts, but it is messy.
- Different vendors report their bios versions into windows differently, Dell, Surface it is easy to make a version check because they report for example, Dell 5420 needs a minimum bios version of 1.31.0, so I can do a version check greater than or equal to against that, easy. Lenovo however name their firmware back like R1TET46W (v1.25), I can't do a version check against that and a string check would also not be helpful as the text characters change from version to version not just the version number.
Ideally, we want something that has the following in the report.
- Is the device compliant fully, i.e. has a bios version that is current enough and has the keys / Intune policy set to start using them for windows.
- If not, why not?
- Is it that the bios version is not up to date? If so, what is on the device, and what is the minimum version required from the vendor, something like "meets minimum bios revision, compliant or not compliant".
- If the bios is current, is it just that the keys are not set correctly so Windows knows to set the new secure boot certificate?
- What about devices that will never get bios updates because they are out of support? Can that information be presented in the report.
Question 3
What are the actual impacts of devices which do not have everything completed by the time the deadline rolls around.
Will they be unable to boot? Will we be unable to install fresh Windows, will it continue ticking away but be insecure i.e. someone could bypass secure boot if they had physical access to the device?Question 4
This seems important enough that it should have a built in compliance policy in intune to check going forward if the certificate is valid and current.
Thank you! :)
Three questions related to Secure Boot:
- When updating Secure Boot variables (like this db update but also on some older dbx updates), some older firmware has problems due to maximum variable size or size of variable store. UEFI exposes this information via RT:QueryVariableInfo, and when booting Linux, you can see by querying free space of efivarfs. Is there a way from Windows userspace (e.g. Powershell or a NTDLL exported function) to get this information? Max variable length, max variable store, remaining variable store.
- When applying the hardening measures for Black Lotus and adding SVN values to dbx, some older versions of bootmgfw.efi deny booting due to SVN mismatch. This is by design. BUT: When you boot from some recovery media that comes with its own loader that sets its own security protocol file authentication callback (like shim does), to use a fixed set of hashes, and bypasses DBX that way, and chainload this (whitelisted) bootmgfw.efi, the SVN values are still checked in DBX and deny booting. Is this by design? If yes, what is the preferred way to set up such media? Try to remove the signature from bootmgfw and patch the check out? Or use an old version of bootmgfw that does not check SVN yet (like one from 2017 I found on an old Win10 install disk)? Always having the latest bootmgfw on these media is not an option for us, and we'd like to apply the SVN hardenings for "normal" boots (not via this recovery media) if possible.
- The current certificate update will install the replacements for the Third Party EFI CA to DB only if the old Third Party EFI CA is included in DB. However, as Microsoft published signed variable updates for adding them to DB on every system that has the old KEK, nothing prevents an adversary from doing so. Is this taken into account when evaluating security implications of adding anything to DBX which is signed by these keys (nothing revoked yet, but in the future?). E.g. by applying these DBX updates when old KEK is in DB, even when new Third party EFI CA replacements are not there? Or by adding those replacements to DBX at a later stage if not present in DB?
I am aware you probably cannot answer them by heart, therefore I'll give you a week advance notice :)
- Arden_White
Hi Mihi, I noticed that you have been very active answering questions. Thank you for all of your efforts.
Hi Mihi, I’ve noticed how active you’ve been in answering questions. Thank you for all your efforts — it’s been very helpful.
- I don't know of a way to do this in Windows. As far as I know it's not possible.
- As far as I know, there isn’t a way to do this in Windows. The boot managers that enforce the Secure Version Number (SVN) are designed to avoid running if they don’t meet the minimum SVN defined in the DBX. Blocking older boot managers, whether they’re on the internal disk or on external media, is intentional because it prevents rollback attacks. Unfortunately, this also affects some external bootable media scenarios.
You’ll see a new Get‑SecureBootSVN PowerShell command coming in March that should make it easier to check the SVN on a device. - Yes, it is possible to add the new third‑party certificates to the DB if you have administrative or physical access. For devices where this is a concern, we recommend using BitLocker with a PCR7 and PCR11 binding policy. PCR7 measures the Secure Boot state, so adding third‑party certificates to firmware would change the PCR7 measurement and trigger BitLocker recovery.
Thanks again for all your help in the discussion threads — it’s very much appreciated.
Arden
Hello Arden,
thank you for the feedback.
About the answer to the third question:
- To protect against physical access, BitLocker will certainly help. But I don't think it matters whether it binds against PCR7 or PCR4 (among others). As the boot binary signed by Third-Party CA will certainly not be identical to the one used by Microsoft
- To protect against malware having administrator/SYSTEM access, Bitlocker won't help. Attacker can just suspend (or disable) bitlocker before carring on with their attack.
I now tried to answer as many of other people's questions as possible, in the hope that someone answers mine too in return...
How dependent are we on FW updates by vendors? Does Microsoft expect most devices to need updates before cert updates can occur? Or do y'all anticipate most Tier 1 and 2 OEM devices to "just work"?
- Kevin-Sullivan
Most cases will not rely on a firmware update, though we recommend checking for and applying latest firmware updates as a best practice.
On my Azure Gen2 VM, Secure Boot reports True and the dbx entry is present with non‑volatile attributes:
- Secure Boot enabled: Confirm‑SecureBootUEFI → True
- DBX present: Get‑SecureBootUEFI -Name dbx showing active firmware data
Does this confirm that Secure Boot and the updated Secure Boot revocation list (DBX) have already been applied automatically through Windows Update or the underlying Azure platform firmware?
- Arden_White
For newly created VMs, the virtualized firmware should already have the new certificates in the DB and KEK. The DBX is the disallow list. I don't know what comes in the DBX on a new VM. For long running VMs (multiple years), the VM may not have the new certificates.
If you want to know if the VM is running with the new certificates and the 2023 signed boot manager, you can look at the UEFICA2023Status registry key. It should say Updated.
it applies to all 64bit Operating Systems Windows and Linux, Hardware and VMs as well as all Hypervisors.
Dom, you might want to use the script that I posted yesterday to get more insights (at scale).I am using it right now. 😁 Which is how I learned that ALL W11 VMs are already updated and NONE of the physical devices in our (and our customers') fleet.
It seems we'll have to wait for OEMs and MoBo manufacturers to ship firmware updates to unblock them. And/or Microsoft to unblock them via Windows Update. Correct?
