What Happened
Microsoft has confirmed that three Secure Boot signing certificates — foundational components of the technology that verifies your organisation’s servers and workstations have not been tampered with before the operating system loads — will expire between June and October 2026.
Secure Boot is the mechanism that prevents malicious software from inserting itself into the boot process before your security tooling, your endpoint detection software, and your operating system can defend against it. It is a primary defence against a class of attack called UEFI bootkits — malware that sits below the operating system and is invisible to all standard security tools. The first UEFI bootkit capable of bypassing fully patched Windows 11 systems was publicly documented in 2023, demonstrating that this threat is operational, not theoretical.
The certificates expiring in June 2026 are the mechanism by which your fleet receives revocations of compromised boot software. After June, systems that have not been updated cannot receive updates to the revocation list — meaning known bootkit software cannot be blocked, even after public disclosure.
This is a hard deadline with fixed consequences. It cannot be addressed by a software patch alone — it requires OEM firmware updates that must come from hardware manufacturers, and that process takes weeks.
Business Impact
Organisations that fail to act before June 26 will face:
Permanent loss of boot security updates. Systems running on expired certificates cannot receive updates to the list of blocked boot software. This is not a temporary gap — it is a permanent limitation until hardware is replaced or firmware is updated.
Increased exposure to UEFI bootkit attacks. Bootkits that execute before the operating system loads can disable endpoint security tools, survive full OS reinstallation, and persist through standard incident response procedures. Recovery from a successful bootkit attack typically requires physical reimaging at the hardware level.
Regulatory compliance risk. Many regulatory frameworks require maintenance of security controls at known effective states. Operating on expired cryptographic certificates for boot integrity verification is likely to be considered a configuration deficiency during audits under NIS2, DORA, and ISO 27001.
Legacy hardware write-off. Systems manufactured before approximately 2015 may not receive firmware updates from their OEMs. If your estate includes older hardware, this is a forced decommission timeline.
The cost exposure varies by fleet size, but organisations with large managed Windows estates — common in financial services, healthcare, and government — face significant project cost to coordinate OEM firmware updates across thousands of devices before the deadline.
Regulatory Implications
NIS2 / DORA: Both frameworks require maintenance of effective technical controls and timely remediation of known security gaps. Operating on expired cryptographic certificates for boot integrity after a publicly-announced deadline is a foreseeable audit finding.
ISO 27001 (A.8.8): Technical vulnerability management obligations cover known configuration deficiencies, not only exploits. The June 2026 Secure Boot expiry is a documented, dated risk with a known mitigation — failure to address it before the deadline sits squarely within vulnerability management scope.
NIST CSF: Under the Protect function, cryptographic key management (PR.DS-2) includes certificate lifecycle management. Expired Secure Boot certificates represent a lapse in cryptographic control.
Board-Ready Summary
- The technology that verifies your Windows systems have not been tampered with before they boot expires in June 2026. Without action, your organisation permanently loses the ability to receive security updates for this protection layer.
- Fixing this requires coordinating hardware firmware updates from your PC and server manufacturers — a process that takes 4–6 weeks for a managed enterprise fleet. The deadline is 11 weeks away.
- Older hardware manufactured before ~2015 may never receive the fix and should be earmarked for decommission.
Recommended Actions
-
Inventory Secure Boot certificate status this week. Deploy a compliance query through Intune or SCCM to identify devices currently showing Secure Boot certificate warnings. Microsoft’s Windows Security app now displays affected device status. Produce a count of affected devices by hardware vendor and age.
-
Identify devices that cannot be updated. Flag hardware from approximately 2011–2015 for OEM firmware update availability check. Devices with no available firmware update should be reviewed for decommission before June 26. Do not leave them as permanent exceptions without documented risk acceptance.
-
Engage OEM firmware update processes immediately. Contact Dell, HP, Lenovo, Microsoft Surface, and other hardware vendors for Secure Boot 2023 certificate firmware packages. For enterprise hardware managed through WSUS or Intune, begin procurement and testing of firmware update packages now.
-
Stage the update process — firmware before OS. Microsoft’s published playbook requires OEM firmware to be updated before the Windows OS certificate transition update is applied. Applying these in the wrong order can result in devices that fail to boot. Follow the published playbook and test on a representative sample group first.
-
Update BitLocker recovery documentation before deployment. Certificate updates can trigger BitLocker recovery prompts on some configurations. Ensure recovery keys are accessible and documented for every device before beginning the rollout.
-
Set a hard internal deadline of 15 June. The June 26 expiry leaves no room for last-minute delays. A realistic enterprise rollout — test group, issue resolution, broad deployment — requires a minimum of four to six weeks. Beginning now targets completion by mid-June with margin for delay.