Good eye! I'll see about getting that changed. 

I believe the 

Group Policy Objects (GPO) method of Secure Boot for Windows devices with IT-managed updates page has the correct description.

Great questions. I'll do my best to answer some of these.

For Q1A&B and Q2)
In general, virtualized environment are like virtual OEMs. If you create a new VM in these environments, there's a good chance they'll come with the new certificates. For long running VMs, they'll need to be updated like existing machines in your environment. I'm not familiar with the ins and outs of these environments. A couple of details that I'm aware of:

• Hyper-V support to allow KEK updates is expected to be available in March.
• VMware has some details on their site.

Q3A)

The firmware does not care about certificate expiration and will continue to use the certificates after they expire. The need to update certificates is 1) good PKI practice, 2) necessary to continue signing binaries/programs. The new certificates will allow signing of the Windows Boot manager, future Secure Boot updates, third-party boot loaders and Option ROMs. Without the new certificates, components signed with these certificates will not be trusted by the firmware.

6) There are many nuances to this question. I'll try to give some details

• If the device came with UEFI Secure Boot support and had the Microsoft certificates from 2011. That's a good start.
• If the firmware code for processing the certificate updates operates correctly, then that should allow the three certificates for the DB to be updated without issue.
• The KEK is more complicated. To allow Microsoft's KEK to be applied to a device, it should be signed by the device's Platform Key (PK). Microsoft has been working with OEMs to sign the KEK with their PK and send it back to Microsoft to be included in the cumulative updates. For the manufacturer of devices that have done this, the KEK update should work as well - again assuming no issues with the firmware performing the updates. If there is no PK signed KEK for a device, Windows will emit an 1803 event.

Q7) The Windows RE is using the same certificates and boot loader as the main OS and should not need updating. Bootable images such as PxE, USB drives, etc. will continue to work assuming the device has both the 2011 and 2023 certificate. If you add the 2011 certificate to the DBX, then bootable images will need to be updated to use the 2023 signed boot loader.

Q8) I don't know much about Linux distros. I know there are people in our team that are regularly working with the Linux community and care deeply about it. Adding the new certificates should not affect the trust of Linux since the existing trust is not removed. I don't know why the boot violations would occur. 

Karl-WE​ 

You have asked a lot of the questions I would have wanted answers to and more!

I have not seen Microsoft publish answers to the questions you ask, let's hope we can learn more at the AMA

This looks, like a lot of work for a lot of people to resolve all the issue arising from getting all our Secure Boot certificates updated.

Yesterday when I first heard about this after reading an email. I thought I would kick thing off by running the script on work laptop. So, my laptop which is only 2 years old does need its certificate updating. Now I spent a good few hours trying to update the certificate, but my laptop is stuck 'InProgress' and from all the research I have done it looks like a repair install is the only way it can be fixed.

So now I have another 53 client devices and 6 servers to check over and resolve. Due to a lack of budget where I work, we still have few client computers running Windows10, thanks a bunch Microsoft for keeping me in Job!

These are the most comprehensive guidances I have found and some questions from above are answered in these. I would still like to have them answered in one place or suggest a single "Q&A" page based on relevant comments of the previous and the upcoming session.

1. Guide 1: Very complete: Secure Boot playbook for certificates expiring in 2026

Thanks HeyHey16K​ for sharing the previous session. Please check the comments of this session.

WARNING: When using the GPO to enable the settings, that GPOs are marked. This means you can only configure them one time and then they will stick. Removing or reverting via GPO does NOT work!
The registry settings that directly edit required HKLM items could be reverted. For Example with a GPO Client Side Extension Registry item (GPO WinXP Look).

2. Guide 2: https://support.microsoft.com/en-gb/topic/secure-boot-certificate-updates-guidance-for-it-professionals-and-organizations-e2b43f9f-b424-42df-bc6a-8476db65ab2f
the first script has an issue, using Write-Verbose instead of Write-Host.
Write-Verbose would only work if you save the script to a file then executing the file in PS with -verbose
Otherwise it will not give any output and just the error is there is any.
Also this guidance does not contain the required settings for the registry / GPO etc, but other information how to collect data.

Installing the January cumulative update does include the high confidence targeting data for some client devices, and the number of high confidence devices will increase over the coming months. This allows Windows to identify many devices that are eligible to automatically receive the new Secure Boot certificates without requiring Windows Update or Autopatch connectivity.

However, this applies only to the subset of devices covered by the high confidence data included in the update. It is still important to monitor deployment results in your environment. Event 1801 can help indicate when a device needs attention.

Devices that fall outside the identified high confidence subset require customer‑managed deployment, and this is especially true for servers and IoT systems. These device types are not expected to receive automatic updates and must be updated manually using the guidance in Secure Boot Certificate updates: Guidance for IT professionals and organizations.

Saw this only on computers that have a patching problem. See article:
https://support.microsoft.com/en-us/topic/group-policy-objects-gpo-method-of-secure-boot-for-windows-devices-with-it-managed-updates-65f716aa-2109-4c78-8b1f-036198dd5ce7
October or November 2025 patch level is required

From my understanding, the AvailableUpdates (0x5944) reg key needs to be applied and then a manual fire-off of the scheduled task needs to happen afterward. Once I did this, in this order, the status of UEFICA2023Status went from “NotStarted” to “InProgress”. It took me about 2-3 reboots for changes to take effect. 

Questions I hope to have answered are below:

1. Are all 3 certificates (2 DB and 1 KEK) required to rotate in? How many certificates do we need to check for to meet compliance? Some are checking for just one, some are checking for 3… which is it? 
2. If one certificate is missing in either the DB or KEK databases, is a firmware upgrade of the BIOS required?
3. According to the documentation, there is an option for “Controlled Feature Rollout” using Microsoft Update Managed certificates (MicrosoftManagedUpdateOptIn). Not too concerned about the level of telemetry that is pulled; however, just curious if this is something that customers can turn on to quickly retrieve these certs. Or if it’s necessary for future cert rotations.
4. And! What happens if a computer doesn’t have Secure Boot enabled? Or if Secure Boot is enabled, what happens to that device if not compliant by June of 2026?

I now see the new Secureboot report in Intune. 

thks

I would like to know this too.