Event details
219 Comments
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
Community Manager
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
Microsoft
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.
If an organisation didn't meet the deadline or for example had some devices that didn't power up for a while. What is actually going to happen. It seems a very confusion scenario. I am also seeing ADKs and other ISOs still provided by Microsoft that have not been updated. Rufus is pretty keen to tell you that its not going to keep working.
Systems will still boot and apply the updates when they get powered up next time.
Also, there are no plans (outside of corporate environments that decide themselves to do so) to revoke old 2011 signed bootloaders soon, so your Rufus stick will still work except on those environments, or if you purchase a brand-new device that does not come with 2011 certificates any longer.
what happens if I deploy the updated certificates to a device that does not meet the minimum firmware version?
- Ashis_Chatterjee
If the minimum firmware version is not met, quite likely it is old firmware that is not being updated by OEM/ODM and has the old Secure Boot UEFI variable defaults. In this case, if you Toggle Secure Boot ON->OFF->ON, the older 2011 defaults from Firmware will overwrite and the Secure Boot Certificates in OS will need to be re-applied. If you do not Toggle Secure Boot OFF, which is not recommended, and you updated the Certificates, all is good, and you will continue to be secure.
Can you clarify how this impacts customers on Microsoft Azure? How are gen1, gen2, and gen2 with trusted launch VMs affected and what remediation actions need to be taken (if any) for each VM type?
- Ashis_Chatterjee
Gen1 are not impacted. Gen2 with Trusted Launch impacted
