Secure Boot Certificates Have Expired: What SMBs Still Need to Fix

"The Secure Boot deadline came and went and our computers still turn on, so are we done?" That is the question we are hearing from business owners this fall, and it is a fair one. Microsoft's original 2011 Secure Boot certificates expired between June and October 2026, and nothing dramatic happened on most desks. That quiet is exactly why the unfinished work is easy to miss.

Here is our view: the Secure Boot certificate expiration was never a single deadline you either hit or missed. It was the start of a split between devices that keep receiving boot-level security fixes and devices that silently stopped. Every machine in your fleet is now on one side of that line, and the ones on the wrong side look perfectly healthy until a boot-level vulnerability or a Windows reinstall exposes them.

Did the Secure Boot certificates expire, and what does that mean now?

Yes. The Secure Boot certificates Microsoft issued in 2011 have expired. Devices without the replacement 2023 certificates still start and run Windows normally, but they can no longer receive new protections for the boot process, including Boot Manager fixes, Secure Boot revocation updates, and mitigations for newly discovered boot-level vulnerabilities.

According to Microsoft's Secure Boot certificate expiration and CA updates guidance (KB5062710), the Microsoft Corporation KEK CA 2011 expired on June 24, 2026, the Microsoft UEFI CA 2011 used for third-party bootloaders and option ROMs expired on June 27, 2026, and the Microsoft Windows Production PCA 2011 that signs the Windows boot loader expired on October 19, 2026. Each has a 2023 replacement that needs to be present in your devices' firmware databases.

Microsoft's explainer on what happens when Secure Boot certificates expire spells out the consequence plainly: an un-updated device "becomes progressively less protected" as new threats emerge, and fixes such as BitLocker bypass mitigations or Secure Boot revocations will not be available to it. The page also warns that Secure Boot should not be disabled as a workaround.

What changed when the last 2011 certificate expired in October?

The October 19 expiration was the one with operational teeth. Microsoft's KB5132953, published October 22, 2026, confirms that existing devices continue to start, but it also sets out several changes that will play out over the coming months.

The final Windows Boot Manager releases signed with the 2011 certificate are now frozen and will not receive future security patches; every future bootloader fix is signed only with the Windows UEFI CA 2023 chain. Installation media is moving to boot by default with the 2023-signed bootloader, so hardware whose firmware lacks the 2023 certificate will need Microsoft's planned media reversion script to boot it. And future major client and server releases of Windows will ship installation media carrying only 2023-signed boot binaries.

Put simply, a device that never receives the 2023 certificate keeps booting on a bootloader that will never be patched again, and it is on a path toward being unable to boot the installation media for the next major version of Windows.

Why does a boot-level gap matter to a small business?

Boot-level attacks are not theoretical. In April 2023, Microsoft published guidance for investigating BlackLotus, a UEFI bootkit that exploited CVE-2022-21894 to bypass Secure Boot. Once installed, it could turn off BitLocker, disable hypervisor-protected code integrity, and switch off Microsoft Defender Antivirus. The ongoing fix for that class of attack depends on revocations and bootloader updates delivered through exactly the Secure Boot trust chain that has just rotated.

BlackLotus also showed why boot-level fixes are delicate: revoking a trusted boot component can leave a device unable to start if its firmware and bootloader are out of step, which is why these updates are staged and why a device stuck on old certificates falls further behind with each round. The lesson from BlackLotus is that malware running before Windows loads can defeat the very tools a business relies on to detect it. Disk encryption, endpoint protection, and compliance reporting all assume the boot process was trustworthy. A laptop that can no longer receive boot-level fixes undermines every control stacked on top of it, and that is a hard thing to explain to an auditor or an insurer after the fact.

What is still unresolved for most SMBs?

Most SMBs still have four open items: devices that never received the 2023 certificates, firmware that cannot accept them, security tools that trust only the old certificate, and installation or recovery media built before the change. None of these shows up as an outage on an ordinary workday, which is why they linger.

The pattern is familiar from other quiet deadlines. Microsoft's automatic rollout handled the easy majority of devices, which created a reasonable impression that the job was done. The remainder tends to be the odd hardware: the reception PC bought from a different vendor, the engineering workstation with a custom image, the server that has not been rebooted into its firmware menu in years. Those are precisely the machines nobody looks at until something breaks.

Devices that never received the 2023 certificates

Microsoft's own Secure Boot update FAQ is direct about responsibility: automatic updates are "an assist, not a guarantee," and "the customer is ultimately responsible for updating the Secure Boot certificates." Updates can stall when diagnostic data is blocked by a firewall, when firmware has problems, or when a device runs a Windows version outside support. That last point matters for any Windows 10 machine not enrolled in Extended Security Updates; our guide to what business leaders must do about Windows 10 end of life covers those options.

Firmware that cannot accept the new certificates

Some devices need an OEM firmware update to apply the certificates correctly, and Microsoft notes that such updates may only exist for devices still within their manufacturer's support period. Older hardware with no firmware path is a replacement decision, not a configuration task, which is the same calculation we lay out in whether to upgrade or replace aging devices.

Application control and security tools pinned to old certificates

KB5132953 warns that App Control for Business (WDAC) policies, CI/CD checks, or security tools that trust Microsoft code by a specific certificate, issuer, or thumbprint may block updated Windows binaries. Symptoms include cumulative updates failing to install, services failing at startup, and Code Integrity Event 3077. This one can cause real outages, and it tends to hit the better-secured environments first.

Installation media, recovery images, and virtual machines

Older USB installers and imaging media default to the 2011 bootloader, while new media will default to 2023. Microsoft's KB also notes that VMware vSphere environments need ESXi hosts and VM hardware versions updated to releases that include the 2023 certificates, while Hyper-V and cloud platforms deliver the change through their own servicing. If your rebuild process after a ransomware incident depends on an old image, test it now, not during recovery.

How should SMBs finish the Secure Boot transition?

Finish the transition by confirming status device by device, fixing the exceptions, and checking the systems that depend on old trust. Microsoft's Secure Boot guidance for IT professionals recommends testing on representative devices, deploying in stages with one method per device, and monitoring Event IDs 1801 and 1808.

1. Confirm Secure Boot is on and check certificate status. On individual machines, Windows Security now shows certificate status under Device security, Secure Boot; Microsoft's Windows Security app status guide notes that a green checkmark alone does not confirm the update, so look for the "all required certificate updates have been applied" message.
2. Build an exception list. Group devices that have not updated by manufacturer, model, and firmware version, then check each OEM for firmware updates.
3. Escrow BitLocker recovery keys before touching boot settings. KB5132953 tells administrators to ensure recovery keys are securely backed up before applying any boot-chain, firmware, or Secure Boot update, because recovery prompts can occur depending on device configuration.
4. Review application control and security tooling. Search WDAC policies for rules pinned to Microsoft Windows Production PCA 2011 and confirm compatibility with your endpoint security vendor.
5. Refresh installation and recovery media, then retire or replace any device with no firmware path to the 2023 certificates.

The machines that fail these checks are usually the same ones carrying other forms of technical debt that undermines your security program. Treat the exception list as a lifecycle input, and fold any rebuild-media fixes into your disaster recovery testing so you know your restores will boot.

How Securafy helps close out Secure Boot certificate updates

For managed clients, we report Secure Boot certificate status across the fleet rather than relying on Microsoft's automatic assist, isolate the devices that have not updated, and work through OEM firmware updates in planned windows with BitLocker keys escrowed first. Devices with no firmware path go onto a replacement schedule with a cost attached, so leadership sees a decision rather than a surprise.

We also check the less visible dependencies: application control policies, endpoint security compatibility, and the installation and recovery media we would use to rebuild systems after an incident. It is the same disciplined approach we take to urgent Windows fixes, which we described in how SMBs should respond when CISA sets a Windows patch deadline.

Where To Go From Here

If no one in your organization can say how many of your devices have the 2023 Secure Boot certificates, that is the first number to get. The expiration dates are behind you, but the protection gap they created grows with every boot-level fix your unpatched devices cannot receive.

If you have an internal IT team that needs extra hands for fleet-wide firmware and certificate work, Securafy's co-managed IT services are designed to work alongside them.

If you would rather walk through your environment first, book a strategy call with Securafy and we will help you identify which devices are still exposed and what it takes to close them out.