Event details
274 Comments
What happens if you set the registry settings on a device that is still using Legacy BIOS? Is the update process smart enough to ignore those devices?
- Pearl-Angeles
Community Manager
Thanks for your question! It was answered at around 0:46 during the live AMA.
The device is not updated (since there is no Secure Boot to update) and the scheduled task Secure-Boot-Update will write a 1801 error event.
My company has around 2000 servers on VMWare that we need to make sure that get updated. We don't want to rely on Microsoft to eventually roll out these updates. I know the February AMA discussed that there might be some tools coming out in March that might help with automating some of this.
I just spent about 2 hours or so with our server team just going through this process to update these machines manually. I mean this is asking a lot to have us touch each server, coordinate with folks on their production servers so that we can shut them off, update the NVRAM file, then reboot them about 2 additional times before we get the 1808 event ID that tells us all is well and good.
I also have a script that supposedly audits our servers and tells us if the certs are active. I just looked at a few machines where it says the certs are active and it gives it a "pass" on the report, but when I go to the registry under secure boot, the status is set to "not started", there are also no event IDs present for TPM/WMI. I mean maybe things updated a while ago, but shouldn't I see "updated" in the registry and not "not started". Can someone verify what we should see in the registry w/ regards to this just for verification purposes?
There is so much confusion over what we need to do. We've spent probably too much time looking at Microsoft documentation on this trying to figure out what to do. My boss doesn't want to wait things out and risk critical servers to have issues with booting at some point. Also, going through 2000 servers with a team of about 5 of us is also a lot to ask to make sure certificates are installed and active. There has to be an easier way to do this.
Prabhakar_MSFTMicrosoft
Hello gmartin_3434 , We have published detection script that helps with collecting data on certificate deployment status in the system. The link to the script is published at Sample Secure Boot Inventory Data Collection script - Microsoft Support . Copy the script and save it and execute on server where you want to verify status. The script exits with code 0 if certs are updated else it exits with 1 indicating one or more certs are not updated. Script also prints data points which provides data points about overall secureboot status, any errors with applying the updates.
rparmar50The status registry will show "updated" only when all required certs + bootmgr is updated. If it is showing "not started" that means that device is not fully updated (either some certs or bootmgr is old) and there is no in-progress update.
Our company does not allow us to use Intune.
Are there any helpful tools or scripts to Inventory?- Pearl-Angeles
In addition to Ashis's response below, the panelists covered your question during the live AMA at 1:59.
- Ashis_Chatterjee
Yes, the Inventory Powershell script in: aka.ms/getsecureboot->IT Managed guide on left Nav has a section on Inventory which can be used as a sample.
Sample Secure Boot Inventory Data Collection script
Copy and paste this sample script and modify as needed for your environment: The Sample Secure Boot Inventory Data Collection script.
During the February AMA, you en-phased that enterprises should leverage intune and build their own dashboard to monitor secure boot states. The guide require Enterprises licences. As an MSP that manage thousand of devices with Business Premium Plan for multiple customer with Intune and Lighthouse it doesn't make sense.
Is there a plan to monitor those states via a compliance policy instead?
And also.. regarding the secured boot compliance policy that will happen to devices that will still have an old certificate, will they continue to show as compliant with the 2011 certificate?- Pearl-Angeles
Thanks for participating in today's AMA! Your question was answered at around 3:24.
Hi guys 👋, thank you for hosting another AMA, and for fixing the Intune Secure Boot report 🙏.
It was advised the 65000 error on the Intune report would be fixed by now, but it's still showing on every device we apply the policy to:
When will this issue be resolved please?
Thank you 🙂- Jason_Sandys
Hi HeyHey16K,
The issue is caused by a licensing issue on our end. The service was updated a 2 or three weeks ago to correct the issue and requires devices update their licensing online. This automatically happens every 28 days I believe but can also be forced. See the Known Issues section at Microsoft Intune method of Secure Boot for Windows devices with IT-managed updates - Microsoft Support for information on this. If you have devices still experiencing the issue, please open a support case for deeper investigation as there are no other known, widespread issues at this time but something else may be going on that requires this investigation.
Hi Jason, thank you for your reply. We already have a case open for this but received no response yet from Microsoft support. We have already run the commands referenced in the Known Issues to force the licence refresh but no joy - local Event Logs are still full of endless 827 "policy rejected by licensing" errors as per my post on yesterday's Secure Boot AMA at
Ask Microsoft Anything: Secure Boot - March 12, 2026 - Windows Tech Community
Could you confirm that the Secure-Boot-Update scheduled task expects Microsoft's Owner GUID on Microsoft's signatures in Secure Boot? We customize the Secure Boot content and it seems that a different GUID causes the task to break the behavior of GetFirmwareEnvironmentVariableA() (used by BitLocker in other things).
Could you also confirm that updating the firmware SVN (4th step of the revocations) only consists in adding SVNs to the DBX? And that for testing purposes, resetting the DBX is enough to cancel the rollback prevention?
- Pearl-Angeles
Your question was covered by panelists during the live AMA at 6:03.
I must have a thousand questions. I'm making one comment per question as that seems reasonable. Posted in no particular order. As of 2026-02-26 I have 22 questions.
I typed up all these questions not knowing there was a February AMA. I'll have to watch that later to see if any of my questions are answered there.
---
When do the 2023 keys expire? See you again in ten years? Or will all you brainiacs be retired by then? :)
You can download the certificates and check their expiration dates. For Microsoft Corporation KEK 2K CA 2023 it's valid until 2038-03-02, after that date Microsoft won't be able to sign Secure Boot updates to the DB and DBX with this certificate
I must have a thousand questions. I'm making one comment per question as that seems reasonable. Posted in no particular order. As of 2026-02-26 I have 22 questions.
I typed up all these questions not knowing there was a February AMA. I'll have to watch that later to see if any of my questions are answered there.
---
I think it was Scott that said (in the Dec AMA) the 2011KEK key can no longer be used to sign updates post-expiration. If a device hasn't received any updates (CA or KEK) by expiration, is it true that device will *first* need to get the (PK-signed) 2023KEK installed and *second* install the (2023KEK-signed) CA into the DB list before bootmgr (or any boot loader for that matter) signed by 2023 CAs will boot? Is that the correct order of operations?
Both updates are independent and there is no required order.
The KEK update (needs to be signed by the OEM because they own the PK) is required before June 2026. Microsoft will stop shipping security updates signed with 'Microsoft Corporation KEK CA 2011' after June because that is when the certificate expires. So DB/DBX updates shipped afterwards will only be signed by 'Microsoft Corporation KEK 2K CA 2023'.
The DB update (signed by 'Microsoft Corporation KEK CA 2011' and probably also by 'Microsoft Corporation KEK 2K CA 2023') is required to be able to boot Windows on a boot manager signed by 'Windows UEFI CA 2023', and optionally some other specific components. There is technically no set date for updating the boot manager, but it helps fully mitigate BlackLotus and other past vulnerabilities. In addition, if the boot manager needs to be patched in the future, it will only be released as a 2023-signed version. Thus the DB update will be required to support the new secure version.The DB update is intentionally signed only by the old KEK, since machines that have the new KEK only will already have the new DB as well. And it prevents attackers from installing the 2023 third-party certificate on machines that only have the 2023 KEK and 2023 Windows certificate (no 2011 KEK) by a signed variable update.
Still, despite being said that Microsoft does not automatically apply 2023 third-party certificates to systems that do not have 2011 third-party certificates "for security reasons", nobody stops an attacker who has local administrative access from doing so (by applying the published DB updates signed by the 2011 KEK).
So those security reasons are pretty moot as long as the machine has the 2011 KEK.
I must have a thousand questions. I'm making one comment per question as that seems reasonable. Posted in no particular order. As of 2026-02-26 I have 22 questions.
I typed up all these questions not knowing there was a February AMA. I'll have to watch that later to see if any of my questions are answered there.
---
How will Windows Update behavior change post-expiration on devices that haven't trusted the 2023 keys? Will they continue to install LCUs normally *except* for boot-critical components? Or fail to take LCUs altogether? Will this be messaged to users/admins somehow (Defender perhaps)? Will this prevent milestone updates (i.e. prevent 25H2 -> 26H2)?
- Pearl-Angeles
Thanks for your participation in this AMA. Your question was answered at 57:36.
They will continue working but will not take Secure Boot/boot manager-specific security updates. This is documented at :
https://support.microsoft.com/en-us/topic/when-secure-boot-certificates-expire-on-windows-devices-c83b6afd-a2b6-43c6-938e-57046c80c1c2
I must have a thousand questions. I'm making one comment per question as that seems reasonable. Posted in no particular order. As of 2026-02-26 I have 22 questions.
I typed up all these questions not knowing there was a February AMA. I'll have to watch that later to see if any of my questions are answered there.
---
Should admins be considering anything with regard to secure boot as it pertains to backup and recovery or system archival procedures (how do we restore and boot a backup in 5 years time if the 2011 keys cease to be trusted)? Will we need to accept a lower security posture in such cases? Will Microsoft backport or provide newly signed bootmgr updates to unsupported versions of Windows so that the Windows secure boot process can be maintained long-term? Is Microsoft working with partners (Veeam, Cohesity, Rubrik, et al) to consider recovery implications? Or will IT pros have to embrace managing our own secure boot keys in such use cases?
