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
This event has concluded. Follow https://aka.ms/securebootplaybook for announcements about future Secure Boot AMAs.
Get started with these helpful resources
405 Comments
- mikemagarelliCopper Contributor
Arden_White RoySasabe Specifically for Server 2025, we're consistently seeing systems show the new certs installed, the registry value shows that servicing succeeded, no errors in the event logs, but also there’s no 1808 event (see screenshot). This is consistent across every 2025 system I’ve seen the new certs on, so I would assume that this is expected behavior and that the server has successfully updated, but I can find no documentation anywhere that says this would be expected behavior on Server 2025. Can the MS team please clarify whether or not we should always expect the 1808 event?
- DennisJorgensenCopper Contributor
Completely same experience here. Can add that the GPO setting Enable Secure Boot Certificate Deployment also doesn't work on Windows Server 2025. Works on earlier Windows Servers.
- mikemagarelliCopper Contributor
Hopefully Arden_White or someone else on the Microsoft team can shed some light on this.
Updated my Secure Boot analyzer script because the script provided in Microsoft documentation appears unclear to me about its usage.
- yukaeCopper Contributor
The tool to assess current state of the machine and the certificates was mentioned during the event. Where will it be released?
- HeyHey16KSteel Contributor
There was a Secure Boot report in Intune, but Microsoft have since (hopefully only temporarily) revoked it due to issues.
- 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.
- McGoldrickCopper Contributor
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 ?
- mihiBrass 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.
- mihiBrass 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.
- mihiBrass 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.