Secure Boot in late 2026: expired certs, revoked shims, fleet checks

Why this matters now

Microsoft's original Secure Boot certificates have all expired. The KEK CA 2011 expired on June 24, 2026, the third-party UEFI CA 2011 on June 27, and the Windows Production PCA 2011 on October 19, 2026 [Confirmed]. In July 2026, ESET published research on 11 forgotten Microsoft-signed UEFI shims that could bypass Secure Boot on most UEFI machines [Confirmed].

Both stories feed one bad assumption: that an expired certificate makes old boot code untrusted. It doesn't. Revocation does, through the DBX database, and devices that lack the 2023 certificates won't receive future revocations. This guide covers what changed, what didn't, and how to check your fleet with commands that Microsoft, ESET, Canonical, or the mokutil maintainers document.

What expired, and what that does and doesn't mean

Source: Microsoft KB5062710 [Confirmed]. Microsoft split the third-party CA in two so a system can trust option ROMs without also trusting third-party boot loaders.

Myth 1: Expired certificates mean machines stop booting. They don't. Microsoft says devices without the 2023 certificates "will continue to start and operate normally, and standard Windows updates will continue to install" [Confirmed]. Microsoft also warns against disabling Secure Boot to work around expiry [Confirmed].

Myth 2: Expired certificates mean old binaries stop being trusted. They don't. ESET: "the UEFI certificate's expiration date has no effect on the Secure Boot verification process." Canonical says the same: "UEFI firmware does not check the expiry date of CAs when validating signatures" [Confirmed]. As long as a 2011 CA stays in DB and isn't revoked in DBX, binaries it signed keep loading, vulnerable ones included.

What expiry actually costs you. According to Microsoft, devices without the 2023 certificates can no longer receive "updates to Windows Boot Manager, Secure Boot databases, revocation lists, or mitigations for newly discovered boot level vulnerabilities" [Confirmed]. Canonical says Microsoft now uses only the 2023 CAs to sign and deliver revocations. It also warns that Ubuntu updates issued in Q4 2026 or later will require the 2023 CA, and that skipping the CA update "may result in package management failures" [Confirmed]. The result is a machine that boots fine but can no longer receive Secure Boot revocations.

The revoked-shim problem

On July 14, 2026, ESET's Martin Smolár described 11 old, Microsoft-signed UEFI shims, most of them version 0.9 or earlier. They come from Linux distributions, PC-diagnostics tools, drive-wiping software, and other utilities [Confirmed]. Some pre-date SBAT (shim 15.3) or MokListX enforcement (0.9), so they ignore revocations added later. Others trust old GRUB 2 builds with known Secure Boot bypasses. ESET's example is CVE-2015-5281, reached through Oracle Linux's shim [Confirmed].

ESET says the key point is that attackers can bring their own copy of a vulnerable shim to any machine that trusts the Microsoft 2011 third-party CA, whatever OS it runs. CERT/CC (VU#616257) says the attacker needs administrative privileges or the ability to modify the boot process [Confirmed]. Microsoft revoked all 11 by Authenticode hash in the DBX update it shipped on June 9, 2026, Patch Tuesday [Confirmed].

CVE status, checked on October 20, 2026:

• CVE-2026-8863 covers most of the shims. MSRC rates it Important, CVSS 3.1 score 7.8, and as of June 9 marked it "Exploited: No" and "Publicly Disclosed: No." NVD lists it as "Deferred," and its 7.8 score comes from CISA-ADP, not NVD analysis [Confirmed].
• CVE-2026-10797 is the shim 0.9 revocation-check bypass in the RHEL 7.2 and CentOS 7.2 shims. ESET and CERT/CC both reference it, but we found no record for it in the CVE List, NVD, or MSRC. Treat the ID as provisional.
• One openSUSE shim in CERT/CC's table has no CVE listed [Confirmed].
• Neither CVE is in CISA's KEV catalog (version 2026.10.16). ESET does not report in-the-wild exploitation [Confirmed].

ESET notes one useful exception. Windows 11 Secured-core PCs should not trust Microsoft third-party UEFI signing by default, so this attack path shouldn't apply to them [Confirmed]. Verify it: the -Decoded check below should show no Microsoft UEFI CA 2011 in DB.

This has happened before. CVE-2024-7344, a Howyar "Reloader" app that loaded unsigned code, was revoked on January 14, 2025 [Confirmed]. In March 2023, ESET documented BlackLotus, the first publicly known in-the-wild bootkit to bypass Secure Boot, which exploited CVE-2022-21894 more than a year after the fix [Confirmed]. The related Boot Manager flaw, CVE-2023-24932 (mitigated through KB5025885), is marked "Exploited: Yes" by MSRC but isn't in KEV [Confirmed]. Each time, the binaries were already patched, but they stayed trusted until DBX caught up [Our assessment].

Fleet checklist

Run the Windows commands from an elevated PowerShell prompt.

1. Is Secure Boot on? Microsoft (KB5062713):

Confirm-SecureBootUEFI

True means enabled. If it's off, the certificate rollout doesn't apply, but neither does Secure Boot's protection.

2. Are the 2023 certificates in DB, and is the rollout complete? Microsoft (KB5025885):

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'
(Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing").UEFICA2023Status

The first should return True and the second Updated. The other possible values are NotStarted and InProgress. A non-zero UEFICA2023Error in the same key means a step failed (KB5068202). On builds with the April 14, 2026 cumulative update or later, Get-SecureBootUEFI -Name db -Decoded lists subjects and validity dates in readable form (KB5093574) [Confirmed].

3. Read the event log. In the System log, source TPM-WMI, Microsoft documents these event IDs (KB5016061) [Confirmed]:

• 1808: all certificates are applied and the boot manager is updated.
• 1801: certificates are not yet applied.
• 1799: a 2023-signed boot manager was installed.
• 1795: the firmware returned an error. Contact the OEM.
• 1803: Windows has no PK-signed KEK for the device. Ask the OEM.
• 1032: the update was held back because applying it would trigger BitLocker recovery.

4. Did the June 2026 shim revocations land? Run ESET's published check, unchanged:

$hashes = 
'AE75F0D82BA3DF824FBFC69340CC3B4D66C598373B1AB54CDB6C8BFD83A6B961',
'7B2A3F5C96F95BD8086CE54B0825E300F9C8F11FE3401BB631B3215C8DE9EB10',
'EB86FA1386FE6E4533B8B938DCC1250616D2F1C14C15E2FCF80834A161018A0A',
'FD23D6E57DE6F4E1F9D7118DA1C5F31A8AF6BE5E5D9E8170F9493447268D50C5',
'A0DE9333442C1BF9349A460141AE5E80F911955C6506040FA3D021BF6C1AE3E4',
'95B6D71FC0C0F8C5E1533A37AEF92CF6B0C961E2CC612A97117FA6759CE5FC06',
'236A9CB0D71951C36398A32EB660CE2CD4A52CCFA7CF751CC6A35D9DE549E19B',
'5E594C448760A3135B1A3A83E07A4F2E6FBE49414EF2C7CAB1CBA77F284FA63B',
'8A964D5F8373948D20A1D4296FB92E545DAD4617A0C810F3B934B53D98AE8963',
'410260B1B6F5AF5FBEEB9EA3220658435E876CB3247126EE907A437F312DB373',
'96275DFD6282A522B011177EE049296952AC794832091F937FBBF92869028629' 
$dbx = [BitConverter]::ToString((Get-SecureBootUEFI dbx).Bytes) -replace '-'
$notRevoked = $hashes | Where-Object { $dbx -notmatch $_ }
if ($notRevoked) {
    $notRevoked | ForEach-Object { "Hash not revoked: $_" }
} else {
    "All hashes revoked in dbx!"
}

These 11 hashes match CERT/CC's table [Confirmed].

5. Linux hosts. The mokutil man page documents --sb-state, --db, --kek, --dbx, and --list-sbat-revocations [Confirmed]. Check Secure Boot state and the active SBAT revocations:

mokutil --sb-state
mokutil --list-sbat-revocations

For the 2023 certificates, Microsoft's Azure Linux guidance (KB5103014) uses:

mokutil --db | grep "UEFI CA 2023"
mokutil --kek | grep "KEK 2K CA 2023"

If either grep prints nothing, that certificate isn't enrolled. Canonical delivers the 2023 CAs and DBX through fwupd 2.0.0 or later, using fwupdmgr --version, then sudo fwupdmgr refresh and sudo fwupdmgr update [Confirmed]. For Linux, ESET points to the LVFS for revocations and to the uefi-dbx-audit script for checking them. For RHEL, SUSE, Debian, and AlmaLinux, follow each vendor's own guide. Microsoft's Linux guidance warns that updating shim before the firmware variables "may result in a boot failure" [Confirmed].

Staged rollout and BitLocker precautions

Microsoft's playbook for IT-managed fleets (KB5062713) is explicit [Confirmed]:

• Inventory first. Group devices by manufacturer, model, firmware version, and baseboard. Test at least four devices per group before broad deployment.
• Then deploy in stages, and don't mix methods on one device. Options are registry, Group Policy, Intune, or WinCS. Microsoft may also add "high-confidence" device groups to monthly cumulative updates automatically. To opt out, set HighConfidenceOptOut.
• Expect delays. Allow about 48 hours and one or more restarts per device. Applying the update does not force a restart.
• Retire firmware the OEM no longer supports. If old firmware won't take the update, Microsoft suggests replacing the device.

To test one device, Microsoft documents (KB5068202):

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x5944 /f
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"

When AvailableUpdates reads 0x4100, reboot and run the task again.

For BitLocker, Microsoft says "some devices may go into BitLocker recovery" and to keep the recovery key [Confirmed]. Before you touch a device, confirm its recovery key is escrowed:

manage-bde -protectors -get %systemdrive%

If event 1032 appears, KB5016061 says to suspend BitLocker for two restarts. Microsoft prints this command with en dashes; it's shown here with plain hyphens:

manage-bde -protectors -disable %systemdrive% -RebootCount 2

Microsoft's troubleshooting guide (KB5085046) lists three more traps [Confirmed]:

• A single recovery prompt on the first boot after the update is a known, one-time event.
• Recovery on every boot often means PXE is first in the boot order, so BitLocker measures a 2011-signed and a 2023-signed boot path in the same boot. Fix the boot order.
• Resetting Secure Boot to firmware defaults after the transition can make the device unbootable, unless the OEM's defaults include the 2023 certificates.

What we don't know yet

• When Microsoft will force the PCA 2011 revocation. KB5025885 was revised on September 30, 2026, and the date for automatically adding PCA 2011 to DBX is still "to be announced." Microsoft has promised at least six months' notice. ESET says the revocation is coming "soon." When it happens, old recovery and PXE media will stop booting. That September revision, which added an "older external boot media" known issue, is the only Microsoft change to this guidance we found from September or October. The announcements page has no entries after July 15.
• How many forgotten shims remain. ESET says nobody can reliably count the shims signed before shim-review began in 2017.
• Whether CVE-2026-10797 will be published. The ID has no record in the CVE List, NVD, or MSRC yet.
• Regional exposure. We know of no data on how widespread vulnerable shims or missing 2023 certificates are in Latin America, and we won't estimate.

[Our assessment] Treat this as an inventory problem, not a race against a date. The real risks are unrevoked boot code and devices that can no longer receive revocations. If a check turns up a revoked shim on an EFI System Partition where it doesn't belong, treat it as a possible compromise rather than a patching gap. That's the kind of question our compromise assessment answers. You can run every check above yourself, without us.

Sources

• Microsoft, KB5062710, Windows Secure Boot certificate expiration and CA updates (published Jun 26, 2025; updated May 18, 2026).
• Microsoft, KB5079373, When Secure Boot certificates expire on Windows devices (Feb 10, 2026).
• Microsoft, KB5062713, Secure Boot certificate updates: Guidance for IT professionals and organizations (published Jun 26, 2025; updated May 5, 2026).
• Microsoft, KB5068202, Registry key updates for Secure Boot (published Oct 14, 2025; updated Mar 20, 2026).
• Microsoft, KB5016061, Secure Boot DB and DBX variable update events (published Jun 15, 2022; updated Jun 2, 2026).
• Microsoft, KB5025885, Boot Manager revocations for CVE-2023-24932 (published May 9, 2023; updated Sep 30, 2026).
• Microsoft, KB5093574, Using the -Decoded parameter in Get-SecureBootUEFI (Apr 28, 2026).
• Microsoft, KB5085046, Secure Boot troubleshooting guide (Mar 19, 2026).
• Microsoft, KB5081884, Updates and announcements (updated Jun 29, 2026).
• Microsoft, KB5103014, Secure Boot certificate updates for Linux on Azure virtual machines (Jun 12, 2026).
• MSRC, CVE-2026-8863 (Jun 9, 2026).
• ESET, Martin Smolár, Forgotten UEFI shims undermining Secure Boot (Jul 14, 2026).
• CERT/CC, VU#616257 (published Jun 9, 2026; updated Jul 14, 2026).
• NVD, CVE-2026-8863.
• CISA, Known Exploited Vulnerabilities catalog, checked 20 October 2026 (version 2026.10.16).
• ESET, Under the cloak of UEFI Secure Boot: Introducing CVE-2024-7344 (Jan 16, 2025).
• ESET, BlackLotus UEFI bootkit: Myth confirmed (Mar 1, 2023).
• Canonical, Microsoft UEFI CA rotation: What it means for Ubuntu users and vendors (May 21, 2026; updated Jun 23, 2026).
• mokutil(1) man page, Ubuntu 24.04.
• uefi-dbx-audit (referenced by ESET).
• MITRE ATT&CK, T1542.003 Pre-OS Boot: Bootkit.