Microsoft has quietly begun a major security certificate refresh that will affect every Windows PC relying on Secure Boot. Two critical platform certificates issued in 2011—the Microsoft Corporation KEK CA 2011 and Microsoft UEFI CA 2011—are set to expire on June 24, 2026. A third, the Windows Production PCA 2011, follows on October 19, 2026. Waiting until the last minute could leave some machines unable to boot properly, especially in enterprise environments where firmware updates aren’t applied automatically.

If your PC is less than a decade old and receives regular Windows updates, you’re likely in the clear—but not automatically. The nuance is what makes this different from a routine Patch Tuesday: a fully patched Windows 11 machine can still carry the old certificates deep in its firmware, and the checkbox that says “Secure Boot enabled” doesn’t tell the whole story. Microsoft’s guidance, updated this month, makes clear that organizations must audit devices now, not in June 2026.

A Looming Expiration

The certificates in question aren’t files sitting in a Windows folder. They’re part of the UEFI firmware’s trust chain—the digital signatures that verify every piece of code that runs before the operating system loads. When a PC boots with Secure Boot on, the firmware checks the signatures of drivers, option ROMs, and the Windows boot manager against these certificates. If a required certificate has expired and no valid replacement is present, the firmware will refuse to execute the code, and the machine won’t start.

Microsoft’s Secure Boot documentation now includes an explicit warning: “Microsoft is updating the Secure Boot certificates originally issued in 2011 to ensure Windows devices continue to verify trusted boot software. These older certificates begin expiring in June 2026. To avoid disruption, review the guidance and take action to update certificates in advance.”

There are three expiring certificates:

  • Microsoft Corporation KEK CA 2011 (expires June 24, 2026)
  • Microsoft UEFI CA 2011 (expires June 24, 2026)
  • Windows Production PCA 2011 (expires October 19, 2026)

The Key Exchange Key (KEK) and UEFI CA certificates are used to sign and authenticate updates to the firmware’s signature database. The Windows Production PCA is what validates the Windows boot manager itself. All three were created in 2011 as part of the original Secure Boot rollout alongside Windows 8. They were designed to be replaced before expiration, but for many devices, that replacement hasn’t happened yet.

Who Needs to Act—and Who Doesn’t

Home Users

Most consumer PCs sold in the last five years have already received the updated certificates through a combination of Windows Update and firmware updates pushed by the manufacturer. If you run a supported version of Windows 10 or 11 and allow your PC to install optional driver and firmware updates, you’re probably safe.

But there’s a gap: older devices or those where the OEM has stopped issuing firmware updates. A 2015 Dell or Lenovo that’s otherwise working perfectly might never get the required firmware patch. In that case, the machine will still boot as long as you don’t reinstall Windows or reset the firmware, because the operating system can install the new certificates into the firmware’s signature database from within Windows. However, if you ever need to perform a clean OS installation or the firmware is reset, the missing certificate could block boot.

The safest approach for home users: ensure Windows Update runs regularly (Settings > Windows Update > Check for updates), and visit your PC manufacturer’s support site to see if any recent BIOS or UEFI firmware updates are available. Don’t skip those “Lenovo System Update” or “Dell Command Update” prompts.

IT Administrators

The burden falls hardest on corporate IT. A fleet of hundreds or thousands of desktops and laptops will contain a mix of hardware ages and firmware revisions. Some will update cleanly through Windows servicing; others will need manufacturer firmware updates first. A subset—particularly older models no longer supported by the OEM—may have no update path at all.

The temptation is to run a PowerShell command like Confirm-SecureBootUEFI and call it a day. That’s a trap. The cmdlet only reports whether Secure Boot is currently enabled. It does not check which certificates are present or whether the 2011 certificates have been replaced. A machine with Secure Boot on can still fail to boot after the certificates expire if the updates haven’t been applied.

WindowsForum, in its detailed analysis of the rollover, proposes an endpoint-governance model that sorts devices into four dispositions: retain and update, remediate firmware, replace, or temporarily isolate. None of these are official Microsoft mandates, but they provide a practical framework for planning. The essential point is that “Secure Boot enabled” is not a completion metric. Admins must verify that the new certificates are in place, typically by comparing the firmware’s KEK and db databases against known good values published by Microsoft.

Microsoft’s documentation doesn’t yet provide a simple one-command check for completion, but it does instruct OEMs to provision the new certificates during manufacturing. For existing devices, Windows Update can inject them, but only after the firmware is in a compatible state. This two-step dance—firmware update first, then Windows servicing—will occupy many IT shops through the first half of 2026.

Developers and Enthusiasts

Anyone running a custom boot configuration—dual-booting Linux with Secure Boot, using a custom EFI application, or maintaining their own Secure Boot keys—needs to test early. Microsoft’s guidance explicitly mentions that “systems with alternative bootloaders, customized Secure Boot keys, or hardware that participates before Windows starts require their own approved test plans.” If you have enrolled your own KEK or modified the signature database, the automatic update process may not work, and you’ll need to manually import the new certificates before the old ones expire.

Why These Certificates Exist (and Why They’re Expiring Now)

Secure Boot arrived in 2011 alongside Windows 8, primarily as a defense against bootkits—malware that infects the boot process before the operating system loads. The idea was to ensure that only code signed by trusted parties could run during startup. To make that work, Microsoft and PC OEMs embedded a set of certificates into the firmware of every new PC.

The 2011 certificates were never meant to last forever. They were issued with a 15-year validity period, which was considered generous at the time. Now that deadline is approaching. Microsoft isn’t caught off guard: it has been working with OEMs for years to provision the replacement certificates in new devices. The Windows 11 hardware certification requires the updated certificates, so any device sold with Windows 11 preinstalled since 2021 should already have them.

The in-between devices—those shipped with Windows 8, 8.1, or 10 between 2012 and 2020—are where the risk concentrates. Many of these are still in active service, especially in enterprise, education, and industrial settings. They may not have received the firmware update that brings in the new certificates, or the OEM may have stopped supporting the model before Microsoft finalized the update mechanism.

What You Must Do Before June 24, 2026

For Home Users: A Three-Step Check

  1. Run Windows Update fully. Go to Settings > Windows Update, click Check for updates, and install everything offered—including optional updates. Restart when prompted. Repeat until no updates remain.
  2. Check for firmware updates. Use the manufacturer’s update tool or visit the support website for your exact model. Even if you don’t see a specific “Secure Boot certificate update,” any BIOS or UEFI firmware update from 2023 onward is likely to include the new certificates.
  3. Don’t disable Secure Boot. If you encounter a boot problem after an update, don’t reach for the firmware menu to turn off Secure Boot as a quick fix. That removes a critical security layer. Instead, research the error or consult the manufacturer’s support.

For IT Departments: Audit First, Then Roll Out

Do not push firmware updates fleet-wide without testing. Start with a representative sample that includes each major model and firmware revision.

  • Inventory your fleet with at minimum: manufacturer, model, firmware version, Windows edition and version, Secure Boot status (Confirm-SecureBootUEFI result), and the output of Get-SecureBootUEFI -Name KEK -Decoded and Get-SecureBootUEFI -Name db -Decoded for diagnostic collection.
  • Classify each device using a model such as the one proposed by WindowsForum:
    • Retain and update: Windows servicing installs the new certificates without issue.
    • Remediate firmware: A manufacturer firmware update is required before Windows servicing can complete the update.
    • Replace: No update path exists; the device must be retired.
    • Isolate: Temporary exception for a critical, unserviceable machine, with strict network restrictions and a fixed retirement date.
  • Test with pilot rings organized by hardware, not department. Apply all available Windows and firmware updates to a pilot device, verify successful reboots and cold starts, and confirm that the new certificates appear in the KEK and db databases.
  • Monitor for compatibility holds from Microsoft or the OEM. If a hold appears for your model, pause deployment and wait for updated guidance.

A crucial note: Microsoft’s current documentation does not supply a public list of the exact certificate thumbprints that should be present after the update. The decoded output from PowerShell is therefore a diagnostic aid, not a compliance pass/fail. Only Microsoft’s management platforms and the OEM’ s support channels can confirm completion. When in doubt, assume a device is not ready until Windows Update and the manufacturer’ s update tool both report no pending updates and the device has survived multiple reboot cycles.

Beyond June: The October 2026 and Long-Term Outlook

June 24, 2026 is the first critical date, but not the last. The Windows Production PCA 2011 expires on October 19, 2026. While the June certificates affect the firmware’ s ability to accept updates, the October certificate directly impacts the boot loader. A machine that successfully navigates the June deadline could still fail in October if the Windows production certificate hasn’t been replaced.

Administrators should therefore treat 2026 as a year-long rollout, not a one-day cutover. After the June updates are deployed, continue monitoring Windows Update and OEM channels for further required patches. Microsoft may release additional automatic updates that inject the production certificate, but these will only work if the KEK and UEFI CA updates are already in place.

For home users, the same advice holds: keep everything updated, and don’t ignore firmware notifications. The difference between a smooth transition and a bricked PC may be a single firmware update you postponed.

The silver lining is that this is essentially a housekeeping exercise, not a response to a vulnerability. The certificates were always meant to be replaced before expiration, and the industry has had a decade of lead time. The urgency today is because that lead time is finally almost up. Start now, and June 2026 will pass without incident.