On June 24, 2026 the first of four Microsoft Secure Boot certificates expires, kicking off what Microsoft calls the Secure Boot certificate expiration window. If you’ve been ignoring the Windows 10 end‑of‑support hype, you can’t pretend this one’s any less urgent. The certificates that have been silently protecting your boot chain since 2011 are about to run out, and Microsoft’s guidance says you should verify your machine today.
Key Takeaways
- Secure Boot blocks untrusted code at startup on most Windows 10 and 11 PCs.
- Microsoft‑issued KEK and UEFI CA certificates from 2011 expire in June and October 2026.
- Latest updates, released in 2023, already contain replacement certificates.
- If you’re still on an older firmware, you’ll need to run the Windows Security utility to confirm your status.
- Turning off Secure Boot could lock you out of BitLocker‑encrypted drives without a recovery key.
Secure Boot Certificate Expiration Impacts Windows PCs
Secure Boot isn’t a new buzzword; it’s the default firmware setting on virtually every PC sold with Windows 10 or 11 since 2011. The feature works by checking a chain of cryptographic certificates before the OS even loads. When the chain breaks – which is what’s happening today – the system can still boot, but it won’t accept future updates to the boot manager or revocation lists. That means you won’t get patches for newly discovered vulnerabilities that sit in the boot path.
Because the boot process is the first line of defense, any gap in the certificate chain can be used by sophisticated attackers. They could insert a malicious loader that masquerades as a legitimate component, and the firmware would have no way to flag it. In practice, most users will never see the exploit, but the risk remains higher for machines that stay on legacy firmware.
How the Expiring KEK and UEFI CA Certificates Work
The most critical piece in the chain is the Key Enrollment Key, or KEK. It lives in the UEFI firmware and talks to the TPM to manage the Allowed Signature Database (DB) and the Forbidden Signature Database (DBX). Alongside the KEK, Microsoft‑issued Production Certificate Authority (CA) and UEFI CA certificates validate the signatures of boot components. Those three certificates – KEK, Production CA, and UEFI CA – were all signed in 2011, and they’re the ones that expire this month.
Because the certificates are baked into the firmware, you can’t simply replace them with a Windows update. The root of trust – the Platform Key – is owned by the hardware OEM, which is why Microsoft has been coordinating with OEMs for years to push out the new certificates.
The DB holds hashes of binaries that are explicitly allowed to run, while the DBX contains hashes of binaries that have been revoked. When the KEK expires, the firmware can no longer verify new entries to either database, effectively freezing the trust model. Existing entries remain, but any future revocation—especially for newly discovered malware—won’t be reflected.
What Microsoft Is Doing to Replace the Old Certificates
Back in 2023, Microsoft rolled out replacement certificates that are already signed by a newer CA. The company has been publishing guidance since early 2025, and a blog post earlier this year outlined the progress. OEMs have been provisioning the updated certificates to devices that ship with Windows 11, and many Windows 10 machines received the firmware update via Windows Update.
Microsoft points out that the new certificates are designed to let third‑party option ROMs be trusted without also trusting third‑party boot loaders. That change was reflected in a table that showed Microsoft UEFI CA 2011 being replaced with two signatures, a subtle but important tweak for enterprises that run custom boot loaders.
The rollout strategy relies on a two‑phase approach. First, OEMs embed the new certificates in fresh hardware. Second, they push firmware updates to existing devices. This dual path ensures that both new shipments and legacy fleets eventually converge on the same trust anchor. The coordination required between Microsoft, OEMs, and firmware vendors has been ongoing, and the 2023 update represents the most mature point of that effort.
Checking Your PC’s Certificate Status
Microsoft added a built‑in way to inspect the certificate status through the Windows Security app. Open the app, navigate to “Device security,” then look for the “Secure Boot” section. If the status reads “Enabled” and the certificate version shows a 2023 date, you’re good. If it still shows a 2011 timestamp, you should run Windows Update immediately and make sure your firmware is up to date.
Here’s a quick step‑by‑step:
- Press Win + I to open Settings.
- Go to “Update & Security” → “Windows Security.”
- Select “Device security,” then “Secure Boot.”
- Check the “Certificate version” line – it should read “2023‑xx‑xx.”
- If it doesn’t, click “Check for updates” and reboot.
Microsoft also recommends backing up your BitLocker recovery key before you reboot, just in case the firmware update triggers a TPM reset.
If the version still reads 2011 after a reboot, consider a manual firmware flash. Most OEMs provide a utility that can be launched from Windows, but the process typically requires a USB stick and a BIOS‑level recovery mode. The utility will rewrite the KEK, Production CA, and UEFI CA entries with the newer values, after which the Secure Boot status will report the 2023 version.
Potential Risks If You Miss the Update
Missing the certificate refresh won’t brick your machine, but it does close a few doors:
- You won’t receive future updates to the Windows Boot Manager, which could leave you exposed to boot‑level exploits.
- Secure Boot databases (DB and DBX) won’t get new revocation entries, meaning known malicious bootloaders could remain trusted.
- BitLocker hardening that depends on Secure Boot may stop working, forcing you to supply a recovery key on every boot.
- Third‑party bootloaders that rely on the KEK chain might be blocked, breaking custom Linux dual‑boot setups.
In practice, most users will just see a warning and be prompted to update. But for developers who ship hardware‑level software, those warnings could translate into support tickets and lost productivity.
What This Means For You
For developers, the takeaway is simple: make sure your CI pipelines include a step that validates the Secure Boot certificate version on any Windows‑based build agents. If you’re distributing firmware updates, coordinate with OEMs early to avoid a last‑minute scramble.
For IT pros and founders, treat today’s expiry as a reminder to audit your BitLocker recovery keys and to schedule regular firmware checks. The effort you put in now will keep your devices compliant and your data safe when the October deadline rolls around for the remaining certificates.
Scenarios for Different Roles
Below are three concrete situations where the certificate expiration can surface in day‑to‑day work.
1. Build‑agent validation. A DevOps team uses Windows Server VMs to compile a Windows driver that must be signed for Secure Boot compliance. The CI script pulls the Secure Boot status via PowerShell, extracts the certificate version, and fails the build if the version is older than 2023. This guardrail prevents a driver from being shipped to customers whose machines would reject it at boot.
2. Dual‑boot maintenance. An IT administrator supports a fleet that runs both Windows 11 and a Linux distribution. The Linux installer adds its own bootloader to the DBX. After the June expiry, the Linux bootloader is still accepted because the DBX entry remains, but future updates to the Linux shim cannot be added. The admin must apply the firmware update before attempting to upgrade the Linux side, or risk a broken dual‑boot configuration.
3. OEM firmware rollout. A hardware startup prepares a new device that ships with Windows 10. The engineering team embeds the 2023 certificates in the reference design, but the production line still flashes the older 2011 set for legacy compatibility. When the product reaches customers, the Secure Boot check flags a mismatch, prompting a service call. Early coordination with the OEM’s firmware team would have eliminated the mismatch and reduced post‑sale support costs.
Key Questions Remaining
Even with the 2023 certificates in place, a few uncertainties linger:
- Will the remaining certificates that expire in October be refreshed with the same cadence, or will Microsoft introduce a new schedule?
- How will enterprises that rely on custom Secure Boot policies adapt if third‑party option ROMs require additional signatures?
- What mechanisms will be in place for devices that cannot receive a firmware update because they are no longer supported by the OEM?
Answering these questions will shape the next wave of Secure Boot guidance and influence how organizations plan their long‑term hardware refresh cycles.
Will the next wave of Secure Boot updates arrive with the same level of transparency, or will we see another surprise deadline that catches the industry off guard?
Sources: ZDNet, Microsoft Support
