Three Microsoft signed certificates at the heart of UEFI Secure Boot, the low level firmware check that runs before Windows or Linux loads, are about to expire, and the fix is not automatic.
On June 24, three Microsoft-signed certificates quietly expire. They are not the kind of certificate most people have ever thought about, but they are the reason a modern PC can be trusted to boot clean software rather than malware that hides beneath the operating system. After that date, machines that have not been updated face a quiet but consequential choice: accept a weakened defense against a class of firmware-level attacks, or take action now.
These certificates sit at the top of a chain of trust that defines Secure Boot, a Microsoft-designed mechanism that checks the digital signatures of every piece of firmware and boot-time software against a list of approved providers, starting with the motherboard manufacturer. As Wired reports on the approaching deadline, the check runs before the operating system ever loads, which is what gives Secure Boot its power: it can stop malicious code that antivirus software would never see, because antivirus runs later, inside the operating system.
The expiration threatens protection against UEFI bootkits, a class of malware that infects the Unified Extensible Firmware Interface (the modern replacement for the old BIOS, the low-level firmware that hands off control to the operating system) before the OS or any anti-malware product has a chance to load. Once installed, a bootkit typically drops credential stealers, backdoors, or other payloads, and can reinfect the operating system even after a clean reinstall, because the infection lives below the OS.
The exposure is cross-platform. Both Windows and Linux systems that rely on UEFI Secure Boot with the Microsoft certificate chain are affected. This is not a Windows-only patch cycle. It is a shared foundation that most users have never been told exists.
A missed update will not detonate on June 25. PCs will keep booting. But the cryptographic chain that validates legitimate firmware will be weakened or broken on machines that have not absorbed the new certificates, leaving them more exposed to a class of attack that is harder to detect and harder to clean than ordinary malware.
It is also worth saying out loud: a single certificate-expiration event, scheduled years in advance by one vendor, sits in the path of nearly every modern PC. The existing chain-of-trust model concentrates risk in a place most users have never been told about, and that structural weakness is the real story behind the deadline. Reporting on the expiration should not soften that critique.
How the deadline actually lands depends on the platform. Microsoft ships updated certificates through Windows updates, but the chain ultimately has to be carried by the device firmware, the UEFI itself, and firmware updates do not flow through the same channels as operating system patches. Linux distributions handle their own chain through shim and distribution-specific keys, and tools like fwupd exist to push firmware updates to supported hardware, but coverage is uneven across vendors and devices.
For end users, the practical move is to check whether the machine has received a firmware update in the past year and to install any pending UEFI or BIOS update from the manufacturer. IT and operations teams should treat June 24 as a hard date to verify that managed fleets have absorbed the new Microsoft certificates, and that Linux endpoints using distribution-managed shims are running supported shim versions.
The close is constructive, not fear-driven. Microsoft and the major Linux distributions are not ignoring the deadline, and remediation work is underway. The point of writing about it now is that "the chain renews itself" is the wrong mental model. Firmware-level trust is a category that requires active maintenance, not passive assumption, and June 24 is a useful prompt to check.