Secure Boot Certificates Expire June 2026 — Checklist for IT Leaders to Prevent BitLocker Lockouts

Secure Boot certificates expire June 2026 — what IT leaders need to do now

TL;DR: Microsoft-issued Secure Boot certificates from 2011 expire in June 2026. Most vendor-supported Windows PCs will get replacement “Windows UEFI CA 2023” certificates via firmware and Windows updates, but unmanaged, legacy, DIY and some Linux-only systems may need manual intervention. Run a quick check, inventory your fleet, and verify BitLocker recovery key availability now.

Why this matters

Secure Boot is the firmware-level guard that verifies bootloaders and pre-boot components. It relies on a chain of trust (UEFI, KEK — Key Exchange Key, vendor and Microsoft certificates, and TPM-managed databases DB/DBX). Certificates expire by design; the 2011 Microsoft-issued CAs are scheduled to retire in June 2026.

When those certificates expire on devices that haven’t received replacements, Windows can stop trusting new bootloaders and stop accepting security fixes for pre-boot components. That can lead to boot failures, loss of manageability, and BitLocker-encrypted volumes becoming inaccessible unless recovery keys are available.

“You might soon see a firmware update that will bring your computer’s security core into the modern era, pushing the certificate expiration dates out by another decade or more.” — Microsoft

“When the 2011 CAs expire, Windows devices that do not have new 2023 certificates can no longer receive security fixes for pre-boot components, compromising Windows boot security…. Without updates, the Secure Boot-enabled Windows devices risk not receiving security updates or trusting new boot loaders, which will compromise both serviceability and security.” — Microsoft

Who is at risk

  • Low risk: Modern consumer and corporate laptops from major OEMs (Dell, HP, Lenovo, ASUS, Microsoft Surface) running supported Windows versions — likely to receive automatic updates.
  • Medium risk: Corporate fleets with blocked firmware channels, older Windows 10 machines that rely on Extended Security Updates, or air-gapped systems.
  • High risk: Home-built desktops (depends on motherboard vendor firmware support), legacy servers and appliances, industrial/IoT devices, and pure Linux installs without vendor firmware updates.

How to check now (fast)

Run the following PowerShell command as Administrator on a Windows machine to check for the replacement certificate:

([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023')

If the command returns True, the device has the 2023 certificate. If it returns False, the device likely needs a firmware update (or other remediation).

Run this across an environment with PowerShell remoting or via your management tooling. Example (requires domain admin rights, WinRM enabled):

$computers = Get-ADComputer -Filter * | Select -ExpandProperty Name
$results = foreach ($c in $computers) {
  $ok = Invoke-Command -ComputerName $c -ScriptBlock { ([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023') } -ErrorAction SilentlyContinue
  [PSCustomObject]@{Computer=$c;Has2023Cert = $ok}
}
$results | Export-Csv SecureBootStatus.csv -NoTypeInformation

For Linux systems:

  • Check Secure Boot state: mokutil --sb-state
  • List EFI variables: efivar -l (look for DB/DBX entries and inspect contents)
  • Note: many dual-boot Linux installs benefit from Microsoft’s update path; pure Linux-only systems often depend on vendor firmware updates or enrollment via MOK/shim workflows.

If you use Microsoft Endpoint Manager, SCCM, or other endpoint management tools, deploy the above PowerShell script as a detection script and collect results into a dashboard (recommended metrics: % devices with 2023 CA, devices missing firmware updates, devices with Secure Boot disabled, BitLocker recovery events).

Immediate remediation options and trade-offs

  • Firmware + Windows updates (preferred): OEMs issued 2023 certificates in 2023 and began provisioning them in 2024; many devices get them automatically via monthly Windows and firmware updates. Ensure OEM update channels are open and firmware updates are applied.
  • Manual firmware update: For unsupported or unmanaged systems, download vendor firmware packages and follow vendor instructions to provision the new KEK/platform keys.
  • Disable Secure Boot (temporary workaround): May allow booting but will typically block BitLocker access and reduce pre-boot security. Only use as a last resort with recovery keys verified.
  • Replace hardware: For devices with no firmware update from the vendor (common in very old motherboards), budget for replacement or isolated exception handling.

Important: disabling Secure Boot without having BitLocker recovery keys will almost certainly lead to locked drives. Confirm and test recovery key access before attempting Secure Boot changes.

Prioritized 6-step checklist for IT leaders

  1. Inventory now: Identify unmanaged, DIY, server, appliance, and air-gapped devices. Flag Linux-only systems and custom hardware.
  2. Run the certificate check: Execute the PowerShell and Linux checks across representative SKUs and locations within 2 weeks.
  3. Backup and verify BitLocker keys: Ensure keys are stored in Azure AD, AD, or your recovery vault and test a recovery on a non-production device.
  4. Pilot firmware updates: Stage updates on representative systems first; verify boot behavior and BitLocker access. Keep rollback/recovery plans ready.
  5. Mass rollout: Deploy firmware and Windows updates via OEM tools, MEM/SCCM, or vendor utilities. Monitor for failures and recovery events in real time.
  6. Validate and report: Confirm the percentage of updated devices, remaining at-risk systems, and escalate replacement plans for unsupported hardware.

Practical timeline (work backwards from June 2026)

  • Today – 2 weeks: Inventory and run checks on a sample set of devices; verify BitLocker key backups.
  • 2–6 weeks: Pilot firmware updates and confirm rollback procedures.
  • 6–12 weeks: Stage and roll out updates to broader groups; prioritize high-risk devices (servers, air-gapped, custom builds).
  • Final 30 days before June 2026: Validate all critical systems; prepare incident response for any unexpected BitLocker recoveries or failed firmware updates.

Vendor coordination — what to ask your OEMs and motherboard vendors

  • Do you provide firmware that provisions the “Windows UEFI CA 2023” certificate to affected models?
  • Which specific SKUs and firmware versions include the updated KEK/eventual rollback guidance?
  • What is the firmware update process for air-gapped or manually managed systems?
  • What are rollback options if an update fails mid-provisioning?
  • Are there known compatibility issues with specific Linux bootloaders (shim, GRUB, custom signings)?

If something goes wrong — immediate triage

  • Confirm BitLocker recovery key availability for the affected device (Azure AD / AD / recovery vault).
  • Attempt to boot to vendor recovery/firmware update mode; some firmware supports USB-based recovery that can re-provision keys.
  • Contact vendor support with firmware logs and device serial; escalate if the device is business-critical.
  • If rollout caused mass issues, pause further firmware pushes and revert to your tested rollback procedure.

Common questions, answered

Which certificates are expiring and when?
The Microsoft-issued 2011 CAs expire in June 2026. Microsoft released replacement “Windows UEFI CA 2023” certificates in 2023 and OEMs have been provisioning them since 2024.

Will my fleet be updated automatically?
For most modern, vendor-supported Windows devices, yes — updates are delivered via monthly Windows updates and OEM firmware packages. Exceptions include unsupported motherboards, air-gapped machines, and some Linux-only devices.

How do I check quickly?
Run the PowerShell check as Administrator: ([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'). On Linux, use mokutil --sb-state and inspect EFI variables with efivar -l.

What happens if I ignore this?
Devices may stop receiving pre-boot security fixes, fail to trust new boot loaders, refuse to boot, or cause BitLocker recovery events. That’s an operational and security headache — particularly at scale.

Are Macs affected?
No. Macs are not affected by Microsoft’s Secure Boot certificate rollout.

Communication templates — quick copy for your teams

To IT staff (short):
“Run the Secure Boot certificate check on your assigned devices this week. Confirm BitLocker recovery keys are backed up. Pilot firmware updates on 5 representative SKUs before broader deployment.”

To leadership (short):
“Microsoft’s 2011 Secure Boot certificates expire June 2026. Most vendor-supported Windows devices will update automatically, but unmanaged and legacy hardware may require manual firmware updates or replacement. We will inventory and report exposure within two weeks.”

Final notes and recommended next steps

  • Start inventory and the PowerShell checks this week.
  • Verify BitLocker recovery key backups and test a recovery before attempting mass updates.
  • Prioritize devices outside normal update channels (DIY, servers, industrial, air-gapped).
  • Coordinate with OEMs for firmware packages and rollback guidance where vendor support exists.
  • Monitor dashboards for post-update boot and recovery events and be ready to escalate vendor support.

Treat this like any other platform-level certificate rotation: it’s boring, predictable, and entirely avoidable — if you act now. Run the checks, stage the updates, and keep recovery keys at hand so the alarm clock stays silent at 2 a.m.

Sources & further reading: Microsoft guidance on Windows UEFI CA 2023 and certificate lifecycle; OEM support pages (Dell, HP, Lenovo, ASUS, Microsoft Surface) for firmware updates; vendor firmware advisories and your endpoint management documentation.

0