Secure Boot Certificate Rotation 2026: What Breaks and What to Do

All three Microsoft Secure Boot certificate authorities from 2011 have now expired: the KEK CA on 24 June 2026, the UEFI CA on 27 June 2026 and the Windows Production PCA on 19 October 2026. Machines that missed the update still boot today. What they lose is the ability to accept future boot fixes, so check db and KEK on every Windows and Linux machine and finish the rollout.

That is the answer as of 23 October 2026. This post is the runbook for the period after the deadlines. Our earlier checklist, Secure Boot certificates expiring in 2026: what to check on devices, covered the run up to June. Here we cover what happened after the June expiries, what the 19 October expiry changes, and the Linux side: dual signed shims, distro status, fwupd, virtual machines and TPM sealed disks.

One honest note first. The boot chain (firmware, shim, GRUB, Windows Boot Manager) sits almost entirely outside what Safeguard does. We say exactly where the small overlap is near the end.

Key takeaways

• The dates are behind us. Microsoft lists KEK CA 2011 expiring 24 June, UEFI CA 2011 on 27 June and Windows Production PCA 2011 on 19 October 2026.
• Expiry did not stop machines booting. Microsoft, Red Hat, Canonical, Debian and Fedora agree: firmware generally does not enforce certificate dates.
• The risk is the next update. New shims, new Windows Boot Manager builds and new db and dbx updates are signed only under the 2023 hierarchy. A machine without the 2023 certificates cannot take them.
• Linux moved to dual signed shims. Debian, RHEL, Fedora Rawhide and Rocky Linux ship shims carrying both signatures. Canonical says Ubuntu updates from Q4 2026 may need the 2023 CA.
• Some hardware cannot take the update cleanly. Red Hat names HP and Fujitsu platforms where standalone db updates are blocked pending firmware. Do not force them.
• TPM sealed secrets will notice. A db change alters PCR7, so expect BitLocker and LUKS recovery prompts unless you suspend or reseal first.
• Old boot media is the quiet casualty. After the BlackLotus revocation, Microsoft says older media can fail to start.

Where things stand on 23 October 2026

Dates below were confirmed on the source named in each row.

The KB5025885 enforcement phase, when Microsoft revokes the Windows Production PCA 2011 automatically on capable devices, still had no announced date when we checked. Microsoft says it will not begin before January 2026 and promises at least six months' warning.

Which certificates expired, and what replaced them

Microsoft's expiration page lists the Microsoft UEFI CA 2011 twice because its replacement is split: one CA for third party boot loaders, one for option ROMs.

Expiry dates and names come from Microsoft; the "valid until" dates come from Debian's CA changes page.

A naming trap: Microsoft's support page records a November 2025 correction from "Microsoft Corporation KEK CA 2023" to "Microsoft Corporation KEK 2K CA 2023", but the shorter form still appears in Microsoft's OEM key guidance and its description of event 1043. Grep for "2023" and read what comes back.

How the stores fit together

The PK belongs to the device maker and authorises changes to the KEK. The KEK authorises changes to db and dbx. The db lists certificates whose signatures firmware accepts for boot loaders, drivers and option ROMs. The dbx lists what firmware must refuse, checked before db. That chain explains the rotation: Microsoft can only push a db entry if the machine trusts a Microsoft KEK, and new db and dbx payloads are now signed under the 2023 KEK. A machine that never received the 2023 KEK cannot verify them.

Does an expired certificate stop a machine booting?

No. Microsoft says devices that miss the new certificates "will continue to start and operate normally." Red Hat says Secure Boot systems keep booting whether or not they are updated, as long as the 2011 certificate stays in db and is not revoked. Canonical says firmware does not check CA expiry. Debian says the UEFI specification does not enforce certificate dates, "barring buggy firmware."

So the expiry is not a cliff. It is a slow loss of serviceability. A machine that trusts only 2011 certificates cannot accept:

1. New boot loader builds. Shims submitted after 27 June come back signed only by the Microsoft UEFI CA 2023, and new Windows Boot Manager builds are signed under the Windows UEFI CA 2023.
2. New db and dbx updates, which are signed under the 2023 KEK.
3. Fixes for new boot level vulnerabilities, which Microsoft names explicitly.

Nothing breaks on the day. It breaks the first time a boot loader security fix ships and a machine cannot take it.

What happened after the June expiries

The June dates passed without an outage. LWN's 1 July piece, written by a Microsoft employee working on the transition, calls it preventive maintenance and reports no specific boot failures caused by the expiry itself. The update process had its own problems, though.

• Ubuntu paused its fwupd rollout. Canonical shipped fwupd 2.0 to Ubuntu 22.04 and 24.04 in June so they could apply the 2023 certificates. It paused on 11 June after crashes on MTD devices and on BitLocker or TPM full disk encryption systems, and said the initial rollout was complete by 23 June.
• Some platforms block standalone db updates. Red Hat says this applies to some HP and Fujitsu platforms because of boot failures, and they need a firmware update first. Its advice: "Do not force install db updates."
• Forced updates damaged some machines. LWN reports that forced trust database updates left some machines unbootable, some needing physical access to recover and some permanently damaged.
• One fwupd version was not enough. Debian records that fwupd 2.0.8 was insufficient (bug 1138871) and 2.0.20 is confirmed good.

The opposite problem also appeared. Debian documents 2024 and later hardware that ships with the 2023 certificates but without the 2011 UEFI CA (bug 1112197), so older 2011 only shims fail there. Microsoft's own Windows 11 version 25H2 OEM requirements list only the 2023 KEK and the Windows UEFI CA 2023 in the default configuration, with the third party and option ROM CAs in an alternative configuration for machines meant to run Linux. One fleet can hit both failure modes: old machines that reject 2023 only shims, and new machines that reject 2011 only shims.

LWN also records a disagreement about urgency. Matthew Garrett argued you can boot older media, update the trust database, then move to newer media. The LWN author agreed that path exists but said it does not suit strict uptime rules, restricted boot media policies or remote only access. For a laptop on your desk the recovery path is real; for a remote fleet it is a site visit.

The 19 October Windows Production PCA expiry

Four days ago the last 2011 certificate expired. The Microsoft Windows Production PCA 2011 signed every Windows Boot Manager from Windows 8 onward.

• Your current boot manager keeps working. Nothing in Microsoft's guidance says the date alone stops it.
• Future boot manager servicing needs the Windows UEFI CA 2023 in db. Microsoft requires OEMs to ship the 2023 signed boot manager on devices and media because that is the one "that will continue to be serviced after the 2011 certificates expire."
• The PCA 2011 is also the target of the BlackLotus revocation, which is where the two timelines meet.

Where BlackLotus fits

CVE-2023-24932 is fixed by revoking old Windows boot managers. KB5025885 triggers each step with a bit in the AvailableUpdates registry value:

Step 1 is the certificate rollout this post is about. Step 3 revokes the 2011 Windows certificate outright. Microsoft says that once applied, firmware will not boot a PCA 2011 signed boot manager, the change cannot be reverted under Secure Boot, and reformatting the disk does not remove it. In the enforcement phase Microsoft will apply it automatically on capable devices.

The old boot media problem

KB5025885 lists a known issue: after the April 2026 update and the PCA 2011 revocation, the SVN update can stop older external boot media from starting. Microsoft says media built on or before January 2025 is affected and must be updated. If your recovery plan is a 2024 USB stick in a drawer, test it now.

Devices that never receive the new KEK and db entries

They freeze in time.

• Windows: Microsoft lists the loss of Boot Manager updates, db and dbx updates and new boot level mitigations, and says BitLocker hardening and third party boot loaders may be affected.
• Linux: Canonical says 2011 only installs keep booting but stop receiving shim security updates, leaving GRUB and fwupd open to possible downgrade attacks, and package management may fail on updates from Q4 2026.
• Azure: Microsoft says Linux Trusted Launch VMs with only the 2011 certificates still boot but stop receiving protections; Confidential VMs must be recreated.
• Red Hat warns such systems may eventually face a choice between a vulnerable shim and disabling Secure Boot.

Microsoft suggests considering replacement for older devices that will not update. Treat them as documented exceptions with an end date.

How to check which certificates a machine trusts

On Windows

Microsoft documents Confirm-SecureBootUEFI for Secure Boot state and Get-SecureBootUEFI for reading PK, KEK, db and dbx. The cmdlet returns raw bytes, so a string match finds certificate names. Use an elevated PowerShell session.

# Secure Boot on? Should print True.
Confirm-SecureBootUEFI

# 2023 certificates present in db and KEK?
$db  = [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI -Name db).Bytes)
$kek = [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI -Name KEK).Bytes)
$db  -match 'Windows UEFI CA 2023'
$db  -match 'Microsoft UEFI CA 2023'      # expected only if the 2011 UEFI CA was present
$db  -match 'Option ROM UEFI CA 2023'     # same condition
$kek -match 'KEK 2K CA 2023'

# Rollout status as Windows records it
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing' |
  Select-Object UEFICA2023Status, UEFICA2023Error, UEFICA2023ErrorEvent, WindowsUEFICA2023Capable, ConfidenceLevel

Microsoft defines UEFICA2023Status as NotStarted, InProgress or Updated, and UEFICA2023Error as zero on success. Then check events. Microsoft's KB5016061 lists them; these matter most:

Get-WinEvent -FilterHashtable @{ LogName = 'System'; Id = 1032,1043,1044,1045,1795,1801,1802,1803,1808 } -MaxEvents 50 |
  Select-Object TimeCreated, Id, LevelDisplayName, Message | Format-List

Event 1803 deserves attention after the June KEK expiry. It means the device maker never supplied Microsoft with a KEK update signed by the device's own PK, so only the OEM can fix it.

On Linux

Debian, Ubuntu, Red Hat, Fedora, Rocky Linux and Microsoft's Azure page all use mokutil.

[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS   # UEFI boot at all?
mokutil --sb-state                                  # Secure Boot enabled?
mokutil --db  | grep 'Subject:.*Microsoft'          # Microsoft certificates in db
mokutil --kek | grep 'Subject:.*Microsoft'          # Microsoft certificates in KEK

You want Microsoft UEFI CA 2023 in db and Microsoft Corporation KEK 2K CA 2023 in KEK. Canonical says the rollout is complete when those two and the Microsoft Option ROM UEFI CA 2023 are enrolled.

Then check which keys signed the shim you boot, as Red Hat and Fedora show:

findmnt /boot/efi          # confirm where the EFI system partition is mounted
ls /boot/efi/EFI/          # find your distro's directory: redhat, fedora, debian, ubuntu
sudo pesign -S -i /boot/efi/EFI/redhat/shimx64.efi

A dual signed shim shows two signers, one chaining to each CA.

The Linux shim side in depth

Why Linux depends on a Microsoft certificate

On most PCs the only third party certificate in db is Microsoft's, so distributions send their first stage loader, shim, to Microsoft for signing. Shim then carries the distribution's own key and verifies GRUB and the kernel. When the Microsoft UEFI CA 2011 expired, every distribution supporting Secure Boot on stock PCs was affected at the first stage, even though GRUB and kernel signing did not change.

The dual signed shim

Microsoft began signing shim with the 2023 CA in October 2025, which Debian's page and Steve McIntyre's post both call very late. Until the old CA expired, Microsoft returned a signature from each CA, and distributions attached both to one binary. McIntyre describes doing this with sbattach and putting the older signature first to help buggy firmware. His May advice to distributions: "you should really try to get a new build prepared and signed NOW".

After 27 June, new submissions get only the 2023 signature. The dual signed shims already in archives are a one time asset; the next shim security fix will be 2023 only. Rocky Linux notes that whether a dual signed shim validates depends on firmware parsing more than one signature, and Debian asks users to report machines that refuse it. Early Fedora testing, per McIntyre, found no problems.

Distribution status, as published

Red Hat's two documents differ on RHEL 7. The June blog says RHEL 7.9 will not get a dual signed shim and any future shim will be 2023 only; the knowledge base says only that the RHEL 7 shim "will be updated if needed." Plan for RHEL 7.9 machines to need the 2023 CA before any future shim update.

Where SBAT comes in

The shim project's SBAT document explains why revoking by hash does not scale: the 2020 BootHole fix added three certificates and 150 hashes to dbx, about 10 kB of a typical 32 kB store. SBAT instead gives each boot component a generation number and lets a UEFI variable set the minimum allowed. The link to this rotation is Canonical's downgrade warning. A machine that cannot take a new shim also misses the SBAT level increases that ride along with it, so it keeps accepting older boot components it should have stopped trusting. For SBAT and dual boot history, see Secure Boot and the software supply chain and UEFI Secure Boot supply chain in 2026.

Installation media and cloud images

Canonical flags a timing trap. Current Ubuntu media needs the 2011 CA; future media, including upcoming 26.04 point releases, may need the 2023 CA, with extra steps on devices that lack it. An old server may install fine from today's media and fail from next spring's. Update the trust database while the machine still runs.

Option ROMs: the part people forget

Option ROMs are small UEFI drivers on add in cards such as some network cards, storage controllers and GPUs. Microsoft's key guidance says a UEFI driver "shall not execute if it is not trusted in the db." The 2011 UEFI CA signed both boot loaders and option ROMs; the 2023 hierarchy splits them.

• Do not remove or revoke the 2011 UEFI CA. Fedora and Red Hat warn it still signs option ROMs on existing cards, and adding it to dbx would also stop the dual signed shim. It is expired, not compromised.
• New cards may need the 2023 option ROM CA, Rocky Linux notes.

Microsoft's scheduled task adds the Option ROM and Microsoft UEFI CA 2023 only if the 2011 UEFI CA is already present, so a Windows only locked machine gets only the Windows CA.

What role OEM firmware updates play

The new certificates arrive two ways. OS delivered variable updates: Windows applies Microsoft signed db and KEK payloads through a scheduled task, and Linux applies the same payloads plus OEM KEK payloads through fwupd and LVFS. OEM firmware updates: some machines need new firmware first, either for buggy variable handling or because the KEK update must be signed by the maker's PK. Microsoft says all OEMs "must create, sign, and submit" updates for the new KEK, and Canonical asks vendors to publish PK signed KEK updates on fwupd.org. Where an OEM never did, Windows logs event 1803 and Linux has nothing to install.

The OS does most of the work on most machines, but the OEM decides whether some machines can be updated at all. Inventory by make, model and firmware version. Canonical also asks vendors to keep both CA generations in db and KEK until at least 2028.

What can go wrong during the update

BitLocker recovery prompts

BitLocker with a TPM seals the volume key to boot measurements including PCR7, which reflects Secure Boot configuration. Changing db changes PCR7. Windows tries to detect this and logs event 1032 to block the update, but KB5025885 still warns "some devices may go into BitLocker recovery." Back up the recovery key first. Microsoft's event 1032 guidance suspends protection for two restarts:

manage-bde -status $env:SystemDrive                                  # confirm drive and state
manage-bde -protectors -disable $env:SystemDrive -RebootCount 2      # suspend for two restarts
manage-bde -status $env:SystemDrive                                  # after two restarts, confirm resumed

Background: where to store recovery keys and TPM only versus TPM with PIN.

TPM sealed LUKS on Linux

Red Hat says PCR7 changes after a db update, so unseal or disable sealing before rebooting and reseal afterward; its knowledge base suggests sealing temporarily to an unchanged PCR such as PCR0. Canonical warns TPM encrypted VMs may ask for a recovery key. Have the LUKS passphrase in hand before running fwupd on a TPM unlocked machine.

Firmware that rejects the update, and mixed methods

Windows logs 1795, 1802 or 1803 by failure type; on Linux, fwupd declines or a forced update bricks the board. Red Hat, Fedora and Rocky Linux all say follow vendor guidance and do not force. Microsoft also says not to mix deployment methods on one device, and its Azure page says the same for Linux.

Step by step: a fleet rollout plan

For teams that still have machines without the 2023 certificates. Microsoft recommends testing at least four devices per hardware category and allowing about 48 hours and one or more restarts per device.

Phase 0: inventory

1. List every Secure Boot machine with make, model and firmware version, and its current state from the checks above.
2. Classify: done (event 1808 or 2023 entries present), likely automatic, needs OEM firmware, cannot update.
3. Confirm the BitLocker or LUKS recovery key location for each machine you will touch.
4. List every recovery USB, ISO, PXE image and VM template with its build date.

Phase 1: Windows pilot

These commands change firmware variables. Use a pilot device you can physically reach, with its recovery key confirmed.

# Pre-check: right device, Secure Boot on, BitLocker state known
hostname
Confirm-SecureBootUEFI
manage-bde -status $env:SystemDrive

# Trigger the 2023 rollout, then run the servicing task now
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"

# Expect 0x4100, then restart and run the task again; expect 0x4000
Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Control\Secureboot -Name AvailableUpdates

Confirm UEFICA2023Status reads Updated and event 1808 appears. Microsoft says the task works in order, each step needing the last to succeed: Windows UEFI CA 2023 into db; the Option ROM and Microsoft UEFI CA 2023 if the 2011 UEFI CA is present; the 2023 KEK; then the boot manager at the next restart.

Phase 2: Windows broad rollout

Microsoft groups devices into buckets by manufacturer, motherboard and firmware version. High confidence buckets get the certificates through monthly cumulative updates by default (HighConfidenceOptOut turns it off). For the rest, Microsoft offers registry keys, WinCS for domain joined machines, and scripts through Intune or Configuration Manager; when we read the page, Group Policy support and an Intune configuration service provider were still listed as coming. One method per device.

Phase 3: Linux pilot

These commands update firmware variables. Confirm the machine, the EFI partition and any encrypted volume first, and have the passphrase ready.

hostnamectl
findmnt /boot/efi
lsblk -f                  # note any crypto_LUKS device path

fwupdmgr --version        # Canonical: 2.0.0 or later; Debian: 2.0.20 confirmed good
sudo fwupdmgr refresh
sudo fwupdmgr get-updates
sudo fwupdmgr update

Reboot and repeat the mokutil checks, then move to the dual signed shim:

sudo apt update && sudo apt install --only-upgrade shim-signed   # Debian, Ubuntu
sudo dnf upgrade shim-x64                                        # RHEL, Rocky, Fedora

Debian documents a manual db update with efivar for machines where fwupd fails. Red Hat, Fedora and Rocky Linux warn against forcing db changes outside vendor methods, and LWN reports permanent damage from forced updates. If you consider it, read Debian's page in full, back up the current db variable, and work only on a machine you can physically recover.

Phase 4: virtual machines

• KVM on RHEL: edk2-ovmf now carries both CA generations, but existing VMs keep keys in their NVRAM file. Red Hat documents resetting NVRAM on RHEL 9 and later (libvirt 8.1.0 or later). This discards enrolled keys, so confirm the VM name and back up its file under /var/lib/libvirt/qemu/nvram/ first.

virsh list --all                  # confirm the exact VM name
virsh start <vm> --reset-nvram    # discards the VM's stored UEFI variables

• Ubuntu guests: Canonical says VMs pick up the new CAs on reboot; keep edk2 or the LXD snap current.
• Azure: Microsoft says inventory Linux Trusted Launch and Confidential VMs created before April 2024, restart first, update db and KEK before shim (shim first may cause a boot failure), recreate Confidential VMs, then verify that both commands return a line:

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

Phase 5: media, then revocation

Rebuild every recovery USB, ISO, PXE image and VM template from current media. Only then consider KB5025885 Step 3 (0x80), which is irreversible under Secure Boot. Microsoft blocks it with event 1797 if the Windows UEFI CA 2023 is missing, a useful safety net but not a substitute for checking. Machines the OEM will not update become documented exceptions with a replacement date; Debian says plainly not to disable Secure Boot as the fix.

Decision table: what to do with each machine

Where Safeguard fits, and where it does not

Most of this post is outside Safeguard's scope. Safeguard does not read UEFI variables, update db, dbx or KEK, manage devices or BitLocker, or scan firmware and option ROMs. The rollout is work for your endpoint tooling, your OEMs and your distribution.

The overlap is narrow. Shim, GRUB, fwupd and edk2-ovmf are ordinary packages inside OS images, appliance images and VM templates. If you keep SBOMs for those images, "which of our images still carry a shim build that is not dual signed?" becomes a component and version lookup across projects. Safeguard can scan images, ingest SBOM files and show which projects contain a given component and version, so it helps with that one inventory question where your SBOMs list those packages. It cannot tell you what is in a machine's firmware.

Common mistakes

• Treating the expiry date as the deadline. The real deadline is the next shim or boot manager security fix.
• Updating db but not the KEK. Microsoft says both must be updated.
• Removing or revoking the 2011 UEFI CA. It still signs option ROMs and half of the dual signed shim.
• Forcing db updates the vendor does not offer. Red Hat names HP and Fujitsu; LWN reports permanent damage.
• Updating shim before db on Azure VMs. Microsoft says firmware certificates first.
• Forgetting the recovery key until the prompt appears. Escrow BitLocker and LUKS keys first.
• Keeping 2024 era recovery media after the PCA 2011 revocation and SVN update.
• Disabling Secure Boot as the fix. It removes the protection instead of fixing it.

FAQ

Did the Secure Boot certificate expiry in June 2026 stop computers from booting?

No. Microsoft and the major Linux distributions say existing signed boot loaders keep working because firmware generally does not check certificate dates. What stops is accepting new boot loaders and db and dbx updates signed under the 2023 certificates.

What expired on 19 October 2026?

The Microsoft Windows Production PCA 2011, which signed Windows Boot Manager. Its replacement is the Windows UEFI CA 2023. Current boot managers keep booting; future servicing needs the 2023 CA in db.

How do I check if my Windows PC has the 2023 Secure Boot certificates?

In elevated PowerShell, read db and KEK with Get-SecureBootUEFI and match "Windows UEFI CA 2023" and "KEK 2K CA 2023", then check UEFICA2023Status in the SecureBoot Servicing registry key. Event 1808 means done.

How do I check Secure Boot certificates on Linux?

Use mokutil to list db and KEK and look for Microsoft UEFI CA 2023 and Microsoft Corporation KEK 2K CA 2023. Then run pesign against your shim to see whether it carries both signatures.

What is a dual signed shim?

A shim with two Microsoft signatures, one from the 2011 UEFI CA and one from the 2023 UEFI CA, so it boots on machines trusting either. Debian, RHEL, Fedora Rawhide and Rocky Linux ship them.

Will Linux stop installing updates if my PC lacks the 2023 certificate?

It may. Canonical says Ubuntu releases and stable updates from Q4 2026 may need the 2023 CA, and without it package management can fail. Red Hat says 2023 only shims will not boot without that certificate in db.

Why did BitLocker ask for a recovery key after the Secure Boot update?

Changing db or the boot manager changes the TPM's PCR7 measurement. Windows tries to block the update with event 1032 when this is likely. Suspend BitLocker for two restarts before applying the update manually.

Should I remove the old 2011 certificates from my firmware?

No. The 2011 UEFI CA still signs option ROMs on existing hardware and half of the dual signed shim. The only intended removal is KB5025885's revocation of the Windows Production PCA 2011, after media and boot managers are updated.

My laptop maker has no firmware update. What now?

If Windows logs event 1803, the OEM never supplied a PK signed KEK update and only the OEM can fix it. Do not force updates. Record the machine as an exception with a replacement date and keep Secure Boot on.

Fix it without waiting for upstream

A Secure Boot rollout lives in firmware and boot loaders that Safeguard does not patch, so this block is about the rest of the rebuild rather than the certificates. When a machine, VM template or golden image is rebuilt on new media after a CA change, it pulls packages and container images again, and those open source dependencies are where the next fix still has to land.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

None of these demos touch firmware or Secure Boot. They show the software side of a rebuild.

This is a real Safeguard CLI session: install, open the interactive terminal, ask it to fix a lodash CVE, and approve each command as it edits package.json and runs npm install and npm test, with nothing pushed. On a developer machine rebuilt after a firmware or Secure Boot change, the same flow rescans the projects you cloned back.

Click through it at your own pace, or open it full screen.

This one sets up the local runner on your own machine, approves it with a device code and scans from the terminal. Teams that build golden images and VM templates on internal hosts can scan them where they are built, including the boot related packages their SBOMs list.

Click through it at your own pace, or open it full screen.

This one connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude may use. During a rollout, it lets an assistant answer "which of our images carry this package version" from your own Safeguard data. It still cannot see firmware.

Click through it at your own pace, or open it full screen.

To try it on your own projects, get the apps from safeguard.sh/download and read the CLI documentation.

Quick check

Sources

• Windows Secure Boot certificate expiration and CA updates, Microsoft Support
• KB5025885: Windows Boot Manager revocations for CVE-2023-24932, Microsoft Support
• Windows Secure Boot Key Creation and Management Guidance, Microsoft Learn
• Registry key updates for Secure Boot: Windows devices with IT managed updates, Microsoft Support
• Secure Boot DB and DBX variable update events (KB5016061), Microsoft Support
• Windows devices for businesses and organizations with IT managed updates (KB5062713), Microsoft Support
• Secure Boot certificate updates for Linux on Azure virtual machines, Microsoft Support
• Get-SecureBootUEFI, Microsoft Learn
• microsoft/secureboot_objects, GitHub
• SecureBoot, Debian Wiki
• SecureBoot/CAChanges, Debian Wiki
• Secure Boot and Microsoft CA Rollover, Steve McIntyre (22 May 2026)
• SBAT.md, rhboot/shim on GitHub
• Microsoft UEFI CA rotation: what it means for Ubuntu users and vendors, Ubuntu Discourse
• Expiration of Secure Boot signing certificates in 2026, Red Hat blog
• Red Hat knowledge base article 7128933
• Expiration of Microsoft Secure Boot keys, Fedora Magazine
• Secure Boot CA and KEK transition, Rocky Linux (2 June 2026)
• Secure Boot certificate expiration is here, LWN.net (1 July 2026)

Last reviewed: 23 October 2026. Microsoft and the distributions are still updating their guidance; check the linked pages for the latest status, especially the KB5025885 enforcement date.