Secure Boot Certificate Expiration: What Changed in June, What Happens on October 19

Which Secure Boot certificates are expiring?

Three certificates issued by Microsoft in 2011 are reaching the end of their validity. The Microsoft Corporation KEK CA 2011 expired on June 24, 2026 and authorised updates to the Secure Boot databases. The Microsoft Corporation UEFI CA 2011 expired on June 27, 2026 and signed third-party boot loaders and option ROMs. The Microsoft Windows Production PCA 2011 expires on October 19, 2026 and signs Windows' own boot components.

Most of the coverage written about this was published before the June dates, which is why so much of it reads as a warning about something imminent. Two of the three have now passed without incident, and that is worth stating plainly, because the quiet is the part people misread. Nothing was supposed to happen in June. The certificates stopped being usable for signing new things; everything already signed carried on.

Will the machine still boot?

Yes. Devices that have not received the 2023 certificates continue to start and operate normally, and standard Windows updates continue to install. Secure Boot's job at power-on is to check that the code it is about to run was signed by something the firmware already trusts, and an expired certificate does not disappear from the firmware's allow list when its validity period ends.

Anyone who has watched a public root expire in an operating system trust store will recognise the shape of this. The certificate itself is a statement with a start and end date, but the decision a verifier makes depends on which question it was asked. A browser asked whether a TLS certificate is valid right now says no the moment it expires. Firmware asked whether a boot image matches a key in its allow list is doing something closer to a lookup, and the lookup keeps succeeding.

This is the same reason a timestamped Authenticode signature outlives the certificate that made it. Expiry governs what a key may still be used to sign, not whether everything it signed in the past is retroactively worthless.

What actually stops working

What a device loses is the boot layer's capacity to change. Without the 2023 certificates in firmware, it can no longer receive new security protections for the early boot process: updates to the Windows Boot Manager, changes to the Secure Boot databases, new revocation entries, or mitigations for boot-level vulnerabilities discovered from here on. The machine is not broken. It is frozen.

That distinction decides how urgent this is for a given fleet. A kiosk rebuilt from an image every quarter is in a different position from a laptop estate that has to accept a revocation the week a new bootkit is published. The historical case everyone reaches for is BlackLotus, where the response was a revocation pushed into the deny list — precisely the mechanism that an expired key exchange key can no longer authorise.

Why three certificates become four

The 2011 set has three certificates and the 2023 set has four, because the third-party certificate splits in two. Microsoft Corporation UEFI CA 2011 signed both non-Microsoft boot loaders and option ROMs under one certificate. Its replacement is a pair — Microsoft UEFI CA 2023 and Microsoft Option ROM UEFI CA 2023 — which separates those two kinds of trust so they can be granted independently.

The reason is a real one rather than administrative tidiness. A server whose RAID controller needs a signed option ROM previously had to trust third-party boot loaders to get it, because both came from the same CA. Splitting them lets a platform add the option ROM certificate on its own. It is the same instinct behind single-purpose roots in the public web PKI, where a hierarchy is increasingly expected to do one job rather than several.

For anyone writing an inventory check, the split is the detail that matters operationally. Microsoft's guidance notes that where the 2011 third-party certificate is active in a device's allow list, Windows appends both 2023 third-party certificates during cumulative updates. A script that looks for three replacements and reports success has not actually confirmed the fourth.

Why the KEK has to land first

The key exchange key is the credential that authorises changes to both Secure Boot databases, so it gates everything else in the rollout. A device that has not taken the Microsoft Corporation KEK 2K CA 2023 has no valid authority to accept the allow-list update carrying Microsoft Windows UEFI CA 2023. Order is not a preference here; it is a dependency.

This is why the June dates deserved more attention than they got, even though nothing visibly happened. The KEK expiry was the one that closed the door, and the October date is the one that makes the closed door matter. Reversed, the situation would be far more forgiving: an expired signing CA with a live KEK is a problem you can still push a fix through.

It is worth being precise about what the expiry does and does not do to the update path, because the two are easy to conflate. A device that received the 2023 KEK before its predecessor expired holds a valid authority and can keep taking database updates indefinitely. The constraint binds on devices that never received it — firmware that was off, unmanaged, or on a platform whose vendor has not shipped the update.

What the October 19 date really does

October 19, 2026 is the date the Windows Production PCA 2011 can no longer sign new Windows boot components. From that point, Microsoft signs them under Microsoft Windows UEFI CA 2023, and a device will only verify those newly signed components if that certificate is in its allow list. Existing boot components on the device are unaffected.

So the practical failure mode is not a machine that will not start. It is a machine that starts perfectly and then cannot accept a boot manager update, which is a much quieter problem and one that surfaces at an inconvenient moment — usually during a feature update or a recovery operation rather than on the day itself.

The same certificate turns up in Microsoft's broader code signing work, which is a separate thread worth not tangling with this one. The 2026 guidance describes Microsoft moving its own production signing to stronger configurations and looking ahead to post-quantum signing in 2027. None of that is a deadline for an Authenticode certificate a software vendor buys, and our OV and EV code signing certificates keep working under the same rules they do today. What the guidance does ask of vendors is narrower: stop hard-coding certificate names, thumbprints, issuers, key sizes and digest algorithms in your own signature-checking code, because that is the code that breaks when a CA changes underneath it.

How to check a device

Read the active Secure Boot variables from an elevated PowerShell session and look for the 2023 certificate names. Checking the allow list for the string returns True when the certificate is present. Run PowerShell as administrator — an unelevated session cannot read these variables and the resulting error is easy to mistake for a missing certificate.

# Is the 2023 KEK present? Check this one first.
[Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI KEK).bytes) -match 'KEK 2K CA 2023'

# Is the Windows boot component CA present?
[Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'

# And the two third-party certificates, if this device needs them.
[Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Microsoft UEFI CA 2023'
[Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Option ROM UEFI CA 2023'

Check the KEK before anything else. It is the dependency for every other line, so a False there explains a False everywhere else and points the remediation at the firmware rather than at Windows Update. The two third-party lines only apply to devices that actually need third-party boot loaders or signed option ROMs; a Windows-only machine with neither is not failing a check by missing them.

What to do now

Inventory first, remediate second. The population that matters is not the whole estate — it is the devices that have not taken the 2023 KEK, because those are the only ones where the rest of the update cannot proceed. Run the KEK check across the fleet, then sort what comes back by whether the device can take a firmware update at all.

The last row is the one most likely to be missed, because it lives in application code rather than in a device inventory. Installers that pin a Microsoft thumbprint before applying an update, licence checks asserting an issuer name, and self-update routines that accept only SHA-256 have all been quietly correct for a decade. Certificate rollovers are exactly when that kind of code stops being correct, and how trust stores decide what a device accepts is the background that makes the failure legible when it happens.

FAQ