Why Firmware Below the OS Goes Unpatched, and How to Fix It

Firmware below the operating system goes unpatched because a fix has to travel through a chain of vendors before it reaches your machine, often has no automatic delivery path, needs a reboot, can brick the device if it fails, and stops arriving entirely once the hardware leaves support. Most teams also never inventory it, so nobody notices the gap. The fix is a firmware inventory per operating system, a short list of advisory feeds, and a written firmware patch SLA.

Your operating system probably patches itself every month. The UEFI firmware that starts it, the embedded controller that runs the keyboard and battery, the baseboard management controller (BMC) on a server, the SSD controller, the network card and the Thunderbolt or USB4 controller all run their own code, and almost none of it follows that monthly rhythm. This post explains why, using two dated disclosures, LogoFAIL and PKfail, as examples, and then walks through how to inventory firmware versions on Windows, macOS, Linux and servers, apply updates without bricking anything, track advisories, and set a firmware patch SLA you can actually meet.

Key takeaways

• The supply chain is long. A UEFI fix starts with a silicon vendor or independent BIOS vendor (IBV), moves to the board maker (ODM) and the brand (OEM), and only then ships to you.
• Support ends quietly. When a model reaches end of support, firmware fixes stop, even for flaws disclosed later. CERT/CC's PKfail note lists one vendor's affected products simply as "no longer supported."
• Delivery is uneven. Windows ships OEM firmware as driver packages, Linux uses fwupd and the LVFS, and Macs get firmware with macOS. BMCs and many adapters still need vendor tools.
• Reboots and bricking fear delay updates. Firmware updates usually apply at restart, can fail on low battery or power loss, and many devices block rollback to older versions by design.
• Inventory is the first control. You cannot set an SLA for versions you have never collected. Every major OS exposes firmware versions through built in commands.
• Write the SLA down. Tie deadlines to exposure and exploitation, not just CVSS, and add an explicit rule for hardware that will never get a fix.

What counts as firmware below the OS

NIST SP 800-193, Platform Firmware Resiliency Guidelines, lists the devices on a typical x86 platform that carry their own mutable firmware and are critical to secure operation. It is a useful map, because most inventories stop at the first item.

NIST is explicit that this list is not exhaustive and that platform vendors must consider other devices. For a security team, the practical lesson is that "the BIOS version" is one row of eight or more.

For a broader history of how these parts came to sit on a modern board, see our companion post on motherboard evolution from chipsets and BIOS to UEFI, TPM and BMC.

Why firmware patching lags OS patching

The vendor chain: silicon vendor to IBV to ODM to OEM

An operating system vendor writes, builds, signs and ships its own updates. Firmware does not work that way. The UEFI code on most PCs and servers starts as reference code from a chip vendor and a core firmware product from an independent BIOS vendor. A board maker customises it, adds platform drivers and its own settings, and an OEM brands, validates and ships it. Each party has its own release schedule and its own support matrix.

CISA's August 2023 call to action, "A Call to Action: Bolster UEFI Cybersecurity Now," written by Jonathan Spring and Sandra Radesky, frames this as a maturity problem across supply chain stakeholders. It asks for product security incident response teams (PSIRTs) that connect UEFI development, quality assurance and update distribution, and says traditional software integration practices have not been applied to UEFI. In plain terms: the fix often exists upstream well before the version you can install exists.

The two disclosures below show what that looks like in practice.

LogoFAIL (December 2023). CERT/CC's vulnerability note VU#811862 records that most vendors were notified on 11 July 2023 and the issue went public on 6 December 2023. The flaws sat in image parsing libraries that UEFI firmware uses to show a customisable boot logo, code that runs with high privilege early in boot. The researchers who disclosed it reported vulnerable parsers across many OEMs, on both x86 and ARM. One IBV's advisory, Insyde's INSYDE-SA-2023053 for CVE-2023-40238, was published the same day and lists fixed versions per firmware kernel line (for example 05.28.47 for kernel 5.2 and 05.60.47 for kernel 5.6). Those are IBV versions. An end user never installs them directly. They wait for their OEM to pull the fix into a model specific release, and CERT/CC's vendor table still lists several large OEMs with no statement.

PKfail (July 2024). CERT/CC's note VU#455367 (CVE-2024-8105) went public on 25 July 2024. Untrusted test Platform Keys, meant only for development, ended up in production firmware. Because the same test keys were reused across vendors and product lines, affected firmware spans many years of shipped devices. Fixing it means each OEM shipping firmware with its own Platform Key; the OS layer cannot fix it.

The 2026 Secure Boot certificate rotation is a current example of the same chain. Microsoft can only push new db entries to machines that trust a newer KEK, and devices whose OEM never supplied a KEK update signed with the device's own Platform Key need a firmware update first. Our post on Secure Boot certificate rotation in 2026: what breaks and what to do covers that in detail.

End of support

Hardware vendors publish support dates, but few people read them, and firmware support often ends years before the hardware stops working. A flaw disclosed after that date may never be fixed.

PKfail shows this directly. In CERT/CC's vendor table, Intel is listed as affected with the note that the affected products are no longer supported. The machines still boot and still run current operating systems. The firmware simply will not change again.

On Macs, Apple's Platform Security guide explains that personalised software updates cover boot components such as iBoot. Firmware therefore follows the macOS versions a Mac can install, and a Mac that cannot install a current release stops receiving it.

No automatic update path, or one that nobody turned on

The LVFS project documentation describes the historic Linux problem bluntly: users did not know their exact hardware or firmware version, updates were scattered across many vendor websites, flashing tools were Windows only, and as a result customers stayed on insecure firmware even when fixes existed. The LVFS and the fwupd daemon fixed much of that. The project says more than one hundred vendors use the LVFS and that millions of devices are updated every month. Coverage still depends on each vendor choosing to upload.

On Windows, Microsoft's UEFI firmware update platform lets OEMs ship system and device firmware as driver packages that Windows hands to firmware through the UEFI UpdateCapsule service. That is a real automatic path, but only for firmware the OEM publishes that way. Microsoft's own guide says UEFI capsules should not be used for removable peripherals, because the device must be present at reboot. Docks, external drives and many add in cards stay with vendor tools.

BMCs are the hardest case, updated through vendor utilities, web consoles or the DMTF Redfish UpdateService. Redfish's own schema describes the firmware inventory as software "that does not execute within a host operating system," and notes it is "generally updated using platform-specific methods or utilities." Nothing in the host OS patch cycle touches it.

Reboots and maintenance windows

System firmware updates almost always apply at restart. The LVFS documentation notes that for UEFI updates, fwupd stages the capsule on the EFI System Partition and the update runs at the next reboot through UpdateCapsule, while many USB and Thunderbolt devices can update without one. On servers, a BMC update may restart the BMC, and a host firmware update needs the host down. That pushes firmware into the same maintenance windows that teams already guard closely, and it competes with every other change that needs downtime.

On encrypted laptops, changed firmware changes TPM measurements, so BitLocker can ask for the recovery key unless protection is suspended first; see our post on Windows boot problems, BitLocker recovery and boot loops. A help desk burned by a wave of recovery key requests slows the next rollout.

Fear of bricking, and rollback that is blocked on purpose

A failed OS update usually rolls back. A failed firmware flash can leave a board that does not start. Microsoft's ESRT definition, which describes how firmware reports update results to Windows, includes specific failure statuses for "Power event, AC not connected" and "Power event, insufficient battery." Those exist because power loss during a flash is a real failure mode.

Rollback is also limited by design. NIST SP 800-147 says the authenticated update mechanism should prevent unauthorised rollback to an earlier authentic version with a known security weakness, for example by checking that the new version number is larger than the installed one. Microsoft's ESRT definition has a matching field, Lowest Supported Firmware Version, and says that when a release contains a security fix, the lowest supported version should equal the current version. Apple's guide likewise says older firmware from one device cannot be copied to another. This is correct security design, and it means that if a new firmware breaks something, you often cannot go back. Operations teams know this, and it makes them cautious.

Firmware is invisible to most inventories and scanners

Firmware rarely appears in package inventories, image scans or OS patch reports. CISA's call to action asks system owners to audit, manage and update UEFI components like any other acquired software, including through an SBOM, and asks operational teams to collect UEFI event logs and relay them to the OS or endpoint tools. Most organisations still cannot answer "which firmware versions do we run?"

Advisories are fragmented

Firmware fixes are announced by silicon vendors, IBVs, OEMs, BMC, drive and NIC vendors, each with its own page and version numbers. LogoFAIL alone drew separate statements from AMI, Insyde, Phoenix and many OEMs, and an IBV build number rarely maps cleanly to an OEM BIOS version.

What NIST and CISA say good looks like

NIST SP 800-147 (April 2011) sets guidelines for four BIOS features: an authenticated update mechanism using digital signatures, an optional secure local update that requires physical presence, integrity protection outside the update process, and non-bypassability. Its management practices start with a baseline of approved BIOS versions and settings and monitoring for unexpected changes, and it lets organisations authorise specific images by countersigning them with their own key.

NIST SP 800-193 (May 2018) extends that from the BIOS to all platform firmware and critical data, organised around three principles: protect firmware against unauthorised changes, detect unauthorised changes that occur, and recover rapidly and securely. Its device list, summarised in the table above, is the best single reference for scoping a firmware inventory.

CISA (August 2023) adds the operational side: treat UEFI as acquired software with SBOMs, collect firmware event logs, fund PSIRTs, and give owners reliable update distribution so they are not left to manage signing key revocations by hand. Its closing line is a fair summary for anyone writing a firmware policy: "the work must start today."

NIST 800-193 is also meant to guide procurement: asking how long firmware will be supported, and whether updates are authenticated and recoverable, costs nothing before purchase.

How each platform delivers firmware updates

How to inventory firmware versions on each OS

The goal is one row per device per component: hostname, component, vendor, model, current version, and date collected. Start with system firmware and BMCs, then add drives, NICs and docks. Every command below only reads information.

Windows

The WMI class Win32_BIOS exposes the system firmware vendor, the SMBIOS BIOS version and release date, and, on Windows 10 and later, the embedded controller major and minor release. Microsoft's ESRT documentation explains that each firmware resource in the ESRT is surfaced as a device instance with a hardware ID, which is why system and device firmware appear as devices in the Firmware class.

# System firmware and embedded controller versions (read only)
Get-CimInstance -ClassName Win32_BIOS |
  Select-Object Manufacturer, SMBIOSBIOSVersion, ReleaseDate,
                SystemBiosMajorVersion, SystemBiosMinorVersion,
                EmbeddedControllerMajorVersion, EmbeddedControllerMinorVersion

# Firmware resources that Windows can service through UEFI capsules
Get-CimInstance -ClassName Win32_PnPSignedDriver |
  Where-Object { $_.DeviceClass -eq 'FIRMWARE' } |
  Select-Object DeviceName, DriverVersion, DriverDate, HardWareID

# Drive firmware revisions
Get-PhysicalDisk | Select-Object FriendlyName, SerialNumber, FirmwareVersion

# Model, so you can match OEM advisories
Get-CimInstance -ClassName Win32_ComputerSystem | Select-Object Manufacturer, Model

To collect this across a fleet, run the same queries through whatever tool already gathers your software inventory and write one CSV per host.

Linux

fwupd gives the richest view, because its plugins enumerate system firmware, Thunderbolt controllers, docks, NVMe drives and many USB devices. Its documentation recommends the JSON output for anything you parse, since terminal output can change between versions.

# Every device fwupd knows about, with current versions (read only)
fwupdmgr get-devices --json > "fw-$(hostname).json"

# Host Security ID: firmware protection checks such as SPI write protection
fwupdmgr security

# System firmware version and date from SMBIOS
cat /sys/class/dmi/id/bios_vendor /sys/class/dmi/id/bios_version /sys/class/dmi/id/bios_date
cat /sys/class/dmi/id/sys_vendor /sys/class/dmi/id/product_name

The kernel also exposes the UEFI ESRT directly. Each entry has a type (1 for system firmware, 2 for device firmware), the installed version, the lowest version it can be rolled back to, and the result of the last update attempt.

for e in /sys/firmware/efi/esrt/entries/entry*; do
  printf '%s type=%s version=%s lowest=%s last_status=%s\n' \
    "$(cat "$e/fw_class")" "$(cat "$e/fw_type")" "$(cat "$e/fw_version")" \
    "$(cat "$e/lowest_supported_fw_version")" "$(cat "$e/last_attempt_status")"
done

A last attempt status of 0 means success. Anything else means the last update did not complete, which is worth a ticket on its own.

For drives, NICs and BMCs that fwupd does not cover:

# NVMe firmware revision (FW Rev column)
sudo nvme list

# NIC driver and firmware version
ethtool -i eth0

# BMC firmware revision from the host, on servers with IPMI
sudo ipmitool mc info

macOS

On a Mac, firmware versions are reported through System Information and follow the installed macOS release.

# Model identifier and System Firmware Version
system_profiler SPHardwareDataType

# Internal NVMe drive details, including revision
system_profiler SPNVMeDataType

# What macOS updates are pending, and what has been installed
softwareupdate --list
softwareupdate --history

For a Mac fleet, also track whether each Mac can still install the current macOS major release.

Servers and BMCs

For servers, collect firmware out of band from the BMC as well as from the host. The DMTF Redfish standard defines an UpdateService with a FirmwareInventory collection for "platform firmware" that does not run in the host OS. On a BMC that supports Redfish, you can list it like this, using a read only account and a verified certificate:

# List firmware components the BMC knows about (read only)
curl -s -u readonly-user https://bmc01.example.internal/redfish/v1/UpdateService/FirmwareInventory

# Then fetch each member for its Version field
curl -s -u readonly-user https://bmc01.example.internal/redfish/v1/UpdateService/FirmwareInventory/BMC

Member names vary by vendor, so script against the Members list rather than hard coding them. BMC management interfaces should sit on an isolated management network; never expose them to make inventory easier.

Put it in one table

Normalise everything to one schema with history: host, component class, vendor, model, version exactly as reported, support status, collection date and last update status. Advisories are written per model, so model is the field you will join on most.

How to apply firmware updates without bricking anything

Flashing firmware writes to non-volatile memory on a device. A wrong image, an interrupted write or a power loss can leave the device unusable. Before every update block below, confirm the target device, its exact model and its current version, and make sure the machine is on mains power.

Before you start: checks that apply everywhere

1. Confirm the model and current version with the inventory commands above. Check that the update is published for that exact model.
2. Read the release notes for prerequisites, such as an intermediate version that must be installed first or an EC update bundled with the BIOS.
3. Connect AC power. On laptops, also keep the battery above the level the vendor requires.
4. On BitLocker protected Windows devices, suspend protection for one restart so the changed measurements do not trigger recovery. Use your OEM's instructions or Suspend-BitLocker with a reboot count of 1, and confirm you have the recovery key escrowed first.
5. Note that rollback may be blocked. Pilot on a small ring of the same model before the whole fleet.

Linux with fwupd

Warning: this flashes firmware. Run fwupdmgr get-devices first and confirm the device ID and name match the device you intend to update.

# 1. Refresh metadata from the LVFS
fwupdmgr refresh

# 2. Review what is available, per device
fwupdmgr get-updates

# 3. Check the device list once more and note the device ID you expect to change
fwupdmgr get-devices

# 4. Apply. UEFI capsules are staged and run at the next reboot
fwupdmgr update

# 5. After reboot, confirm the version and the recorded result
fwupdmgr get-history

CERT/CC's PKfail note gives exactly this route, alongside Windows OEM update mechanisms, as a way to apply vendor firmware fixes.

Windows

Firmware published by your OEM through the UEFI firmware update platform installs like a driver and applies at restart. Check Windows Update, including optional driver updates, and your OEM's update tool. In managed fleets, approve firmware driver updates in rings exactly as you approve quality updates.

Warning: OEM flashing utilities write directly to system flash. Before you run one, confirm the model in Win32_ComputerSystem matches the package, the current version in Win32_BIOS is older than the package, and the device is on AC power.

After the restart, rerun the Win32_BIOS query and confirm the new version. If the ESRT reports a nonzero last attempt status, the update did not apply.

macOS

There is no separate firmware download for a Mac. Install the latest macOS update the Mac supports, from System Settings or with softwareupdate, on mains power, and the firmware travels with it.

BMCs and adapters

Warning: a BMC update can restart the BMC and drop remote console access, and some host firmware updates staged through the BMC power cycle the host. Confirm the server's serial number and model in the BMC inventory before uploading any image, and schedule a window.

Use the vendor's documented method (web console, vendor tool or Redfish UpdateService), update the BMC first if the vendor requires it, and re-read the FirmwareInventory afterwards.

How to track firmware advisories

Build a short feed list per model family, not per CVE. For most teams it looks like this:

1. OEM security advisory pages and PSIRT mailing lists, where the version you can install appears.
2. BMC, NIC, storage and dock vendors, often owned by different teams.
3. IBV and silicon vendor advisories, which arrive first and tell you to chase your OEM.
4. CERT/CC vulnerability notes. VU#811862 and VU#455367 show how CERT/CC tracks each vendor's status, including "unknown," which is a signal to chase your vendor.
5. LVFS metadata through fwupd. fwupdmgr get-updates on a representative machine of each model is a cheap check that new firmware exists.
6. Your own inventory diff. A weekly report of "models with a newer firmware available" is often more useful than any feed.

When an advisory names only an IBV version, open a ticket with the OEM and record the date; that gap is your real exposure and useful evidence for the next purchase.

How to set a firmware patch SLA

An SLA for firmware has to be different from one for OS patches, because the clock depends on when your vendor ships, not when the CVE appears. Write it with three parts: when the clock starts, how long you have, and what happens when no fix exists.

When the clock starts. Start it when a fix is published for your exact model, not at CVE publication. Separately, track the time from the upstream advisory to the OEM release as a vendor metric.

How long you have. Base it on exposure and exploitation, not only severity. The table below is a starting point we suggest, not a standard. Adjust it to your change windows.

What happens when there is no fix. Every firmware SLA needs an end of support rule. Options include compensating controls (restricting who can write to the EFI System Partition, keeping BMCs on an isolated network, enforcing Secure Boot and boot measurements), moving the device to lower risk duties, or replacing it by a set date. Record the decision and an owner, and review it each quarter.

A simple policy fragment that teams can paste into their patch standard:

firmware_patch_policy:
  scope:
    - system_firmware      # UEFI or BIOS, including embedded controller
    - bmc
    - storage_firmware
    - nic_firmware
    - docks_and_thunderbolt
  inventory: weekly
  clock_starts: fix_published_for_exact_model
  targets_days:
    known_exploited_or_remote_mgmt: 7
    boot_chain_mobile: 30
    boot_chain_servers_and_build_hosts: 30
    local_only_not_exploited: 90
  rollout_rings: [pilot, 5_percent, all]
  no_fix_available:
    action: compensating_controls_or_replace
    review: quarterly
    owner_required: true
  vendor_metric: days_from_upstream_advisory_to_oem_release

Report against it like any other SLA: percentage of devices within target per component class, and a list of models on the no fix path.

Decision table: what to do in each situation

Where Safeguard fits, honestly

Safeguard is a software supply chain security platform. It does not scan firmware, flash firmware, manage devices or read BMC inventories, and nothing in the inventory or update steps above depends on it. The overlap is narrower. The reasons firmware lags (a long upstream chain, fixes that exist upstream before they reach you, no clear inventory, and products that stop being supported) are the same reasons open source dependencies lag in the software you build. Safeguard addresses that software side: it scans repositories, container images and SBOM files, shows which projects contain a given component and version, matches them against vulnerability databases with reachability analysis, and can open fix pull requests when a safe version exists. The same inventory, SLA and ring discipline you apply to firmware works for those dependencies too.

Common mistakes

• Treating "BIOS version" as the whole inventory. NIST SP 800-193 lists embedded controllers, BMCs, NICs, GPUs, storage controllers and TPMs as well. Collect each class.
• Starting the SLA clock at CVE publication. You cannot install an IBV fix. Start the clock when your OEM ships for your model, and track the upstream gap separately.
• Assuming a reimage or factory reset updates firmware. It does not. System firmware, EC and drive firmware stay at whatever version they had.
• Ignoring failed updates. A nonzero ESRT last attempt status means the update never landed, even if the deployment tool reported success.
• Updating BitLocker laptops without suspending protection. That produces a wave of recovery key requests and makes the next rollout harder to approve.
• Rolling out to the whole fleet at once. Rollback is often blocked by design. Use rings.
• Exposing BMCs to make management easier. Out of band interfaces belong on an isolated management network.
• Treating "vendor status unknown" as "not affected." In CERT/CC notes, unknown means the vendor has not said. Ask.

FAQ

Why is firmware not updated automatically like Windows or macOS?

Because the code passes through several companies and each device class has its own channel. Windows, Linux and macOS have automatic paths for firmware vendors publish to them, but BMCs, many adapters and older models still need vendor tools.

How do I check my BIOS or UEFI version?

On Windows, run Get-CimInstance Win32_BIOS in PowerShell and read SMBIOSBIOSVersion and ReleaseDate. On Linux, read /sys/class/dmi/id/bios_version or run fwupdmgr get-devices. On a Mac, run system_profiler SPHardwareDataType and read the System Firmware Version line.

Is it safe to update BIOS firmware?

Generally yes, if you follow the vendor's procedure: correct model, AC power, BitLocker suspended for one restart, and no interruption. Pilot on one machine of each model first.

Can I roll back a firmware update if something breaks?

Often not. NIST SP 800-147 recommends that authenticated update mechanisms block rollback to vulnerable versions, and the UEFI ESRT includes a lowest supported version for that purpose. Some vendors allow authorised rollback in limited cases. Assume you cannot and test first.

Does reinstalling the operating system update firmware?

No. Firmware lives in flash on the board and devices, not on the system disk, so a reinstall, reimage or factory reset leaves it unchanged. On a Mac, only a newer macOS can bring new firmware.

How often should firmware be updated?

Check monthly through your inventory, apply routine fixes quarterly, and move faster for exploited or remotely reachable flaws, as in the SLA table above.

What happens when my hardware stops getting firmware updates?

New firmware flaws will not be fixed. Apply compensating controls, move the device to lower risk duties, and set a replacement date.

Do I need an SBOM for firmware?

CISA's 2023 call to action asks owners to manage UEFI components like other acquired software, including through an SBOM. Few vendors provide firmware SBOMs today, so ask for them in procurement and use your version inventory in the meantime.

Fix it without waiting for upstream

Firmware itself has to come from your hardware vendor, so nothing in this section patches a BIOS, BMC or drive. It applies to the other half of the same problem: the open source dependencies and container images in the software you build, which lag behind upstream fixes for many of the same reasons firmware does.

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 inventory or update firmware. They show the software side of the same discipline: knowing which versions you run and moving to fixed ones quickly. If you want to try the CLI yourself, download it from https://safeguard.sh/download and read the setup guide at https://docs.safeguard.sh/docs/cli .

This first demo is a real CLI session. After install, safeguard opens the interactive terminal, you ask it to fix the lodash CVE in a repo, and it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. It is the dependency equivalent of the firmware flow above: confirm the version, apply the fix in a controlled way, and verify before anything ships.

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

The second demo sets up the Safeguard runner on your own machine, approves it with its device code, and then scans from the terminal. Teams that keep build hosts on isolated networks, the same hosts they schedule firmware windows for, can use this to keep dependency scanning local. Our post on how the local runner and offline mode work covers the details.

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

The third demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which tools Claude can use. If your team already uses Claude for patch planning, this is how it can read your real dependency and vulnerability data while you decide exactly what it is allowed to touch.

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

Quick check

Sources

• CISA: A Call to Action: Bolster UEFI Cybersecurity Now (August 2023)
• NIST SP 800-193: Platform Firmware Resiliency Guidelines
• NIST SP 800-193 full text (PDF)
• NIST SP 800-147: BIOS Protection Guidelines
• NIST SP 800-147 full text (PDF)
• CERT/CC VU#811862: LogoFAIL image parsing vulnerabilities in UEFI firmware
• CERT/CC VU#455367: PKfail untrusted Platform Keys
• Insyde INSYDE-SA-2023053 (CVE-2023-40238)
• LVFS documentation: introduction
• fwupd: fwupdmgr command line reference
• fwupd: Host Security ID specification
• Microsoft Learn: Windows UEFI firmware update platform
• Microsoft Learn: ESRT table definition
• Microsoft Learn: Win32_BIOS class
• Linux kernel ABI: sysfs firmware EFI ESRT
• Apple Platform Security: Secure software updates
• DMTF Redfish UpdateService schema
• ethtool manual page

Last reviewed: 23 October 2026.