If you manage Windows devices in any kind of enterprise environment, the Secure Boot certificate expiry is a deadline you really do not want to sleep on. The Microsoft certificates that have been the foundation of UEFI Secure Boot since Windows 8 are reaching the end of their lifetime in 2026, and the clock is ticking. The first wave of expirations begins in June 2026, and if your fleet is not ready by then, devices will start losing the ability to receive boot-level security updates and to trust software signed with new certificates.

The reason this matters is not just calendar housekeeping. The whole reason we are rotating these certificates in the first place is the BlackLotus UEFI bootkit (CVE-2023-24932), a piece of malware that can survive an OS reinstall and even bypass Secure Boot itself. The 2023 certificate set is the long term answer, and you need every Windows device in your environment trusting it before the old certificates roll off.

In this post I want to walk through what BlackLotus actually is, what is happening with the Secure Boot certificates, how the two are connected (but not the same thing), and what you can practically do about it today using Intune, PowerShell, and the great work that several Microsoft MVPs have already shared with the community.

A Quick Refresher on BlackLotus

BlackLotus is a UEFI bootkit that exploits CVE-2023-24932, a vulnerability in the Windows boot manager. What makes it particularly nasty is that it loads before Windows does, which means it sits underneath every traditional security control you have in the operating system. Antivirus, EDR, even a clean reinstall of Windows will not necessarily get rid of it, because the malicious code lives in the boot path that Secure Boot is supposed to protect.

Microsoft addressed CVE-2023-24932 with a multi-phase rollout that started back in 2023 and is still in progress today. The fix is not just a patch you install. It involves updating the bootloader, revoking the trust of the vulnerable boot manager, and ultimately replacing the certificates that Secure Boot uses to decide what is allowed to run. That last part is the piece we are dealing with right now.

The Secure Boot Certificate Expiry: What Is Actually Going Away in 2026

There are three Microsoft certificates from 2011 that are baked into firmware on basically every Windows device shipped in the last decade. Here is the short version of what is going away and when:

• Microsoft Corporation KEK CA 2011 – the Key Enrollment Key authority. Expires June 2026.
• Microsoft Corporation UEFI CA 2011 – signs third party UEFI components and option ROMs. Expires June 2026.
• Microsoft Windows Production PCA 2011 – signs the Windows boot manager itself. Expires October 2026.

The replacements are the 2023 certificate set: Microsoft Corporation KEK CA 2023, Microsoft UEFI CA 2023, and Windows UEFI CA 2023. These are the certificates Microsoft is using going forward to sign boot components, and they are also the ones that carry the BlackLotus mitigations.

How BlackLotus and the Certificate Expiry Are Connected, but Not the Same Thing

This is the part I see people mixing up the most, so it is worth being precise. BlackLotus and the certificate expiry are two different problems that share a single solution.

• BlackLotus (CVE-2023-24932) is a security vulnerability. It exists because the old boot manager can be tricked into running malicious code. The fix is to revoke trust in the vulnerable boot manager and replace it with a new one signed by a new certificate.
• The 2026 certificate expiry is a lifecycle event. The 2011 certificates were always going to expire eventually. June 2026 is simply when their validity runs out.

Where they meet is the 2023 certificate set. Microsoft is using this rotation as the opportunity to also roll out the BlackLotus mitigations at the same time. So when you update a device to trust the 2023 certificates, you are doing two things in one go: you are getting it ready for life after the 2011 certificates expire, and you are closing the BlackLotus attack path.

If you do nothing, the consequences are not the same on both sides either. A device that never gets the 2023 certificates will still boot after June 2026. It just will not be able to install future Secure Boot updates, will not trust new third party UEFI components, and will remain exposed to BlackLotus style attacks. That is not a place you want to be.

How to Fix It

The good news is that the actual remediation is mostly registry plumbing. Microsoft ships the certificate update logic inside the cumulative update, and you opt a device in to receiving the new certificates by setting a value under HKLM\SYSTEM\CurrentControlSet\Control\Secureboot. Specifically, the AvailableUpdates DWORD controls which steps are applied. The current recommended value is 0x5944, which performs the full sequence: it adds the 2023 KEK to KEK, adds the 2023 DB entries, updates the boot manager, and updates DBX. After the registry value is set, the Microsoft\Windows\PI\Secure-Boot-Update scheduled task is what actually does the work, usually across one or more reboots.

At a high level the process for any device looks like this:

1. Make sure the device is fully patched. Anything earlier than the July 2024 cumulative update is not going to do you any favors.
2. Confirm that diagnostic data is set to at least Required, because the certificate update flow uses it.
3. Set AvailableUpdates to 0x5944 under the Secureboot key.
4. Trigger the Secure-Boot-Update scheduled task (or wait for it to run on schedule).
5. Reboot. Sometimes more than once. Verify by checking the UEFICA2023Status registry value, which should eventually read Updated.
6. Validate by querying the actual Secure Boot databases with PowerShell to confirm the 2023 certificates are present.

The cleanest way to do this at scale is with Intune Remediations. You build a detection script that reports back whether a device already has the 2023 certificates installed, and a remediation script that sets the registry values and kicks off the scheduled task. That gives you a single dashboard view of your whole fleet and lets you target the long tail of devices that need a nudge.

Things That Will Trip You Up

• OEM firmware. Some older devices will need a UEFI/BIOS update from the manufacturer before they can accept the 2023 certificates. If you have a fleet that is more than four or five years old, plan on doing a firmware audit as part of this project.
• Diagnostic data. If telemetry is set to Off (Security on Enterprise), the certificate update flow will not run. You need at least Required.
• Dual boot and custom signed bootloaders. If you are running anything that depends on the 2011 UEFI CA (some Linux distributions, some hardware vendors’ utilities), test before you push the update broadly.
• Virtual machines. Hyper-V Generation 2 VMs and Azure VMs are also affected. Do not forget the server side of the house.
• Monitor first, remediate second. Microsoft’s recommended approach is to start with a monitor-only Intune Remediation that just reports status, so you understand the scope of the problem before you start changing anything.

Reference Articles From the Community

I am far from the first person to write about this, and several Microsoft MVPs have already done excellent deep dives that are well worth your time. If you are about to start this project, read these first:

• Torbjörn “Mr T-Bone” Granheden (MVP, Enterprise Mobility) – Update Secure Boot Certificate by using Intune Remediation, Take 2. T-Bone has been iterating on his detection and remediation scripts as Microsoft has refined the recommended registry values, and his “Take 2” post is the most current version of his approach. This is the article I would point any Intune admin to first.
• Richard M. Hicks (MVP) – Windows Secure Boot UEFI Certificates Expiring June 2026. Richard provides a clean walkthrough of the problem and includes a handy Get-UEFICertificate PowerShell function for inspecting the current state of Secure Boot on a device.
• Microsoft Windows IT Pro Blog – Act now: Secure Boot certificates expire in June 2026. The official call to action from Microsoft, with the timeline and the high level guidance.
• Microsoft – Secure Boot playbook for certificates expiring in 2026. The detailed playbook, including the registry values, the scheduled task, and the recommended sequence of operations.
• Microsoft Support – Secure Boot certificate updates: Guidance for IT professionals and organizations. The canonical reference for what each registry value does and what state to expect at each step.
• 4sysops – Monitoring Secure Boot certificate installation status with Intune and PowerShell. A practical write up of the monitor-first approach using Intune Remediations.

GitHub Scripts You Can Use Today

If you would rather start from working code than write your own from scratch, several community members have published their detection and remediation scripts on GitHub. Always read through any script before deploying it in your environment, but these are good starting points:

• ThomasMarcussen/SecureBoot_2026_UpdateScripts_v1.0 – my own toolkit. Four scripts: a readiness detection script, a remediation script that applies the registry and telemetry settings, a CSV reporting script, and an OEM firmware readiness check. Designed to be deployed via Intune Remediations or Configuration Manager.
• markorr321/Secure-Boot – Detection, remediation, and throttle bypass scripts for Intune, with a focus on enterprise wide compliance and the BlackLotus mitigation.
• calibur/SecureBoot-ManagedOptIn-Intune-Remediation – A minimal Intune remediation that opts a device in to fully managed Microsoft handling of the DB and KEK updates.
• SimoneTermine/MicrosoftIntune – SecureBoot_UpdateCerts – Detection and remediation scripts using the AvailableUpdates=0x5944 registry trigger.

Conclusion

The 2026 Secure Boot certificate rotation is one of those rare projects that touches every Windows device in your environment, including the ones nobody has thought about in years. It is also one of those projects that is going to be infinitely easier if you start now than if you wait until May 2026 and try to do it under pressure. The combination of Intune Remediations, the registry-based opt-in flow, and the great scripts already shared by the community means there is no real reason to put it off.

Start with monitoring so you know what you are dealing with, fix any firmware and telemetry prerequisites, and then roll out the remediation in waves. Closing the door on BlackLotus is a nice bonus on top of staying ahead of the certificate expiry, and your future self (and your security team) will thank you.