Event details
281 Comments
I have one more question.
I successfully tested the update on a representative group of devices. The entire procedure completes correctly — the certificates are properly enrolled into DB and KEK, and the Boot Manager is signed with the new certificate.
However, the BIOS still does not contain the new certificates in dbDefault (and KEKDefault), and I am not sure whether a future BIOS version with such configuration will ever be released.
Should I proceed with the deployment to the remaining machines?
Is there any potential risk in having the new certificates present in DB while they are not present in dbDefault?
Yes, proceed with deployment.
The risk is users who are able to enter UEFI setup and mess with Secure Boot settings (set them to default) or reset all UEFI settings to default.
If the 2023 cert used to be installed in DB and the new boot manager is used, this will result in a machine that will not boot unless you either disable Secure Boot or boot the machine from securebootrecovery.efi. Also it will require a Bitlocker Recovery Key if Bitlocker is used (protected with TPM PCR 7+11 and maybe others) after having done either one of these.
Therefore, your support staff should know about this potential issue so that they can help the "curious" user get the machine working again. It may be good practice to protect the firmware setup of such machines with a password to avoid this scenario.
Is June 24, 2026 (the expiration date of the old KEK) a hard deadline?
After this date, will the procedure for deploying the new certificates to the DB and signing the boot manager with the new certificate no longer work?
Or will it still be possible after June 24 by using the registry entry together with running the scheduled task?- Arden_White
Microsoft
Yes, the KEK certificate expires on that date, Microsoft UEFI CA 2011 expires on June 27th and Microsoft Windows Production PCA 2011 on October 19, 2026. These are hard deadlines.
The procedure for updating the certificates does not change after the certificates begin expiring. What changes is for the ability of the device to get security updates to the boot level components.
When Secure Boot certificates expire on Windows devices - Microsoft SupportThank you for the clarification. Just to make sure I understand everything correctly:
If, for example, I power on a “forgotten” computer in December 2026 that still contains the old certificates, will I still be able to perform the certificate update procedure on it without issues, so that the device can continue receiving security updates for boot components?
Am I understanding this correctly?
Hi,
I have a specific technical question about SBAT that I could not find addressed anywhere in public documentation, forums, or Microsoft's own tooling.
My system (MSI MPG Z590 Gaming Plus, Intel i7-11700K, Intel PTT TPM 2.0, Windows 11 Pro 25H2) has been logging Event ID 1796 with UpdateType: SBAT on every boot since the March 2026 out-of-band update introduced the SBAT update attempt. HResult: -2147024895 (0x80070001 — ERROR_INCORRECT_FUNCTION).
The system is otherwise fully compliant:
- UEFICA2023Status: Updated
- WindowsUEFICA2023Capable: 2 (2023 cert in DB, booting from 2023 signed boot manager)
- AvailableUpdates: 0x0400 (only SBAT bit remains, stuck)
- SBAT\UpdateStatus: 2
- Secure Boot enabled throughout, never disabled
- No manual registry or certificate modifications — everything was applied via standard Windows Update and an OEM BIOS update provided by MSI
Two things I cannot find explained anywhere:
1. Every documented case of a failing SBAT update shows HResult 0x800700c1. My system returns 0x80070001. These are different error codes — 0x80070001 is ERROR_INCORRECT_FUNCTION, not ERROR_BAD_EXE_FORMAT. I cannot find any public documentation, tool, or forum post that addresses 0x80070001 specifically in the context of a SbatLevel write attempt. What does this code indicate at the firmware level?
2. SbatLevel is a Boot Services variable. The write attempt happens during boot. On this specific platform (Z590 + Intel PTT), the write has been failing consistently across multiple BIOS versions and multiple clean Windows installations. Is there a known class of firmware implementations on this generation of Intel platform that cannot support the SbatLevel write, and if so, is this an expected/documented limitation or a gap that needs addressing before June 2026?
I am not looking for a workaround. The system is functional and secure. I am looking for a technical explanation of what this specific error code means in this specific context, because it does not appear in any public resource I can find.
Thank you.
This is odd. The aforementioned bucket hash lists as High Confidence in the 2026-03 version of C:\Windows\System32\SecureBootUpdates\BucketConfidenceData.cab (Generic_OEM_3.json), yet it is missing in the detailed bucked confidence lists published by Microsoft at https://github.com/microsoft/secureboot_objects/tree/main/HighConfidenceBuckets which are, as I understand it, supposed to match the lists shipped in this update.
So for one part, it explains why the automatic LCU tried to apply those updates on your machine.
It does not, however, explain why that hash appeared on that list, despite the machine obviously being unable to cope with the consequences of even just installing one Windows 2023 certificate. And it does not describe why this hash is missing in the detailed listings.
Perhaps Arden_White can shed some light on this?
I´m still getting Event Error 1795 in TPM-WMI on Hyper-V Gen2 VMs with Inplace Update History. The system firmware returned an "Access denied" error when attempting to update a Secure Boot variable KEK 2023. The signature information for this device is listed here. DeviceAttributes: FirmwareManufacturer:Microsoft Corporation;FirmwareVersion:Hyper-V UEFI Release v4.1;OEMModelNumber:Virtual Machine;OEMManufacturerName:Microsoft Corporation;OSArchitecture:amd64; BucketId: 4e22d051e8c143d2875b9d16ef2241c7ec548985a21e5073126d3c1f9bf53bb2 BucketConfidenceLevel: Under Observation - More Data Needed. For more information, see https://go.microsoft.com/fwlink/?linkid=2169931
I can Workaround the Problem with changing the Secureboot Template. Is this a supported solution for this Problem ? CoPilot tells me no, and says that i had to Recreate the VM.
What consequences might this workaround have for the future?
If your VM has a TPM (or had one in the past) the UI will not allow you to change the Secure Boot template. If you force it to change in another way, it will render your VM unbootable (in the same way that your VM becomse unbootable if you mess with the TPM in another way). Therefore, you'll need to recreate the VM in case it has/had a TPM.
If your VM has no TPM (and never had one in the past), you can change the Secure Boot template twice to get the new certificates.
In other words, if the workaround works for your machine and it is still bootable afterwards, you should not expect any negative consequences later. The only negative consequence of the workaround can be that your VM is unbootable right after performing it, and you need to recreate the VM at that point (and suffer downtime of that VM until you have done so).
I'm surprised that, even after the March LCUs, almost none of my nearly 8,000 workstations are in the high confidence database yet. We run a majority HP laptops with mostly standard supported models from within the last few years, and Windows 11 24H2/25H2 with BIOS reasonably up-to-date for most devices. I would have expected to have seen many more devices attempting to update by now through Windows Update. Why is it taking so long for these devices to start the process? Your advice in the videos seems to lean towards most devices being updated automatically through Windows Update and we would have to manually deal with the remainers. At this point I'm unsure whether to continue waiting for the LCUs to hopefully and eventually update the majority, or get my devices enrolled in CFR already, or not even wait for MS to do this and start updating devices myself. Time is ticking, right?
I have the same situation. 20,000 endpoints using standard Dell models purchased within the last 1-4 years and only approximately 800 endpoints are showing the 'Updated' status in the 'UEFICA2023Status' registry entry. We have also pushed out the latest BIOS. Will we see more auto updates in April or do we need to start taking manual action on this? Would love to see a Microsoft response on this.
- Arden_White
Thanks for raising this. What you are seeing is consistent with how the High Confidence rollout is designed to behave early on.
The automatic path is intentionally cautious. Devices only enter the High Confidence database after we have sufficient real‑world servicing and reliability signals for that specific hardware and firmware combination. Early in the rollout, that means coverage grows slowly even on modern, well‑supported systems, especially when BIOS or firmware was updated recently and needs to be re‑observed.
The January, February, and March LCUs primarily established the pipeline and initial confidence data. We expect significantly more devices to become eligible in April and May as additional telemetry is collected and more hardware buckets graduate to high confidence. That expansion is already planned and does not require changes on your side beyond staying current on servicing updates.
For organizations that prefer not to wait, taking a managed approach using the published guidance is a valid option. The key point is that low numbers today do not indicate a problem with your devices, only that we are still building confidence before broad automatic deployment.
We’ll continue to expand coverage carefully and share updates as the rollout accelerates.
Arden_White mihi - I have a more general question as well. If machines are not able to update to the new certificates at all, how will this affect the installation of future Windows feature updates?
On all of my machines (both the Dell machines that seem to be able to get the partial 2023 cert updates and the HP z840 that seem to not be able to get anything related to the 2023 certs), I've been able to upgrade to the latest feature updates using the AllowUpgradesWithUnsupportedTPMOrCPU registry hack. Is there any reason to believe, based on current knowledge, that future feature upgrades might be blocked on these machines as a result of the 2011 cert expiration?I had exactly the same thought. Current answers below are not completely clear on the long term.
Scott and Richard added some contributions in a related question in the video:
https://www.youtube.com/live/ixq4RP33Am4?si=ccMm0X82PHChs40J&t=2303
From my understanding, it seems quite likely that a future Windows 12 or what ever coming next will REQUIRE Secure boot with the Boot manager signed with the 2023 certs only.
This would mean some older machines what were NOT able to update the certs will NOT be able to install such future version of Windows.
Is that correct?It could be seen as another way from Microsoft to get rid of older machines.
But for simple people just ok with their current old machines and not willing to buy anything newer e.g. for environmental concerns, it means the end of a supported version of Windows in their machine. Sure, it will happen some times, sooner or later.
But Microsoft could help those people to stay on their older machines if they could sell them more years of ESU (after oct'26, ESU is said to be for business only, NOT for consumers) or even better to make the LTSC editions of Windows 11 (as the 24h2) officially available for those people!- Arden_White
A few clarifications that may help.
The goal here is to keep all supported devices updated with the newer Secure Boot certificates so they can continue to receive boot‑level security updates over time. In most cases this happens automatically. The determining factor is firmware capability, not device age. Older devices, including devices that are no longer in OEM support, can successfully update the certificates as long as their firmware implementation is able to accept them. The main limitation arises when a device’s firmware has an implementation issue that prevents the certificates from being updated, and there is no firmware update available to address it.
If a device can’t install the 2023 Secure Boot certificates, that does not by itself block current Windows feature updates. Those systems will continue to boot and can continue to receive standard Windows updates. What they won’t receive going forward are new boot‑chain security updates, such as Boot Manager updates or dbx revocations, once the 2011 certificates expire.
For future, unreleased versions of Windows, Microsoft hasn’t published specific requirements. That said, devices that can’t update their Secure Boot trust should expect increasing security and compatibility limitations over time as newer operating systems, firmware, and Secure Boot‑dependent protections assume an updated trust foundation.
This work isn’t about forcing device turnover. It’s about making sure systems that are capable of doing so can continue to receive critical boot‑level security updates and stay protected as the threat landscape evolves.
Arden – Microsoft
I'd say it is likely that some of these unsupported upgrade scenarios will prevent you to install a future Windows update, but I believe it is unlikely that this will happen based on whether your Secure Boot certificates are current or not.
- Arden_White
Yeah, it looks like it was able to update the DB with the certificates. I also would expect that the 2023 signed boot manager will update if it hasn't already. The KEK is what you don't get in this case - probably due to the age. The device will continue to run and get updates. What you won't get is the updates to the Secure Boot DBX when there are security issues in things like boot loaders and other firmware modules.
Kudos to you for keeping it running that long and to Dell for manufacturing something that lasts. I sympathize with you. I'm still using my Lenovo Yoga Pro 2 that is about the same age as your Dell. I can sense that I'm getting close to getting a new laptop. 🙂And yes I believe it did update the signed boot manager. Does that do us any good without the KEK?
The signed boot manager does not require the KEK to be updated, as the 2023 DB updates are signed with the 2011 KEK.
Only the next boot manager certificates (in 2038) will require the 2023 KEK to be present (if the device still works by then).
We won't get updates to the Secure Boot DBX. Does that mean we will get updates to other Secure Boot components, or is it all or nothing?
You will get updates to the boot manager, even without KEK. You won't get the next certificates (in 2038 when the current ones expire) and you won't get any new DBX entries.
How does Microsoft see what is needed for PXE boot with WINPE/MDT/SCCM etc?
After the 2011 certs expire is it correct to assume that the installation of Windows 11 via pxe boot etc is still working? As long as the bios fw has the 2011 (and 2023) certs available?So nothing needs to be changed towards boot images signed binaries unless the device only has 2023 certs in fw?
Also that means that after fresh install of W11 you always need to update the 2023 certs in Windows boot manager to get the security updates?Is this the case till we get a W11 version which is signed with the 2023 certs and requires boot images to have the 2023 signed binaries? So in this case you need to update the pxe/winpe/boot images?
I asked them the same question. As far as I understand, the old boot images will continue working during PXE Boot, as long as the old certificates (the ones from 2011) are present in the UEFI store. If the old certificates are revoked, we need to create new boot images, possibly using new Windows ADK.
- Jason_Sandys
Correct. And as called out in a few of my other answers (which you may or may not have seen) we have no intent to revoke the old certs as that serves no purpose and would cause widespread issues.
A key point in all of this to keep in mind is that the certs expiring has no immediate impact whatsoever. Nothing signed by these certs becomes invalid or untrusted just because the certs expired. Unless or really until we release an updated boot critical component that requires signing--which must be done with the new certs--nothing changes. When this does finally happen (as I'm sure it will happen at some point (but can't say how soon that will be) that's the time when that new component won't be trusted by devices without the new certs and thus they won't be able to install that new component. Again, components signed by the old certs, whether they be in a full OS instance or a WinPE boot image, are and will still be fully trusted--nothing changes for them.
How is Windows 10 LTSC, Win10 IOT LTSC, and Windows 11 IOT LTSC affected by the certificates? Will the new 2023 certificates be install on these devices? Win10LTSC and Win10 IOT LTSC should still be getting windows updates without the extended licensing. Thank you.
