If you manage Windows endpoints, you have a hard deadline coming up that has nothing to do with a CVE. On June 26, 2026, the original Microsoft Secure Boot signing certificates from 2011 begin to expire. The Windows ecosystem has been quietly preparing for this for over a year, and Microsoft is now telling IT teams in plain language: act now.
Here is what is expiring, what breaks if you ignore it, and the operational steps you should be working through over the next seven weeks.
What is actually expiring
The 2011-issued Microsoft Secure Boot certificates underpin the chain of trust that decides whether your firmware will boot a Windows OS in the first place. There are three certificates of interest:
- Microsoft Corporation KEK CA 2011 — the Key Exchange Key authority that allows Microsoft to update the allow/deny lists in firmware.
- Microsoft Windows Production PCA 2011 — used to sign the Windows boot loader itself.
- Microsoft Corporation UEFI CA 2011 — used to sign third-party UEFI components and bootloaders, including Linux distros, recovery tooling and OEM diagnostics.
Microsoft is rolling out 2023 replacement certificates. Once a device has the new certs in its UEFI variables, it can keep receiving updated boot components and stay in compliance. If a device misses the transition, it can keep booting — but it will stop receiving signed updates to boot components, which means new boot-stage vulnerabilities will go unpatched on that device.
This is not “your machines brick on June 26.” It is “your machines quietly fall out of the trust chain and start accumulating unfixable boot-stage exposure.”
Why this matters more than it sounds
Boot-stage compromise is one of the few attack surfaces where local admin does not help you, because the attacker is operating below the OS. Bootkits and pre-boot rootkits live exactly in this layer. The reason Microsoft built this whole certificate hierarchy is to keep that surface defensible.
If your fleet drifts out of Secure Boot trust:
- New revocations (DBX updates) will not deploy correctly, so known-bad bootloaders stay accepted.
- New signed boot components from Microsoft will not validate, so you will start failing updates.
- Attestation, BitLocker recovery flows, and any policy that depends on a healthy boot chain will start breaking in ways that are slow and confusing to debug.
In other words: this is a control plane you cannot afford to let rot.
The 7-week action list
1. Inventory devices that need the transition
Microsoft surfaces Secure Boot certificate update status in the Windows Security app and via registry and event log signals. Your endpoint management platform (Intune, ConfigMgr, your RMM) should be able to query this for you. Build a dashboard that splits the fleet into:
- Devices already updated to 2023 certs.
- Devices receiving updates from Microsoft but not yet transitioned.
- Devices not receiving Windows Update at all. These are your problem children.
2. Make sure Windows Update is actually flowing
Microsoft’s stated path for “automatic” cert rollout is: let Windows Update manage it. That sounds simple. It is not, in environments that have aggressively deferred updates, blocked driver updates, or rely on offline imaging. Confirm:
- Your update rings include the relevant servicing months.
- Devices are actually checking in, not just told to.
- You are not blocking the optional updates that include the new certificate payloads.
3. Validate OEM firmware on critical hardware
Some OEMs (Dell, Lenovo, HP) have published their own guidance and, in some cases, firmware updates that streamline the certificate transition. Pull each OEM’s KB and check whether anything in your fleet needs a BIOS or UEFI update before it will accept the new certificates cleanly. Servers and engineering workstations are where this trips up most often.
4. Plan a path for offline and air-gapped systems
If you have offline build PCs, lab gear, OT systems, or staged images, those will not get the rollout from Windows Update. You will need:
- Updated baseline images that include the 2023 certificates.
- A documented manual procedure for applying the cert update via firmware tools or scripted DBX updates.
5. Decide what to do about devices that cannot be transitioned
Old hardware that has stopped receiving updates is going to be left behind. Make a list. Decide which devices are getting decommissioned, which are getting BitLocker re-keyed and isolated, and which are getting an exception ticket so they do not surface as “broken Secure Boot” alerts forever.
6. Update your recovery and break-glass procedures
If your incident response runbooks include booting from signed recovery media, vendor diagnostics tools, or third-party utilities, test that they still work after the transition. Some signed-by-2011-UEFI-CA tools will not validate against the 2023 chain. The Secure Boot playbook Microsoft published is a good source for the validation steps.
7. Communicate up
This is one of those changes where leadership should hear about it before something breaks, not after. A two-paragraph email to the IT and security stakeholders explaining the deadline, the risk of inaction, and the plan is worth ten incident calls in July.
What to do this week
- Confirm that “Secure Boot certificate update status” is being captured in your endpoint inventory.
- Identify the top 10 devices in your fleet that are not receiving Windows Update for any reason.
- Pull your OEMs’ Secure Boot transition KBs into a single planning doc.
This is the rare deadline you can hit without heroics if you start now. Wait until June and you will be triaging it during a heatwave with everyone on PTO.
