Event details
274 Comments
I noticed that some of my clients (around 5% so far) updated only two of three Secure Boot Certificates.
Intune Remediation script shows the following output: Microsoft UEFI CA 2023 = False, Microsoft Corporation UEFI CA 2011 = True.Two other certificates are showing "2023" data string.
Is it expected that not all the certificates are updated at the same time?
- Pearl-Angeles
Community Manager
For reference, this question was answered at 35:24 during the live AMA.
Thanks for the answer. The script returns the following output for the other two certificates:
Windows UEFI CA 2023 = TrueMicrosoft Corporation KEK 2K CA 2023 = True
Is there any update on KBKB5077181 being updated to address the boot loop issue?
My current status regarding dbx is that the old certificates must be moved there so that the SecureBoot certificate update can be completed successfully (managed IT environment with Windows 11 Enterprise licenses). Will there also be instructions or a PowerShell script that performs or explains this process?
Thank you for your time.- Jason_Sandys
Microsoft
Hi SebastianKIT​,
DBX is for explicit revocations in case of compromise or similar. That is not the case here and is part of this process. Adding the old certs to DBX would cause all current boot critical components to become untrusted making the system unbootable. We would need to update every boot critical component to re-sign it on all in market OS versions which would be an even greater logistic nightmare and would add not true value. Ultimately, both certs of certs will remain trusted and there isn't an explicit reason to ever change this (unless a cert is compromised as noted).
Will Microsoft release an OS upgrade that requires the EFI partition to be signed with the 2023 certificate? If so, is this expected in Windows 11 26H2, and has Microsoft announced anything about this? We want to avoid upgrading devices if it will re-sign the EFI partition before the new certificates are installed.
- Pearl-Angeles
Your question was answered at 38:23 during the live AMA.
We've successfully updated some of our devices with the 2023 cert, and tested how PXE boot in SCCM would work. PXE boot worked fine when both 2011 and 2023 certs were enabled, which makes sense, and after revoking the 2011 cert, did not work, since the boot.wim doesn't contain the 2023 cert. A couple of questions:
Will the boot.wim naturally get the 2023 cert, if we keep SCCM/Windows SDK up-to-date?
Once we pass June 2026, will devices that didn't successfully get the 2023 cert yet still be able to PXE boot?
Will the 2011/2023 cert be able to live side-by-side in the boot.wim?- Pearl-Angeles
Thanks for participating in today's AMA! Your questions were covered at 18:25.
How important is it that the system already boots trusting the 2023 cert instead of the 2011 cert? Is it okay for the system to continue booting using the 2011 cert as long as the 2023 KEK and DB certificates install?
- Pearl-Angeles
Your question was answered at 26:48 during the live AMA.
how can we get a compliance report if we do not use AutoPatch ?
- Pearl-Angeles
In addition to Ashis's response below, your question was also answered during the live AMA at 23:35.
- Ashis_Chatterjee
Autopatch is one of the ways, and it is not a requirement. You can inventory the devices in your environment using the sample powershell in:
aka.ms/getsecureboot->IT Managed section (on left Nav)
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.
For Devices Managed in SCCM. Will these be addressed through the Cumulative updates? Or is there other intervention we should be working towards?
Deleted.
if not updated, will not get security update means, is it related secure boot related update or OS related security related patch/update?
All updates that change the boot manager will no longer get applies. Usually these are secure boot related security updates, but maybe also bugfixes for exotic boot scenarios.
Normal kernel-level and user-level security vulnerabilities will be continued to be fixed.
