On 24 June 2026 — this Tuesday — a set of cryptographic keys that underpin the Secure Boot process on Windows and Linux machines will begin to expire. If you've never heard of this, you're not alone. But the consequences of ignoring it range from annoying (systems that won't boot after an update) to serious (machines left exposed to bootkit malware that Secure Boot was specifically designed to stop).

Here's the short version of what Secure Boot actually does. When your computer starts up, before the operating system loads, firmware checks that every piece of boot software has been signed by a trusted key. It's a chain of trust designed to ensure nobody has tampered with your boot sequence — the kind of attack that nation-state malware like BlackLotus specifically targets. The keys doing that signing have a finite lifespan, and a batch of them are hitting their expiry date right now.

Who is actually at risk? The impact varies depending on your setup. Home users running standard Windows 11 on modern hardware are likely covered by automatic updates Microsoft has been quietly pushing for months. The bigger exposure is in enterprise environments — particularly organisations running older hardware, custom Linux distributions, dual-boot configurations, or systems that have been carefully locked down and aren't receiving automatic firmware or bootloader updates. Virtualisation environments and servers are also in scope.

For Linux users, the picture is patchier. Distributions like Ubuntu, Fedora, and SUSE have issued updated shim packages (the small piece of software that bridges firmware and the bootloader), but whether those updates have actually landed on every machine in a fleet is a different question. If your Linux systems run a rolling update process, you're probably fine. If someone last touched that server in 2024, check now.

The practical risk has two flavours. First, if the expired keys are revoked as part of the transition, machines running older signed bootloaders could simply refuse to start — a business continuity problem. Second, and more concerning from a security standpoint, the window between key expiry and full revocation is exactly the gap attackers will probe. Bootkits that survive only because old keys aren't yet revoked become newly potent.

What should you do before Tuesday? Microsoft's guidance says to ensure your Windows devices have received updates from the last few months and that UEFI firmware is current. For Linux, check that your distribution's shim and GRUB packages are at their latest versions. If you manage a fleet, now is a good time to audit which machines haven't checked in for updates recently — those are your risk surface.

The Australian context: Organisations covered by the Security of Critical Infrastructure Act — utilities, financial services, health, transport — have an obligation to maintain patching and configuration hygiene on their systems. A boot-level vulnerability or misconfiguration isn't the same category of risk as an unpatched application server, but the principle is identical. If your asset register doesn't track firmware patch state, this week is a reasonable prompt to fix that.

The expiry itself is a planned, managed transition — not a zero-day. But "planned" doesn't mean "painless," and the organisations most likely to be caught off guard are the ones that have the least tolerance for unplanned downtime.

Watch for: post-deadline reports of boot failures in enterprise environments, and any threat actor attempting to exploit the transition window before revocation is fully enforced.