Event details
It's time for our second Ask Microsoft Anything (AMA) about updating Secure Boot certificates on your Windows devices before they expire in June of 2026. If you've already bookmarked Secure Boot playbook, but need more details or have a specific question, join us to get the answers you need to prepare for this milestone. No question is too big or too small. Update scenarios, inventorying your estate, formulating the right deployment plan for your organization -- we're here to help!
On the panel: Arden White; Scott Shell; Richard Powell, Kevin Sullivan
How do I participate?
Registration is not required. Simply select Add to calendar then sign in to the Tech Community and select Attend to receive reminders. Post your questions in advance, or any time during the live broadcast.
Get started with these helpful resources
327 Comments
- yukaeCopper Contributor
The tool to assess current state of the machine and the certificates was mentioned during the event. Where will it be released?
- jeddunnCopper Contributor
I would like clarification on the process on machines that have no internet access. We have 8 domains that have nothing but Windows 10 and 11 LTSC.
- Arden_White
Microsoft
There are several approaches that can work for offline environments. If the devices are typical client machines such as desktops or laptops, they will usually receive the Secure Boot certificates automatically through the monthly cumulative updates if they are identified as high confidence devices. Another option is to manage the deployment directly by instructing the devices to install the certificates through Intune, Group Policy, or registry-based configuration.
It is important to monitor each device in your fleet to understand its current status. Several registry keys and event log entries report the state of the Secure Boot update process. These documents are being updated this week, so check the Change log on each page for the latest information.
Building a dashboard that tracks these signals will help you understand how the deployment is progressing. In particular, watch the BucketConfidenceLevel in Event 1801, since it indicates whether the device qualifies as a high confidence system for automatic updates.
- McGoldrickOccasional Reader
According to CMPivot in ConfigMgr, we're detecting over 1500 Windows 11 devices without the "UEFICA2023Status" registry key. Why would this be? We had planned on using this in a detection scenario where we could flip the AvailableUpdates key on devices where the "UEFICA2023Status" key was "NotStarted"
- Gunnar_PutzCopper Contributor
We previously had access to the new Intune Secure Boot Certificate Status Report in our tenant, but as of today the report is no longer visible, without any tenant-side changes.
Can Microsoft confirm whether this report has been temporarily rolled back or disabled as part of a service-side change, and whether there is an expected timeline for when it will become available again?
- patgerberBITBrass Contributor
The Secure Boot status report is temporarily unavailable in Windows Autopatch. This documentation remains published for reference and will be updated when the report becomes available.
https://learn.microsoft.com/en-us/windows/deployment/windows-autopatch/monitor/secure-boot-status-report- Gunnar_PutzCopper Contributor
Thanks for sharing
- kumarshai88hotmailcoCopper Contributor
About the Media Update, do we have latest ISO available with 2023 Certificates updates for Server OS like 2016, 2019, 2022 in Volume licensing portal?
Secondary how can I update the Custom build server OS iso image (that we built using WinPE and ADK) if required ?
- mihiCopper Contributor
For the second question, refer to this Knowledge Base article:
https://support.microsoft.com/en-us/topic/updating-windows-bootable-media-to-use-the-pca2023-signed-boot-manager-d4064779-0e4e-43ac-b2ce-24f434fcfa0f
- jeddunnCopper Contributor
Concerned about the inconsistent registry values we are seeing. In the Secure Boot Playbook, it mentions that the device should have a key of UEFI2023Status set to Updated if the device has been through the process. We have a high number of machines that don't have this but the value for WindowsUEFICA2023Capable is set to 2.
- mihiCopper Contributor
I cannot tell from experience here, but from the documentation of these keys I would assume this would happen if the original AvailableUpdates value included the 0x0004 bit and it is still there (i.e. it ended with 0x4004 or 0x0004), because there is no KEK update available for the machine's platform key. UEFI2023Status is (correct me if I am wrong) tracking KEK updates, but WindowsUEFICA2023Capable is not (it is only tracking DB and boot manager updates).
Can you share from one such machine:
- initial value of AvailableUpdates (as you set it)
- current value of AvailableUpdates
- Which related event IDs you are seeing in event log
In case the situation points to KEK, you might also want to check the contents of the KEK variable and the thumbprint of the platform key.
- Arden_White
Microsoft
mihi, I think you're right. If AvailableUpdates started at 0x5944 and is now 0x4004, that would indicate that a PK signed KEK from the OEM isn't yet available. There is an ongoing effort to work with the OEMs to fill in as many PK signed KEKs as possible.
A device with setting 0x4004 will continue retrying to apply the KEK until one shows up, which is okay. I believe it'll also emit an 1803 event each time it doesn't find one.
- Arden_White
Microsoft
UEFI2023Status and WindowsUEFICA2023Capable serve related but different purposes.
- WindowsUEFICA2023Capable was originally created to help validate the move to the 2023 signed boot manager. This was needed so the 2011 certificate authority (CA) that signs the older boot manager could be added to the DBX, which prevents 2011 signed boot managers from being trusted. This key only indicates that the 2023 CA used to sign the boot manager is present, and that the device is running the 2023 signed boot manager. When both conditions are true, the system can safely add the 2011 CA to the DBX. The primary purpose of this key is to help protect against boot manager rollback attacks.
- UEFI2023Status goes further. It accounts for the presence of the 2023 CA, the 2023 signed boot manager, the updated KEK (Key Exchange Key), and the third party CA certificates when those are required. When all of the new Secure Boot certificates and the 2023 signed boot manager are in place, this key reports “Updated.” Its primary purpose is to confirm that the device has the full set of updated certificates from Microsoft along with the correct boot manager in use.
More details on these registry keys can be found on
Registry key updates for Secure Boot: Windows devices with IT-managed updates
- Pearl-Angeles
Community Manager
Thank you everyone for your participation in this Secure Boot AMA! Below are the questions the panelists answered live, along with associated timestamps:
Question – What happens to devices after a certificate expires? – answered at 1:14.
Question – I understand these devices will continue to boot after June 2026 even with Secure Boot active. However, what happens if there are changes e.g. to bootmgfw.efi or the underlying hardware? What would be the impact? Can we let such a device live until HW dies to avoid replacement still good working HW? – answered at 2:18.
Question – If a firmware update for an older machine is released after June 2026, will it be possible to install/deploy the new certificates manually at that point? – answered at 3:53.
Question – Can you provide clarification on this? Does Microsoft currently deploy the Secure Boot 2023 certificates using a hybrid rollout model (telemetry-based CFR combined with optional policy-based control)? – answered at 5:08.
Question – At what point will policybased opt in become the primary or required mechanism for IT managed devices? – answered at 6:37.
Question – Could you talk about the device's local Secure Boot enforcement mode (Strict, Standard, Audit etc.) please? Someone in our team mentioned it today - that if devices are in Strict mode they won't boot without the new certificate? I've not seen this mentioned in the MS docs I've read. – answered at 9:10.
Question – We've been seeing devices that appear to be eligible for the automatic Secure Boot cert updates based on the documentation available via MS but don't seem to progress. Can you confirm the minimum “eligibility checklist” for the automatic Secure Boot certificate update (OS baseline, update level, UEFI + Secure Boot, diagnostic data level, etc.), and which items are hard blockers vs “recommended”? Once a device is eligible, what is the typical timeline (hours, days, weeks) to observe progress? – answered at 13:46.
Question – Can you elaborate on the differences between the active db and the default db? This seems to be a common point of confusion. – answered at 15:44.
Question – If diagnostic data/telemetry is disabled, what specifically stops working? Does it prevent Microsoft from delivering the secure boot update altogether, or does it mainly impact reporting and insights? – answered at 17:19.
Question – what is the process to update devices with currently safeboot disabled.? – answered at 19:09.
Question – We have several physical HyperV host servers where Secure Boot is currently disabled at the Windows hypervisor level, while the guest virtual machines have Secure Boot enabled. Please confirm whether it is still necessary to update the compatible firmware on these HyperV host servers. – answered at 21:32.
Question – Is there (or will there be) a tool or series of PowerShell commands that can be used to assess the current status of the computer and 2023 Certificate? – answered at 22:46.
Question – Can we proceed with the firmware upgrades on the physical HyperV servers with OEM Support before Microsoft releases the fix of event ID 1795 (write protected) on March 10th? – answered at 23:48.
Question – Are there other mitigations we can take in our environment to ensure devices that cannot get the certificate are less vulnerable? – answered at 24:38.
Question – You mentioned that as long as a device doesn’t log a specific Event ID indicating it’s blocked from receiving the Secure Boot update, the update will be delivered in the coming months. Which Event ID are you referring to 1801? – answered at 26:12.
Question – I thought I heard someone say that Server OS shouldn't be expected to receive updates via CFR. Did I hear that correctly? If yes, can you elaborate? – answered at 27:22.
Question – When stating "Microsoft will push the new certificates through Windows Update", what does that mean specifically in the secure boot pipeline? You are pushing 2023 into the DB? You are signing the Boot Manager in the EFI partition with the 2023 certificate? you are pushing 2011 into the DBX? What happens when a machine is reimaged with a factory or custom image? – answered at 29:34.
Question – Will Microsoft force the revocation of the 2011 certs at some point? – answered at 35:34.
Question – What’s the best approach to use for dual-boot devices? Either 2 Windows instances or a Linux and Windows setup? – answered at 36:51.
Question – Is there a plan for Microsoft or OEM to only ship hardware with new 2023 certs? Assuming that when option ROM expire it will not be possible to certify new devices after this date? I.e. Dell release new laptop model in Jan 2027 will only ship with 2023 certs? Does this mean not compatible with old 2011 bootloaders (Operating Systems) – answered at 40:04.
Question – What is happening with consumer hardware? For example, someone’s Grandma who doesn’t know what Secure Boot is but has a 5-year-old Windows 11 laptop? – answered at 41:06.
Question – Is the presence of event ID 1808 sufficient to validate the successful Secure Boot certificate renewal or should we additionally verify the certificate expiry details? – answered at 41:39.
Question – If we don’t use Intune, what does Microsoft suggest as the most reliable method? – answered at 42:14.
Question – Can you please further document actions to undertake when a system doesn't boot after enabling secure boot from the BIOS, like precising all the mandatory settings to implement for it to work and possibly bringing the host back to a secure baseline which allows it to boot with the setting enabled, this aspect isn't documented properly and or I'm missing where to look at. – answered at 44:22.
Question – For the third-party antivirus it will have any affect if the certificate doesn't update? – answered at 43:39.
Question – I'm doing test in my lab, and i have successfully completed the update of the Secure boot via RegKey, but i have noticed that the boot loader is updated with the new certificate that will expire to May 2026, this will be update automatically during the normal patching process? – answered at 46:08.
Question – Am I correct in assuming that the default db will only be updated by an OEM's BIOS update? In other words, Microsoft updates would only update the Active db, and never the default. Follow up question: What is the risk of not updating the default db when the active db is up to date? – answered at 48:01.
Question – Is my understanding correct? If you have a common Dell, Lenovo, Surface device you 'should' be fine just to make sure the UEFI / BIOS is up to date, and then leave it for Microsoft to update the certificate on the client via CFR? If you have some wacky bit of hardware, like custom built gaming pc, odd meetingroom system, then you might need to manually add the reg key manually to tag it as a known good system? – answered at 49:37.
Question – The newest ADMX/ADML template files contain settings to control the Secure Boot cert push/etc. is this actually needed? – answered at 52:18.
Question – When will Windows 365 gallery images contain the new secure boot certificates? – answered at 53:39.
Question – For manually installing the Secure Boot certificate update, is updating the BIOS the only way to do it? If I’m remembering correctly, the Microsoft-provided steps mainly prepare the device to receive the update from Microsoft, but don’t actually provide a way to manually install it. Can you confirm? – answered at 54:10. - JpanskiBrass Contributor
Hi, Most of this information seems to pertain to clients. I have a question about servers. HPE released an article, https://support.hpe.com/hpesc/public/docDisplay?docId=emr_na-a00156355en_us&hprpt_id=ALERT_HPE_3088457 that says "To enable the Windows UEFI CA 2023 certificate, install the latest BIOS version on each platform. Reset "All Keys to Platform Defaults" is required to activate the Windows UEFI CA 2023 certificate after latest BIOS is installed."
Why is the last step necessary? What if it's not done? Why isn't it necessary on clients to do this? Just wondering because it is a very manual disruptive process that will take quite some time. Thank you in advance.
- mihiCopper Contributor
The behaviour is exactly the same on servers as on clients:
- For hardware vendors (Dell) to push the new certificate to the active db, a manual step is required within the firmware (followed by possibly additional steps in the OS like Bitlocker recovery). The reason for this is that TPM's PCR7 register will seal keys against the content of those certificates in the active db. Which means whenever this value changes outside of the control of the OS, the TPM will deny access and keys in there (e.g. used for Bitlocker) will be unusable, triggering Bitlocker recovery.
- Operating system vendors (Microsoft) can push new certificates to the active DB if they receive a signed Variable Update for the new KEK that is signed by the hardware vendor's platform key. This has happened for many different devices (probably also for the server from Dell) and it can be applied later in a LCU if the hardware is in the low-risk bucket, or by various ways of the sysadmin by pushing registry keys, group policies, Intune etc. This update is possible since the OS will at that moment have access to the keys in TPM and can reseal them to the new PCR7 value. So it will change the active DB and the TPM at the same time. Which the hardware vendor cannot do as the TPM will only allow access in very specific stages of the boot process where no firmware of the vendor is still running.
- The only difference between client and server SKUs is that on clients, Microsoft will use Controlled Feature Rollout to update the certificates earlier, while on servers they will only come with cumulative updates and only for hardware that is known to not show any issues with installing them.
My questions:
- Did you try setting the AvailableUpdates registry key on such a machine and verify that it will indeed not update the certificates? If yes, what error is in event log? I would assume it does update them by now.
- What is the thumbprint of the Platform Key? You can find it via PowerShell UEFIv2 module:
(Get-UEFISecureBootCerts pk).Signature | Format-List Subject,Thumbprint
- Arden_White
Microsoft
mihi provided an excellent explanation. I will only add a bit more context on why hardware vendors sometimes release new firmware during the Secure Boot certificate updates.
- Defaults: Vendors may update the default Secure Boot variables, such as DBDefault, so the new certificates are included as part of the platform defaults. This matters if someone resets the Secure Boot configuration, because the reset will then load the updated defaults and ensure the active database contains the newer certificates.
- Firmware behavior: In a small number of cases, a platform may have a firmware issue that prevents the active Secure Boot variables from updating correctly. A firmware update addresses this so the device can accept and apply the new certificates.
Both of these situations are examples of the hardware vendor looking out for customers and making sure the Secure Boot update process is reliable on their platforms.
- Eric_BlCopper Contributor
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?- mihiCopper Contributor
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 :)
- Eric_BlCopper Contributor
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.
- Sugus0769Copper Contributor
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?
- kumarshai88hotmailcoCopper Contributor
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.