The deadline nobody missed
Every expiry story we've written here has the same shape. A certificate lapses, nobody was watching, something breaks, and everyone is surprised. A Splunk license at a federal agency. Microsoft's own network connectivity tool. Same plot, different logo.
This one is the opposite, and that's what makes it worth reading.
On October 19, 2026, roughly ten weeks from this writing, the Microsoft Windows Production PCA 2011 certificate expires. It sits under the trust chain for the Windows boot process on essentially every PC shipped in the last fifteen years.
Nobody forgot it. The expiry date has been printed inside the certificate since 2011. Microsoft has been publishing guidance for over two years, shipping replacement certificates through Windows Update since 2024, running OEM briefings, and pushing an automatic rollout that requires most users to do nothing at all.
It is August. It still isn't done.
What's actually expiring
Three certificates, four replacements, three dates, all in 2026:
| Certificate | Expires | Replaced by |
|---|---|---|
| Microsoft Corporation KEK CA 2011 | June 24, 2026 | Microsoft Corporation KEK 2K CA 2023 |
| Microsoft Corporation UEFI CA 2011 | June 27, 2026 | Microsoft UEFI CA 2023 |
| Microsoft Corporation UEFI CA 2011 | June 27, 2026 | Microsoft Option ROM UEFI CA 2023 |
| Microsoft Windows Production PCA 2011 | October 19, 2026 | Windows UEFI CA 2023 |
Both June dates have already passed. October is the one that matters most, because that's the certificate used to sign the Windows Boot Manager itself.
Devices that don't pick up the 2023 certificates keep booting and keep taking normal Windows updates. What they lose is the ability to receive new protections for the early boot path: updates to Boot Manager, Secure Boot database changes, revocation lists, and mitigations for bootkit vulnerabilities discovered from here on.
In other words, the machine doesn't fail. It just quietly stops being patchable in the one layer that sits below your antivirus, your EDR agent, and your operating system.
Two years of notice wasn't enough
Here's the part worth sitting with. Microsoft did nearly everything right, and the rollout still stalled.
By July 10, 2026, Microsoft had confirmed in an updated support document that it was halting the rollout on certain device and firmware combinations: "Devices in this group are affected by a known issue. To reduce risk, Secure Boot certificate updates are temporarily paused while Microsoft and partners work toward a supported resolution."
Microsoft didn't name the affected hardware. Administrators and OEMs filled that in themselves, reporting failures across HP, Dell, ASUS, MSI, and ASRock systems. Some ASUS machines needed Secure Boot temporarily disabled before revocation updates would install. Some MSI devices ignored the certificate update while still reporting Secure Boot as enabled. HP had begun shipping updated BIOS builds in June specifically to prepare for the deadline, and on some models the machines landed at a BitLocker recovery screen with the 2023 certificates failing to apply.
Microsoft's guidance is that some devices need a firmware update from the manufacturer before the Secure Boot update can be installed at all. Which means the fix isn't in Microsoft's hands, or in yours. It's in a vendor's BIOS release schedule.
On July 15 Microsoft ran a twelve-hour OEM office hours session alongside Acer, Asus, Cisco, Dell, Fujitsu, HP, Lenovo, LG, Surface, and Xiaomi. Administrators turned up with BitLocker recovery loops, devices stuck at the wrong readiness rating after a BIOS update, Intune policies failing with unclear error codes, and confusion over which registry key they were supposed to set.
Two weeks after that, the message was still don't panic: unpatched devices will continue to start normally, and Microsoft will "continue to install the newer certificates via Windows updates in the coming months."
Coming months. For a certificate that expires in October.
None of this is incompetence. It's a rollover that touches firmware from dozens of vendors, across fifteen years of hardware, with BitLocker and TPM state in the middle of it. The date was never the hard part. The dependency graph hanging off the date was.
Nothing explodes on October 20
Worth being clear about this, because there's a lot of breathless coverage: your machines will not stop booting on October 20.
UEFI firmware, in practice, doesn't enforce certificate expiry the way a browser does. The reference implementation skips that validation, which is why plenty of systems already run happily on certificates that lapsed some time ago. Binaries signed before the expiry keep verifying afterward. As Matthew Garrett has argued, this is a managed certificate rotation, not a Y2K event.
That sounds reassuring. It isn't, quite.
An expired TLS certificate is loud. The browser throws a full-page block, the phone rings, and someone fixes it within the hour. This expiry is silent by design. There's no error, no red banner, no ticket. The gap opens between the machines that took the 2023 certificates and the ones that didn't, and nothing in your environment tells you which is which unless you go looking.
The failure mode isn't an outage in October. It's discovering next spring that a slice of your fleet has been unable to accept boot-layer security updates since the autumn.
The asset nobody has an inventory of
If something does bite, this is where.
Your recovery media has an expiry date now, and it isn't in anyone's CMDB. WinPE drives. PXE boot images. The Windows Server installation USB in the drawer. Bare-metal restore media from your backup vendor. Every one of those carries a boot loader signed by a specific certificate chain, and every one was built at some point in the past and then never thought about again.
Once machines are remediated onto the 2023 chain, older media can fail to boot on them. Which you will find out at the exact moment you need it: after a crash, with a server down, holding a USB stick that no longer works on the box you're trying to rescue.
Microsoft ships a Make2023BootableMedia.ps1 script to re-sign media with the updated Boot Manager, and Lenovo, Veeam, and others have published their own procedures for refreshing WinPE boot files. The tooling exists. The problem is that rebuilding recovery media is a manual step that no automatic Windows Update rollout will ever do for you, and it lives on an asset most teams have never tracked as having a lifespan at all.
Certificates you can scan for. A USB stick in a drawer, you cannot.
October is a loaded month
One more thing about the timing. October 19 isn't the only certificate deadline landing this fall.
As of March 15, 2026, the maximum lifetime of a public TLS certificate dropped from 398 days to 200. Any certificate issued right at that changeover comes due about 200 days later, which puts the first big wave of shortened-lifetime renewals in early October 2026. (We wrote about that shift here.)
So the same few weeks bring the last of the 2011 Secure Boot certificates and the first real test of the industry's new renewal cadence. If your team has a quiet quarter planned, this isn't it.
What to do before October 19
Nothing here is clever. It's just the work.
- Find out where you actually stand. Check Secure Boot certificate status across the fleet rather than assuming the automatic rollout covered it. Microsoft's phased deployment covers most supported hardware, but "most" is doing real work in that sentence.
- Chase the firmware, not the certificate. For devices that fail, the blocker is usually a pending BIOS update from the OEM. Check your manufacturer's Secure Boot support page and get those into your patch cycle.
- Rebuild and test your recovery media. All of it. Then actually boot from it on a remediated machine. Media you haven't tested is a hope, not a recovery plan.
- Put a date on the work, not just on the certificate. October 19 is when the certificate expires. The date that matters to you is the one where the rebuild and validation are finished, and that should sit weeks earlier with a name attached to it.
The lesson from this one isn't "watch your expiry dates." Microsoft watched this expiry date for fifteen years.
It's that a known deadline and a finished migration are different things, and only one of them shows up on a calendar. Lead time gets spent whether or not you use it. What closes the gap is an owner, a date earlier than the real one, and a reminder that arrives while there's still room to move.
ExpiryPulse tracks credential and certificate expiry for individuals and IT teams: one dashboard, automated alerts at 30, 14, 7, and 1 day before expiration, and primary/backup owners so nothing falls through a gap. Free tier at expirypulse.dev.
Related: It Happened Again. This Time It Was Microsoft's Own Diagnostic Tool., on the expiry nobody was watching. And 47-Day SSL Certificates Are Coming. Is Your Team Ready?, on the renewal cadence arriving alongside this one.
Top comments (0)