Event details
405 Comments
Thanks to all participants of yesterday's panel for the explanations.
There were a lot of questions regarding the tools and possible scenarios.
For a better understanding, I/we are however still missing what is REALLY going on with the certificate updates
As said in the video, whatever tool used for the update of the 2023's certificates, it is pointing to same registry keys. From my understanding, those keys are defining the status of the update.
Scott clearly mentioned in the video that the OS can only modify the "active" certificates, while the "default" certificates in the firmware can only be updated by a firmware update provided by the mainboard's manufacturer. During the update from Windows,
What is exactly done on the EFI partition on the hard drive? Which files get modified?
What is written to the UEFI firmware ? Should be the KEK and DB, but what if the firmware is partially "readonly" (e.g. not allowing KEK update) ?
Maybe, Scott Shell, could you elaborate a bit? Or better, link an article with the deeper technical details? Most of the technical details are already in the playbook and https://support.microsoft.com/en-us/topic/secure-boot-certificate-updates-guidance-for-it-professionals-and-organizations-e2b43f9f-b424-42df-bc6a-8476db65ab2f but without the deeper detail on the EFI.
Above all tools, knowing what is modified could help advanced people to troubleshoot.
I am especially thinking of all older PC than can NOT have a firmware update and will face the possible mismatch of "half" update (one side with 2011 certificate, other with 2023). Those were partially mentioned during the video.
I am very aware that most of the discussion is related to professional users with supported computers. And that owner of older unsupported PC "may want to renew their machine".
However, plenty of older PC can still be used for other purpose, either on Win10 ESU, Windows LTSC, Linux or whatever OS. So it would be very helpful to be able to know what is going on before throwing those PC in the garbage.
Eventually, for older unsupported computers with possible certificate mismatches, what about disabling SecureBoot completely? Isn't is a better recommendation?About files: In C:\Windows\Boot you will find EFI\bootmgfw.efi and EFI_EX\bootmgfw.efi. The first is signed with 2011 and the second with 2023 certificates. This file exists at up to two places in your EFI partition (depending on how exactly the boot variables are set within UEFI). \EFI\boot\bootx64.efi and \EFI\Microsoft\boot\bootmgfw.efi.
Whichever one or two of these files exist, they will be initially the first EFI file, and replaced by the EFI_EX files.
In the firmware, there are named slots, called Variables, which are updated in this process. When secure boot is active, there are restrictions intact that control which variables can be updated from the Operating System. And each of this updates needs to be cryptographically signed by a key that is already mentioned in these variables. In properly implemented Secure Boot UEFI, the PK and KEK variables can only be updated if the update is signed with a key in the PK variable (Platform Key), and the DB and DBX variables can only be updated if the update is signed with a key in the KEK variable.
Also, if TPM is used and sealed against PCR7, the TPM keys will be resealed against the new PCR7 value derived from the new certificates, at the same time when the variables are updated.
Some firmware versions have bugs, like PK or KEK being readonly, or KEK cannot be updated since Microsoft did not receive a signed EFI variable update for that PK (e.g. because the vendor lost it or no longer exists).
In many cases, there are manual workarounds. For example, the firmware setup may provide a menu where you can manually enroll a PK or a KEK. In this case, if enrolling the KEK works there, it is the easiest workaround. (Suspend Bitlocker, if used, before you do anything in firmware setup since it may reset the TPM).
Or it provides a "Setup Mode" where Secure Boot is active but variables are not protected, so you can use third-party tools to enroll the KEK, and afterwards disable Setup Mode again.
Others only provide a single option that will clear all 4 variables, and enroll a new PK only. In that case, you will need third-party tools to sign the KEKs you want to use with the PK, and the DB and DBX content with a KEK (maybe a third KEK you add yourself), and then you can fill the variables again with these updates. After that,, Windows will be happy and work securely again. Just make sure you don't keep your PK secret key on the machine where an attacker could steal it (as in that case you could just turn of Secure Boot and are not off worse). And make sure not to forget any DB or KEK content needed by the firmware or other hardware, or you may have "bricked" your device if you cannot enter UEFI setup any longer.
The last two options are obviously only for people who like to tinker with their hardware and invest some time in them. The same kind of people who brag with using Arch Linux :-P. By the way, the Arch Linux wiki has a good explanation how to set up secure boot completely from scratch, with or without Microsoft keys, so maybe their wiki is for you :)
In any case, for the foreseeable future, having a system that has secure boot enabled but expired KEK only (or even expired KEK and expired DB) is still more secure than secure boot off, as it will properly protect agaisnt a lot of old attacks. It will not protect against new attacks, but disabled Secure Boot will neither.
There may come a point when the old boot manager lacks features you want to use, and only in this case you'd have to bite the bullet and disable Secure Boot.
I know, many technical details in very condensed form. Probably it gives you some basic understanding and you can find the details on the Internet (or in the Secure Boot specification), or just ask again :)
thanks for the explanations!
In one machine from 2013 already mentioned in an earlier comment some weeks ago with an Asrock mainboard, it seems it does NOT have a "properly implemented Secure Boot UEFI" since the KEK seems readonly, and there is no way to add certificates from the firmware. On that machine, I will stay with the 2011's certificates with SecureBoot enabled as long as I am using Windows on that machine (currently win10 Pro on ESU, so only for 2026). In case of more trouble, I can always disable the SecureBoot.
More challenging is for the bootable USB key I am using for different PC. I will likely keep the EFI files with 2011's certificates there. It seems more compatible across machines.
If the device with expired secure boot certificate after June 2026, whether if it will affect the device daily operation, like machine bootup & shutdown, software usage? Will the device turned off secure boot be affected?
For Secure Boot Off Devices- Certificate renewal is not applicable. There will be no impact, and the devices will continue to operate as expected.
Devices with an expired Secure Boot certificate after June 2026 will experience no impact on performance or boot functionality. However, Secure Boot protection will no longer be active. As a result, any future updates or features that rely on Secure Boot may fail or will not be applicable on these devices.
- Arden_White
Microsoft
To add to what kumarshai88hotmailco said
After the Secure Boot certificates expire, devices that haven’t received the newer 2023 certificates will continue to start and operate normally, and standard Windows updates will continue to install. However, these devices will no longer be able to receive new security protections for the early boot process, including updates to Windows Boot Manager, Secure Boot databases, revocation lists, or mitigations for newly discovered boot level vulnerabilities.
Over time, this limits the device’s protection against emerging threats and may affect scenarios that rely on Secure Boot trust, such as BitLocker hardening or third-party bootloaders. Most Windows devices will receive the updated certificates automatically, and many OEMs have provided firmware updates when needed. Keeping your device current with these updates helps ensures it can continue receiving the full set of security protections that Secure Boot is designed to provide.
We are rolling this out with the Intune policies, and overall it appears to be working well. The new report in Autopatch looks great - thanks.
However, we have encountered a consistent issue with Dell OptiPlex 3040 and 7040 systems.
On these models, running the latest firmware and Windows 11 LTSC (unsupported, we understand), the machines lock up completely a few minutes after boot when network access is available. There is no blue screen or crash dump—the system simply freezes as if time has stopped. This behavior does not appear to occur when the network is disconnected.
These devices have been running since purchase in 2016 and have been using the same Windows 11 LTSC image since it was released, without prior issues.
We have confirmed that disabling Secure Boot in the BIOS immediately resolves the problem. Every OptiPlex 3040 and 7040 that has received this policy is affected.
These models must be on the known good list, but this specific configuration clearly does not work as expected.
Hi Lars,
I got exactly the same behavior on my older machine as described in this previous comment:(complete freeze of the PC after 5 min, and only when network is access is activated, caused by a scheduled task trying to update the certificates, see my comment. My PC is running Windows 10 Pro ESU, and has a i5 4670k CPU from 2013 so Gen4! It has no TPM chip despite having a connector for extra module).
AFAIK, your systems are running Gen6 of Core CPU, correct?What means the "yeah" in AaronCR's question? It is failing despite those settings or no failure anymore after the settings?
Likely keeping SecureBoot activated but disabling the "enable secure boot certifcate updates" will stop running the task freezing the systems.
As mihi responded to my other comment, "for the foreseeable future, having a system that has secure boot enabled but expired KEK only (or even expired KEK and expired DB) is still more secure than secure boot off, as it will properly protect agaisnt a lot of old attacks. It will not protect against new attacks, but disabled Secure Boot will neither."Hello LarsDK,
Do you just have the below config set and its working?
Yeah!
Hi there I've noticed a problem with AMD consumer platforms. Confirmed with two different AMD chipsets, SVM (CPU Hyper-V required feature) is disabled by default. But this is required along with Secure Boot to make use of VBS and other subsequent security features, that are to be set in Microsoft Security App (Defender).
After today's AMA, I think I understand that as long as IT managed systems are configured with this reg key / value - 'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\AvailableUpdates' to '0x5944', that should trigger the system to apply the updated Secure Boot certs as long as the firmware supports the update and the machine has the certs via CU. Can you please verify that my understanding is correct? If it's not correct, what additional requirements am I missing? Additionally, with the above configuration, what does timing look like? Should the certs be applied relatively quickly or is there still a wait period before you should expect the updated certs?
Is correct.
Should be applied relatively quickly (when the scheduled task runs again). Note that the boot manager will be updated only after next reboot (when certificates have been installed properly).
- Pearl-Angeles
Community Manager
Thanks for your participation in today’s AMA! We’ll post a recap of the questions panelists answered during the live AMA, shortly.
what about the 65000 error in Intune.... there are enough people posting this, why isn't it being covered in this discussion thoroughly?
Not super important, It will get fixed by another team soon. This AMA was more about the process and technical background.
I'd also like an answer on if this will be fixed. Here's a really good resource on why its happening for anyone that hasn't found it already. Should be the top result if you search it by title: "Policy is rejected by licensing: Error Code 0x82B00006"
https://patchmypc.com/blog/intune-policy-rejected-by-licensing/
In my environment, we are not currently consuming all the event logs to look for 1808, but I have a MECM (SCCM) baseline looking for the regkey status of "Updated". For those workstations that show "Updated" does that mean they are good? Nothing else to do?
Are you guys aware if there are plans to allow the OS to automatically suspend BitLocker protection when a firmware update comes down via Windows Update on devices where Secure Boot is enabled but the PCR 7 binding is not possible?
Firmware updates coming from WU are currently being prevented from installing when Bitlocker Protection is On and the PCRs are set to 0,2,4,11 (generally devices with Secure Boot turned off). The main concern is a subset of devices that leverage OROMS can not bind PCR7 when Secure Boot is enabled and BitLocker is enabled. This causes an SB enabled device to have 0,2,4,11 PCRs preventing them from receiving important firmware updates with updated Default DB 2023 certs. Depending on the client base to suspend bitlocker protection periodically is not a viable solution and doing it automatically via Remediation script would be a security concern.If a device receives the new certificate in the active db and is later reimaged, would the device lose the new certificate? I'm unclear how reimaging affects the db/bootmgr since the drive has to be en-encrypted?
active db is stored in your firmware/NVRAM, so should not be touched by anything you can do to your drives.
