Motherboard Evolution: Chipsets, BIOS to UEFI, TPM and BMCs

The motherboard has changed from a passive carrier of chips into a computer platform with its own firmware, its own trust anchors and, on servers, its own always-on management computer. Over thirty years the board moved from AT to ATX, folded the northbridge into the CPU, swapped BIOS for UEFI, added Secure Boot and the TPM, and gained a BMC that now speaks Redfish. Every one of those layers is software you have to inventory and update.

This post walks through that history with a security lens. It covers the physical board (form factors, chipsets, power delivery), the firmware (BIOS, EFI, UEFI, Secure Boot), the trust hardware (TPM 1.2 and 2.0), the server management plane (IPMI and Redfish), the incidents that shaped each layer, what NIST asks for, and what a usable firmware inventory records. Dates come from the primary documents where we could reach them, and we say plainly where we could not.

Key takeaways

• ATX has lasted because it standardised the box, not just the board. Intel published ATX 1.0 in July 1995, and microATX (1997) and Mini-ITX (2001) kept the same mounting and I/O ideas at smaller sizes, so cases, power supplies and boards stayed interchangeable.
• The northbridge did not disappear, it moved into the CPU. From Intel's Nehalem generation onward the memory controller and main PCI Express lanes sit on the processor, and a single Platform Controller Hub (PCH) handles the rest. On Intel boards the PCH also hosts the Management Engine and the firmware flash.
• UEFI replaced BIOS through a standards body. Intel's EFI work began in 1998, Intel handed the specification to the Unified EFI Forum in 2005, and UEFI 2.3.1 (2011) introduced Secure Boot.
• Secure Boot verifies signatures, not intent. It checks boot components against the db and dbx databases. It does not stop a signed but vulnerable boot loader that has not been revoked, a firmware shipping with test keys, or flaws in code that runs before verification.
• TPM 2.0 replaced 1.2 mainly for cryptographic agility. TPM 1.2 allows only RSA and SHA-1. TPM 2.0 became ISO/IEC 11889:2015, and Windows 11 requires it.
• BMCs are a second computer on the board. IPMI (1998) gave way, in practice, to DMTF's Redfish (1.0 in August 2015), a RESTful API. The BMC needs its own patching, network isolation and credential policy.
• The 2026 Secure Boot certificate rotation is happening now. Microsoft's 2011 Secure Boot certificates expire between June and October 2026. Devices keep booting, but those without the 2023 certificates stop receiving new boot level protections.
• A firmware inventory is the practical answer. Record board, firmware vendor and version, Secure Boot state and key owner, TPM version and firmware, BMC firmware, and the vendor SBOM where one exists.

Timeline: the board as a platform

The table below collects the dated milestones used in this post. Where the only source we could reach was a secondary reference, the Sources column says so.

How did form factors evolve, and why does ATX still dominate?

Before ATX, most PCs used boards descended from IBM's AT design. Ports hung off the board on ribbon cables to brackets on the case, the power supply fed the board through two similar looking connectors that could be swapped by mistake, and the power switch physically cut mains power.

Intel published ATX 1.0 in July 1995. It changed three things that still matter:

• A rear I/O area. Instead of fixed ports and flying leads, ATX defines a rectangle at the back of the board where the maker places its own port layout, covered by an I/O shield. That let boards integrate more controllers without new case designs.
• Soft power. The case button signals the power supply instead of switching mains, and a 5 V standby rail keeps the power on circuitry alive. That made OS controlled shutdown, wake on LAN and, later, always-on management possible.
• A keyed power connector. One connector that cannot be fitted backwards, and a direct 3.3 V supply.

Smaller variants followed the same mounting logic. microATX arrived in 1997 at 244 by 244 mm, so it fits any ATX case. VIA introduced Mini-ITX in 2001 at 170 by 170 mm, originally for quiet home theatre and fanless systems. A full ATX board is 305 by 244 mm.

Power delivery evolved within the standard. ATX12V 2.0 in February 2003 grew the main connector from 20 to 24 pins and moved most power onto the 12 V rails, because CPUs and graphics cards were drawing far more current. In 2019 Intel published ATX12VO, where the power supply provides only 12 V and the motherboard does its own conversion for 3.3 V and 5 V.

ATX dominates because it is an ecosystem contract. A case, a power supply, a board and a cooler from different makers fit together, which keeps prices down and lets organisations repair and upgrade. Servers and laptops go their own way with proprietary boards, but the desktop and workstation market has kept ATX compatible sizes for three decades.

The security relevance is indirect but real. Small form factor boards end up inside appliances, kiosks and edge gateways, which means the same firmware families and the same firmware flaws show up in places nobody thinks of as a PC.

Where did the northbridge go, and what is a PCH?

For most of the 1990s and 2000s a PC chipset had two chips. The northbridge sat next to the CPU and handled the fast work: the memory controller and the graphics slot. The southbridge handled slower I/O: storage, USB, audio, legacy buses and the firmware flash chip.

That split made sense when the front side bus between CPU and northbridge was the bottleneck worth designing around. As memory bandwidth and latency became the limiting factor, the memory controller moved onto the processor. The move of northbridge functions into the CPU began with Intel's Nehalem generation, where the processor gained a "system agent" containing the memory controller and the main PCI Express lanes.

What remained was folded into one chip. Intel's Platform Controller Hub debuted in 2009 with the 5 Series chipsets (the first PCH was codenamed Ibex Peak). The PCH connects to the CPU over the Direct Media Interface (DMI) and handles clocking, all traditional southbridge functions, the nonvolatile storage that holds the BIOS, and, from that generation, the Intel Management Engine. AMD's equivalent was the Fusion Controller Hub, and since the Zen generation in 2017 AMD simply calls it the chipset.

Why this matters for security:

• The chipset hosts its own firmware. On Intel platforms the PCH runs the Management Engine, a separate processor with its own firmware that starts before the main CPU. That firmware is part of the platform image and receives its own security updates.
• The flash chip is shared. The SPI flash attached to the chipset holds UEFI, the ME region and configuration. Its write protection settings are one of the first things firmware assessment tools check.
• Fewer chips, more integration. Integration reduced the physical attack surface on the board but concentrated trust in a smaller number of firmware blobs that the board maker does not write.

What do VRMs do, and why do they matter for stability?

A voltage regulator module (VRM) converts the 12 V supplied by the power supply into the low, precisely controlled voltages a CPU, memory and chipset need. Modern CPUs change their current draw very quickly as cores wake and sleep, so the VRM is a multi phase switching regulator: several phases share the load and take turns, which spreads heat and smooths the output.

When a VRM is undersized or overheats, the symptoms look like software problems: random reboots under load, throttling, memory errors, or a machine that fails only during long builds. That is the stability angle. There is also a narrower security angle. Firmware and the OS can ask the regulator for different voltages and frequencies, which means the settings that control power delivery are themselves part of the platform configuration that firmware should lock down. If software can push a CPU outside its safe operating envelope, faults stop being random. Treat overclocking and undervolting controls on production machines as settings to disable or restrict, not tuning knobs.

For buyers, the practical rule is simple. Match the board's power delivery to the CPU's sustained power, check that VRM cooling has airflow in the case you plan to use, and treat recurring "random" crashes under load as a hardware investigation before you reinstall anything.

How did BIOS become UEFI, and who runs the UEFI Forum?

The PC BIOS dates from the original IBM PC. It ran in 16 bit real mode, booted from the first sector of a disk using the master boot record, and offered a small set of interrupt services to the OS loader. Option ROMs on add-in cards extended it. It was never designed to authenticate anything.

Intel ran into BIOS limits on its Itanium servers and started the Intel Boot Initiative in 1998, later renamed the Extensible Firmware Interface. HP's Itanium 2 systems shipped EFI 1.10 in 2002, and Intel released an open source implementation called Tiano in 2004. In July 2005 Intel stopped developing EFI at version 1.10 and handed the specification to the Unified EFI Forum, an industry body that has developed it as UEFI ever since. UEFI 2.0 arrived on 31 January 2006 with cryptography and security features, UEFI 2.3.1 on 6 April 2011 added Secure Boot and ARM support, and UEFI 2.11 was published on 16 December 2024. The UEFI Forum also maintains the ACPI and Platform Initialization specifications.

The transition took a long time because UEFI firmware shipped with a Compatibility Support Module (CSM) that emulated the old BIOS. In 2017 Intel announced it would phase out CSM on client platforms by 2020, and in 2023 it announced the same for servers by 2024. Microsoft notes that TPM 2.0 is not supported in Legacy and CSM modes, and that changing an installed system from legacy to UEFI requires converting the disk from MBR to GPT first.

We could not fetch uefi.org directly (the site blocks scripted clients), so the dates in this section come from a secondary reference and from Microsoft's documentation that cites UEFI 2.3.1. Check the UEFI Forum's specifications page for the current revision before quoting a version number in procurement documents.

BIOS and UEFI compared

What does Secure Boot verify, and what does it not?

Microsoft's OEM guidance describes the mechanism clearly. When the PC starts, the firmware checks the signature of each piece of boot software, including UEFI firmware drivers (option ROMs), EFI applications and the operating system loader. If the signatures are valid, the PC boots and hands control to the OS.

The trust comes from four stores kept in firmware nonvolatile memory:

• PK (Platform Key). One key, usually owned by the OEM. It signs updates to the KEK and can turn Secure Boot off.
• KEK (Key Exchange Key database). Keys allowed to update db and dbx. Microsoft requires its key to be in the KEK so it can add new loaders or revoke bad ones later.
• db (signature database). Certificates and hashes of loaders and drivers that may run.
• dbx (revoked signatures database). Items that may no longer run. If an image appears in both db and dbx, dbx wins.

Microsoft's requirements also specify that firmware components be signed with at least RSA 2048 and SHA 256, that the platform protect against firmware rollback, and that secure variable storage be isolated from the running OS.

What Secure Boot does not do:

• It does not block a signed loader that is vulnerable but not yet revoked. BlackLotus worked precisely because affected signed binaries had not been added to dbx, even though Microsoft had fixed the underlying flaw in January 2022.
• It does not protect you from bad keys. If the PK is a widely shared test key, anyone with that key's private half can sign boot code that the firmware accepts. That is PKfail.
• It does not cover code that runs before or around verification. LogoFAIL lived in image parsers inside the firmware that display the boot logo.
• It does not measure anything. Secure Boot enforces; Measured Boot records hashes into the TPM so that a remote party can check them later. You usually want both. Our explainer on Secure Boot, Trusted Boot and Measured Boot covers the difference in detail.
• It does not protect the running OS. Once the kernel is loaded, the OS and its own integrity features are responsible.

For the way signing keys, shims and boot loaders connect to the rest of the software supply chain, see how Secure Boot links to the software supply chain.

What changed from TPM 1.2 to 2.0, and why did Windows 11 require it?

The Trusted Platform Module is a small, passive security processor that holds keys, records boot measurements in Platform Configuration Registers (PCRs) and produces signed attestations. The Trusted Computing Group (TCG), a nonprofit, publishes the specification.

TCG lists early TPM 2.0 library revisions in March 2013 (00.96) and October 2013 (00.99), with revision 01.16 in October 2014. Joint Technical Committee 1 of ISO and IEC approved the TPM 2.0 library as ISO/IEC 11889:2015, Parts 1 to 4. The current library at the time of writing is Version 185, dated March 2026.

Microsoft's TPM recommendations page explains the main reasons to prefer 2.0:

• TPM 1.2 allows only RSA and SHA-1. TPM 2.0 supports additional algorithms through the TCG Algorithm Registry, which Microsoft describes as greater crypto agility.
• TPM 2.0 lockout and dictionary attack policy is configured consistently by Windows, while 1.2 implementations varied.
• TPM 1.2 parts were discrete chips. TPM 2.0 can be a discrete chip, an integrated block inside another package, or a firmware TPM running in a trusted execution environment on the main SoC.

Windows had been moving this way for years. Since 28 July 2016, Microsoft has required new desktop device models to implement and enable TPM 2.0. Windows 11, generally available on 5 October 2021, lists "UEFI, Secure Boot capable" firmware and TPM 2.0 among its minimum hardware requirements. Microsoft's feature table says Windows 11 requires TPM 2.0 by default to make it easier to turn on the stronger protections that pair Credential Guard with System Guard, and System Guard itself requires TPM 2.0 and UEFI.

TPM 1.2 and TPM 2.0 compared

A firmware TPM is still firmware. It gets its updates through the platform firmware or chipset firmware, so the TPM row in your inventory needs a firmware version, not only "2.0". For how TPM attestation relates to build and release pipelines, see trusted computing and the software supply chain.

What is a BMC, and how did IPMI give way to Redfish?

A baseboard management controller is a separate microcontroller on a server board that runs whenever the server has power, even when it is switched off. It monitors temperatures, voltages and fans, logs hardware events, power cycles the host, provides a remote console and can mount ISO images as virtual media. In other words, it can do almost anything a person with physical access could do.

The Intelligent Platform Management Interface standardised that control plane. IPMI 1.0 was published on 16 September 1998 under Intel's leadership. Version 1.5 in 2001 added LAN and serial access, version 2.0 in 2004 added Serial over LAN, and the last revisions were 2.0 rev 1.1 in 2013 with errata in 2015. More than 200 vendors support it. IPMI's weaknesses are well documented: older versions had design flaws in authentication, including the "cipher zero" option and the RAKP handshake, and BMC firmware is largely proprietary. The common advice is to put the management port on a restricted network, use central authentication and disable roles you do not need.

DMTF developed Redfish as the modern alternative. The first specification with base models, Redfish 1.0, was published in August 2015, and work under DMTF's Scalable Platforms Management Forum began in 2014. Redfish is a RESTful HTTPS API with a schema driven data model. SNIA's Swordfish, released in August 2016, extends it for storage. DMTF's developer hub currently links Redfish specification 1.25.0 and data model release 2026.2. DMTF's main site blocked our fetch, so treat the 1.0 date as secondary sourced.

IPMI and Redfish compared

The security lesson of the BMC is that it is a network facing Linux or RTOS appliance soldered to every server. It has its own web server, TLS library, SSH daemon and often open source components, and it rarely shows up in vulnerability scans of the host OS. Our post on the BMC firmware supply chain goes deeper on that point.

What are the landmark firmware and BMC security incidents?

Each layer above was shaped by incidents. These are the ones with clear primary documentation, in date order.

CIH, 1998: firmware as a target for destruction

CIH was first identified in June 1998, when Sophos obtained a sample from Taiwan. Its widespread 1.2 variant triggered on 26 April, the anniversary of the Chernobyl disaster. On vulnerable chip and chipset combinations it tried to write to the flash BIOS, which erased a whole block and left the machine unable to boot until the chip or board was replaced. Reported damage ran to hundreds of thousands of computers. CIH is why "firmware write protection" became a requirement rather than a nice idea, and it is the backdrop to NIST SP 800-147 thirteen years later.

BlackLotus, 2023: Secure Boot bypass in the wild

On 1 March 2023 security researchers published an analysis of BlackLotus, a UEFI bootkit that had been advertised on underground forums since at least October 2022 for 5,000 US dollars. The researchers described it as the first publicly known in the wild UEFI bootkit able to run on fully up to date Windows 11 systems with Secure Boot enabled. It used CVE-2022-21894, which Microsoft had fixed in January 2022, but the affected signed binaries were not yet in the revocation list. That gap between "patched" and "revoked" is the central lesson for Secure Boot operations, and it is why dbx updates and the 2023 certificates matter.

LogoFAIL, 2023: the parser nobody counted

On 6 December 2023 CERT/CC published VU#811862. Researchers found flaws in image parsing libraries that UEFI firmware uses to show a custom boot logo. Those parsers run with high privilege early in boot, and the note lists CVE-2023-39539 (AMI), CVE-2023-40238 (Insyde) and CVE-2023-5058 (Phoenix). CERT/CC's vendor statuses show how messy firmware supply chains are: an independent BIOS vendor may report its base product unaffected while OEM customised builds are affected. The fix path is the OEM's firmware update.

PKfail, 2024: test keys in production

PKfail was publicly disclosed on 25 July 2024, and CERT/CC published VU#455367 (CVE-2024-8105) on 30 August 2024. Some UEFI firmware shipped with untrusted test Platform Keys meant only for development. Because Secure Boot trusts whatever key sits in the PK, anyone holding the private half of such a key can sign boot code that the firmware accepts, which survives OS reinstalls. CERT/CC's mitigations are to install the latest vendor firmware, check whether the PK is a known test key, and apply firmware updates through LVFS on Linux or the OEM's Windows tooling.

The 2026 Secure Boot certificate rotation

This is not an attack but it is the biggest firmware trust event of the year. Microsoft's Secure Boot certificates issued in 2011 expire in 2026:

Microsoft says devices without the 2023 certificates "will continue to start and operate normally" and still receive standard Windows updates, but they can no longer receive new early boot protections such as Boot Manager updates, db and dbx updates, or fixes for new boot level vulnerabilities. Most devices should get the new certificates automatically; some need an OEM firmware update first. Linux systems that boot through a shim signed by the third party UEFI CA are affected by the same rotation, so check your distribution's guidance as well.

What do NIST SP 800-147 and SP 800-193 ask for?

SP 800-147, BIOS Protection Guidelines (April 2011). Written by David Cooper, W. Polk, Andrew Regenscheid and Murugiah Souppaya, it gives guidelines for preventing unauthorized modification of BIOS firmware on PC client systems. Its scope is the system BIOS in flash, focused on x86 and x64 clients. NIST files it under authentication, digital signatures, patch management and roots of trust. In practice that is the model most platforms now follow: firmware updates are signed by the vendor and verified before they are written, and the flash is protected against writes that bypass that path. NIST links a companion document, SP 800-147B, for server platforms.

SP 800-193, Platform Firmware Resiliency Guidelines (May 2018). Written by Andrew Regenscheid, it widens the scope from "do not let firmware be modified" to resilience across the whole platform: all the firmware and critical data needed to boot and operate. It organises requirements into three functions:

• Protect: mechanisms that prevent unauthorized changes to platform firmware and data.
• Detect: mechanisms that notice when unauthorized changes have happened anyway.
• Recover: mechanisms that restore firmware and data to a known good state quickly and securely.

NIST's abstract notes that a successful firmware attack could leave a system inoperable, possibly permanently, or require reprogramming by the manufacturer. That is the CIH lesson written into guidance. SP 800-193 is aimed at OEMs and component suppliers, but NIST explicitly expects administrators to use it in procurement. We cover the three functions in more depth in NIST SP 800-193 protect, detect, recover explained, and the hardware side in hardware root of trust for device makers.

What should a firmware inventory record?

You cannot apply a LogoFAIL update, check for a PKfail test key or plan the 2026 certificate rotation without knowing what you own. A firmware inventory turns those one off scrambles into queries. At minimum, record the following per device:

CycloneDX has component types for this. Its 1.6 schema includes device (a hardware device such as a processor or chipset), firmware (low level software that controls a device's hardware), device-driver and platform. CycloneDX advises that when a device contains firmware, the BOM should list the physical hardware and the firmware as separate components. That structure maps neatly onto the table above. For a broader treatment, see our firmware supply chain security guide.

Step by step: audit a board's firmware posture

These steps collect the inventory fields above on Linux, Windows and a Redfish capable BMC. They are read only except where marked.

1. Identify the board and firmware (Linux)

# Board, firmware vendor, version and release date from SMBIOS
sudo dmidecode -t baseboard | grep -E 'Manufacturer|Product Name|Version'
sudo dmidecode -t bios | grep -E 'Vendor|Version|Release Date'

# Confirm the system booted in UEFI mode
[ -d /sys/firmware/efi ] && echo "UEFI boot" || echo "Legacy or CSM boot"

2. Check Secure Boot and TPM (Linux)

# Secure Boot state
mokutil --sb-state

# Inspect the Platform Key and KEK certificates (look for test or DO NOT TRUST subjects)
mokutil --pk | grep -E 'Subject:|Issuer:'
mokutil --kek | grep -E 'Subject:|Issuer:'

# TPM presence and major version
cat /sys/class/tpm/tpm0/tpm_version_major 2>/dev/null || echo "No TPM exposed"

If the PK subject names a test or sample key, treat it as a PKfail candidate and follow your OEM's advisory. Do not try to replace keys by hand on a fleet without vendor guidance; a wrong PK can leave a machine unbootable with Secure Boot on.

3. Ask fwupd what it knows (Linux)

# Devices fwupd can see, with firmware versions
fwupdmgr get-devices

# Host Security ID report (fwupd 1.8.4 or later)
fwupdmgr security

# Check for available firmware updates from LVFS
fwupdmgr refresh
fwupdmgr get-updates

fwupdmgr security reports a Host Security ID from HSI:0 (insecure) to HSI:4, with HSI:1 described by the fwupd project as the baseline for a safe system, and appends ! when it detects runtime issues such as Secure Boot being off. It checks things like SPI flash write protection, BIOS Write Enable, Intel Boot Guard and whether the TPM event log matches PCR0.

Warning before applying firmware. Flashing firmware rewrites the chip that boots the machine. Before you run the next command, confirm the device ID matches the machine you mean to update, plug laptops into mains power, suspend BitLocker or any TPM sealed disk encryption if your vendor advises it, and make sure you have the recovery key.

# Confirm exactly which device will be updated before flashing
fwupdmgr get-updates | grep -E 'Device ID|Current version|New version'

# Then, and only then
fwupdmgr update

4. Collect the same facts on Windows (PowerShell, elevated)

# Board and firmware
Get-CimInstance Win32_BaseBoard | Select-Object Manufacturer, Product, Version
Get-CimInstance Win32_BIOS | Select-Object Manufacturer, SMBIOSBIOSVersion, ReleaseDate

# Secure Boot (True means on; an error means legacy boot)
Confirm-SecureBootUEFI

# TPM status and versions
Get-Tpm
Get-CimInstance -Namespace root\cimv2\security\microsofttpm -ClassName Win32_Tpm |
  Select-Object SpecVersion, ManufacturerVersion

# Is the Windows UEFI CA 2023 certificate in db yet?
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'

A False on the last line means the device has not received the 2023 boot certificate yet. Follow Microsoft's Secure Boot certificate guidance and check whether your OEM requires a firmware update first.

5. Read firmware inventory from a BMC over Redfish

# Replace with your BMC address; use a read only account
BMC=https://bmc.example.internal

# List firmware components the BMC knows about
curl -s -u "$BMC_USER" "$BMC/redfish/v1/UpdateService/FirmwareInventory" | jq '.Members[]."@odata.id"'

# Then fetch one entry to get its name and version
curl -s -u "$BMC_USER" "$BMC/redfish/v1/UpdateService/FirmwareInventory/BMC" | jq '{Name, Version, Updateable}'

Member names after FirmwareInventory vary by vendor, so use the IDs returned by the first call. For older BMCs that only speak IPMI, ipmitool mc info returns the BMC firmware revision. Run both from a management network, never across the internet.

6. Store it where you can query it

Put the results in your asset system, one record per device, with the fields from the inventory table. If a vendor supplies an SBOM for the firmware or the BMC image, store it alongside the record. When the next advisory lands, the question "which of our boards run this firmware version" should take minutes.

Where Safeguard fits, honestly

Safeguard does not scan firmware images, read SPI flash, check Secure Boot keys, attest boards or generate a hardware bill of materials, and it is not an endpoint or device management product. The boot chain in this post is mostly outside its scope.

The honest overlap is that firmware is software from suppliers. BMC images, firmware update packages and appliance images ship open source components such as web servers, TLS libraries and Linux userlands. When a vendor gives you an SBOM for that software, Safeguard can ingest and analyse it (safeguard scan --sbom vendor-bmc-sbom.json), match its components against vulnerability databases, and show which of your products and projects contain a given component and version. That turns "does any of our hardware ship the affected library" into a query, as long as the vendor provided the SBOM. It also covers the software you build to run on these machines, which is usually where you can act fastest.

Common mistakes

• Treating "UEFI" as "secure". Many UEFI systems run with CSM on or Secure Boot off after a troubleshooting session. Check the actual state, not the firmware type.
• Turning off Secure Boot to fix a boot problem and never turning it back on. Record the change and set a reminder to reverse it.
• Assuming a patched OS means a revoked loader. BlackLotus showed that a fix and a revocation are separate steps. Track dbx updates as their own item.
• Recording "TPM 2.0" without a firmware version. TPMs, especially firmware TPMs, have advisories of their own.
• Leaving the BMC on the production network with default credentials. It is a full remote console. Put it on an isolated management network, change credentials, and patch it on a schedule.
• Forgetting option ROMs. Network, storage and GPU cards bring their own signed firmware into the boot chain and depend on the third party UEFI CA that is rotating in 2026.
• Flashing firmware without a recovery path. Have the BitLocker or LUKS recovery key, mains power and, on servers, a BMC console before you start.
• Buying boards without asking about update support. NIST SP 800-193 expects buyers to ask how firmware is protected, how tampering is detected and how it is recovered. Ask for the update channel and support period in writing.

FAQ

What is the difference between BIOS and UEFI?

BIOS is the original PC firmware: 16 bit, MBR based and without any image verification. UEFI is a specification maintained by the UEFI Forum that boots EFI applications from a GPT disk, supports signed drivers and option ROMs, and adds Secure Boot. Many people still call UEFI setup "the BIOS".

What does the PCH do on a motherboard?

The Platform Controller Hub is the single chipset chip that remained after the memory controller and main PCIe lanes moved into the CPU. It handles storage, USB, audio, clocking, the firmware flash and, on Intel platforms, the Management Engine, and connects to the CPU over DMI.

Why does Windows 11 need TPM 2.0?

Microsoft lists TPM 2.0 and UEFI Secure Boot capable firmware as minimum requirements. TPM 2.0 supports modern algorithms beyond RSA and SHA-1, behaves consistently across implementations, and is required for features such as System Guard, which strengthens Credential Guard.

Is a firmware TPM as good as a discrete TPM chip?

Microsoft does not take a position and treats discrete, integrated and firmware TPMs the same way in Windows. They differ in where they run and how they are updated. A firmware TPM is updated with platform firmware, so keep that firmware current.

Does Secure Boot stop bootkits?

It stops unsigned boot code and anything in dbx. It does not stop signed but vulnerable loaders that have not been revoked (as with BlackLotus), firmware that trusts a leaked test key (PKfail), or flaws in firmware code that runs during boot (LogoFAIL). Keep firmware and dbx updated, and pair Secure Boot with Measured Boot.

What is a BMC and is it a security risk?

A baseboard management controller is a separate computer on a server board that can power cycle the host, provide a remote console and mount media. It is a risk if it is reachable from untrusted networks, runs old firmware or uses weak IPMI options. Isolate it, patch it and prefer Redfish over TLS.

What is the difference between IPMI and Redfish?

IPMI is a binary management protocol first published in 1998. Redfish, from DMTF with version 1.0 in 2015, is a RESTful HTTPS API with a versioned JSON data model and a standard firmware inventory. New management tooling targets Redfish.

What happens when the Secure Boot certificates expire in 2026?

According to Microsoft, devices keep booting and receiving normal Windows updates. Devices without the 2023 certificates can no longer receive new boot level protections, including Boot Manager updates and db or dbx updates. Check whether your devices have the 2023 certificates and whether your OEM needs to ship firmware first.

Fix it without waiting for upstream

When a board is reflashed or replaced, the machine pulls operating system packages, drivers and application dependencies again, and BMC and appliance images ship open source components of their own. The fit with firmware itself is indirect: nothing below touches the boot chain, but it keeps the open source software you build and run on that hardware current and fixed.

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

The first demo is a real terminal session with the Safeguard CLI. It reads a vulnerability finding and its advisory, asks before each command, upgrades a dependency, runs the tests with your approval and pushes nothing. The same flow applies to the tooling and services you run on freshly built or reflashed hardware, such as the management scripts and dashboards that talk to your BMCs.

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

The second demo sets up the local runner on your own machine, approves it with a device code and runs scans from the terminal. That suits a management workstation on an isolated network, where you want to scan a vendor supplied SBOM or a local project without sending source anywhere else.

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 lets you choose which tools Claude can use. Once connected, you can ask which of your projects contain a component that a firmware or BMC vendor has flagged, as long as that software is in your Safeguard inventory.

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

To try it on your own projects, download Safeguard at safeguard.sh/download and read the CLI documentation.

Quick check

Sources

• NIST SP 800-147, BIOS Protection Guidelines
• NIST SP 800-193, Platform Firmware Resiliency Guidelines
• Trusted Computing Group, TPM 2.0 Library Specification
• Microsoft Learn, Windows 11 requirements
• Microsoft Learn, TPM recommendations
• Microsoft Learn, Secure Boot (OEM guidance)
• Microsoft Support, Windows Secure Boot certificate expiration and CA updates
• Windows Experience Blog, Windows 11 availability, 4 October 2021
• CERT/CC VU#811862, LogoFAIL
• CERT/CC VU#455367, PKfail
• Microsoft Security Blog: Guidance for investigating attacks using CVE-2022-21894, the BlackLotus campaign (11 April 2023)
• fwupd, Host Security ID specification
• CycloneDX 1.6 JSON reference
• DMTF Redfish Developer Hub
• Wikipedia, ATX (secondary)
• Wikipedia, UEFI (secondary)
• Wikipedia, Platform Controller Hub (secondary)
• Wikipedia, Intelligent Platform Management Interface (secondary)
• Wikipedia, Redfish (secondary)
• Wikipedia, CIH (secondary)

Last reviewed: 23 October 2026.