The cryptographic trust that sits underneath every modern Windows boot is getting a quiet but important swap. The Secure Boot certificates that have shipped on PCs since 2011 begin expiring in June 2026, and Microsoft is replacing them with a newer 2023 certificate family delivered through Windows Update. The scary version of this story is that machines will refuse to start. The real version is far less dramatic and, for most people, almost invisible.
Quick answer: Keep Windows Update enabled and install the latest cumulative updates. Then open Windows Security, go to Device security > Secure boot, and confirm the status shows the new 2023 trust chain. No manual firmware work is needed on most supported devices.
Which Secure Boot certificates expire in 2026
This is not one single deadline. The 2011 infrastructure ages out in phases across the year, which is why you'll see different dates floating around. The first expirations land in late June, with the Windows operating system key following months later in October.
| Certificate | Role | Expiration |
|---|---|---|
| KEK CA 2011 | Key Exchange Key, used to update the signature databases | June 24, 2026 |
| UEFI CA 2011 | Third-party signature anchor | June 27, 2026 |
| Windows Production PCA 2011 | Native Windows boot manager key | October 2026 |
The replacements issued in 2023 are designed to carry that trust forward, and they're expected to remain valid until 2038. The immediate goal is simply to get existing PCs onto the new chain before the old one ages out.
What happens if you miss the June 2026 deadline
Nothing breaks on day one. A PC that still relies on the 2011 certificates will keep booting and keep running normally. The expiration does not flip a switch that bricks your hardware.
The cost is slower and cumulative. Systems left on the old certificates can stop receiving boot-critical security updates, and they may miss future DBX revocation list updates. That revocation list is what blocks known-bad boot components and bootkit threats such as BlackLotus. Over time, a machine that never gets the 2023 chain becomes harder to protect against firmware-level attacks, and a future boot manager or recovery environment may eventually expect trust material it doesn't have.
So "still boots today" is accurate. It just isn't the same as "stays secure indefinitely."
How to check your Secure Boot status in Windows
You don't have to guess whether the update has landed. Windows now exposes the certificate state directly in the Windows Security app, which removes the old need to dig through PowerShell.
Step 1: Type Windows Security into the search bar and open it. This is the built-in dashboard for device protection.
Step 2: Select Device security, then scroll down to the Secure boot entry. The status text and badge color tell you where the device stands.
Step 3: Read the message. "Secure Boot is on, preventing malicious software from loading when your device starts up" is the healthy state. A line about an "older boot trust configuration that should be updated" means the migration hasn't finished yet.
If you'd rather get a definitive yes-or-no, open PowerShell as Administrator and run a single check. The device must be in UEFI mode with Secure Boot enabled, and the command will not work from inside a virtual machine.
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023')A return value of True confirms the 2023 certificate is present. False means the new certificate hasn't been applied yet.
What the green, yellow, and red Secure Boot badges mean
The status indicator in Windows Security maps to three clear states. Use it to decide whether you can stop worrying or whether the device needs a closer look.
| Badge | Meaning | Action |
|---|---|---|
| Green | The new 2023 certificates are installed | No action needed |
| Yellow | Still on older certificates or waiting for the phased rollout | Install updates and reboot; check again later |
| Red | A boot configuration problem is blocking delivery | Resolve firmware or Secure Boot settings, or apply OEM firmware |
A red indicator is the one that matters for IT teams. It usually signals that the firmware state, disk layout, or device targeting puts the machine outside Microsoft's automatic delivery path, so re-running Windows Update alone may not fix it.
The SecureBoot folder and the extra reboots are normal
Two side effects of this rollout tend to alarm people. The first is a new SecureBoot folder that appears on the C: drive. It is a legitimate staging area where Windows places the certificate files before flashing them to the motherboard's firmware. Deleting it is the kind of "cleanup" that causes the very problems you're trying to dodge, so leave it alone.
The second is repeated restarts. Pushing data into firmware needs one reboot to stage the certificates, another for the firmware to apply them, and a further one to load the newly signed bootloader. An update that restarts more times than usual is expected behavior here, not a failed install.
There's also no need to suspend BitLocker. The process is BitLocker-aware and automatically reseals the keys for BitLocker and Virtual Secure Mode, so Windows Hello and disk encryption stay intact across the reboots.
When the update is skipped or blocked
Not every machine receives the new certificates, and that's intentional. The rules are deterministic.
- Legacy BIOS systems are skipped entirely. They can't do Secure Boot, so they register as not capable and Windows never attempts the update.
- CSM (Compatibility Support Module) devices can still receive the update as long as they retain UEFI and Secure Boot capability.
- Secure Boot disabled in BIOS blocks the update on purpose. Because UEFI implementations vary so widely, Microsoft requires Secure Boot to be actively running to avoid corrupting the boot sequence.
If you've deliberately turned Secure Boot off, the device stays on the old certificates until you turn it back on. One edge case worth knowing: clearing CMOS or resetting the BIOS after the migration can restore the original configuration and trigger a Secure Boot violation at startup. That's usually fixed by letting Windows reapply the certificates or importing the newer keys through firmware settings.
Do Windows 10 PCs need this too?
Yes. The underlying Secure Boot infrastructure is shared, so supported Windows 10 systems get the same 2023 certificates. The catch is eligibility. A Windows 10 machine needs Extended Security Updates (ESU) enabled to keep receiving the relevant updates, since the certificate transition rides along with Windows Update.
For consumers, the Windows 10 ESU coverage runs for one year past the end of mainstream support. Once that window closes, an unmigrated Windows 10 PC feels the weakened boot protection more acutely, because it's already cut off from updates.
Manually forcing the Secure Boot certificate update
Most home users should never need this. The migration is designed to happen on its own through Windows Update, and enabling diagnostic data under Settings > Privacy & security > Diagnostics & feedback helps the system identify which certificates are present. If you're troubleshooting a stubborn device, there is a supported way to trigger it.
Step 1: Open Command Prompt as Administrator and set the available updates flag. This tells Windows to stage the Secure Boot refresh.
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x40 /fStep 2: Kick off the scheduled task that performs the update.
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"Step 3: Restart the PC, and expect it to reboot a couple of times on its own before settling. Afterward, re-run the PowerShell check above. A True result confirms the 2023 certificate is now active.
Note: If the update still fails, the device may need a firmware update from its manufacturer. Some older boards can't accept the new certificate infrastructure without an updated UEFI release.
Servers, Hyper-V, and enterprise fleets
Managed environments need more care than consumer PCs. Windows Server does not follow the automatic consumer rollout, so admins must apply the new certificates manually, as outlined in Microsoft's guidance for preparing servers for Secure Boot certificate updates. Hyper-V deployments may also require updates on both the host and the guest virtual machines before the changes apply correctly.
Do not blanket-enable the "Enable Secure Boot Certificate Updates" policy across an entire fleet. Firmware differences between models can cause failures, and forcing a mass restart without verifying platform alignment can send encrypted machines into a BitLocker recovery loop. Test a representative subset of each hardware model first.
PXE boot has its own limitation. The protocol can offer only one Boot Manager per client, so the 2011 and 2023 Boot Managers can't coexist in a single boot.wim. Once a fleet is fully migrated, admins can mount and update boot.wim manually with DISM. For monitoring, Microsoft provides PowerShell scripts, and Intune-managed devices may surface Event ID 1801 when certificates are available but not yet applied. Event Viewer logs under the TPM WMI source are another place to confirm status.
The headline worth holding onto is that June 2026 is a deadline, not a detonation. Windows 11 and Windows 10 PCs keep starting after the 2011 certificates expire, and a clean Windows 11 install or the move to 26H2 still works for now. The thing to watch is the long tail of forgotten machines, the powered-off spares, kiosks, and lab PCs that never run updates long enough to receive the new chain. For everyone else, keep Windows updated, let it reboot when it asks, leave the new folder where it is, and check for the green badge once you're done.