How a Rack Server Is Made: Motherboard, BMC, Firmware and Provisioning

A rack server is made by fabricating a multi layer motherboard, populating it with CPUs, memory, a baseboard management controller (BMC) and a root of trust, flashing a dozen separate firmware images, burning the whole system in, and then provisioning identity: device certificates in silicon, a TPM endorsement certificate and, increasingly, a signed platform certificate that lists what shipped. Buyers verify that chain on delivery.

This post goes one level deeper than our motherboard evolution guide covering chipsets, BIOS, UEFI, TPM and the BMC and our look at BMC firmware as a supply chain problem. It follows one 1U or 2U server from bare board to a racked machine, and at each step asks the same question: which firmware got written here, who signed it, and which key or certificate was created? The facts come from published specifications from the Open Compute Project (OCP), the Trusted Computing Group (TCG), NIST, DMTF and CISA, plus the documentation of the open source tools you will use on arrival. Where a step depends on a specific vendor's process, we say so and suggest what to ask.

Key takeaways

• A server is two computers in one box: the host and the BMC, which runs from the moment power is applied. OCP's DC-SCM specification moves the BMC, BMC and BIOS flash, a CPLD, an optional root of trust and the TPM onto one replaceable module.
• A typical server carries ten or more separately updated firmware images (UEFI/BIOS, BMC, CPLD, NIC, RAID or HBA, drives, PSUs, TPM, accelerators), written and signed by different companies.
• NIST SP 800-193 (May 2018) frames firmware resiliency as Protection, Detection and Recovery, each anchored in its own root of trust. SP 800-147B (August 2014) covers authenticated BIOS updates on servers.
• Keys enter at more than one factory: a silicon root of trust such as Caliptra gets its device secret fused and its IDevID certificate signed by the chip vendor's HSM backed CA; the server maker later issues a TCG Platform Certificate.
• TCG Platform Certificate Profile 2.0 (revision 39, 29 July 2024) defines Base certificates for the configuration as shipped and Delta certificates for changes made by integrators and resellers.
• On arrival, inventory firmware with Redfish FirmwareInventory, dmidecode, fwupdmgr, in band ipmitool, ethtool -i and nvme id-ctrl, and compare it with the order and the platform certificate.
• Ask vendors for firmware SBOMs, update cadence, end of support dates, the signing model per image and platform certificates. CISA's HBOM framework stops short of firmware provenance, so those questions are yours.

What goes into a 1U or 2U server?

"1U" and "2U" are rack units: a 1U server is about 1.75 inches tall, a 2U server twice that, both built to fit a standard 19 inch rack. The height decides almost everything else about the design: how many drive bays fit on the front, how tall the PCIe cards can be, how big the fans are, and how much heat the box can shed. A 1U chassis usually packs more servers per rack but uses small, fast spinning fans and low profile cards; a 2U chassis gives room for full height PCIe cards, GPUs and more drives.

The parts, front to back

Every row is made by a different team, often a different company, and most rows contain code that someone must sign and update for years.

Why the BMC changes the picture

The BMC is a separate system on a chip, with its own DRAM, its own flash and usually a dedicated network port. NIST SP 800-193 describes it as an out of band management device that lets administrators manage the platform without the host operating system running. CISA's 14 June 2023 announcement of joint NSA and CISA guidance adds the security view: BMCs work separately from the operating system, even when the server is shut down, and a vulnerable one gives attackers "a beachhead with pre-boot execution potential." Our Redfish post covers locking its management interface down; here we care about where its firmware comes from.

How are server motherboards designed and manufactured?

From schematic to bare board

A server motherboard starts as a reference design from the CPU maker: socket pinout, memory channel routing rules, power delivery requirements and a list of validated companion chips. A board designer turns that into a schematic, then a physical layout on a multi layer printed circuit board. Server boards need many layers because each CPU socket fans out to many memory channels and dozens of high speed PCIe lanes, and those signals need controlled impedance and ground reference planes.

A PCB plant images and etches copper clad layers, presses them together, drills and plates the holes that connect layers, adds solder mask and silkscreen, and tests the bare board for opens and shorts.

Assembly: solder paste to tested board

At surface mount assembly a stencil prints solder paste onto the pads, pick and place machines set thousands of components, and a reflow oven melts the paste into joints. Large ball grid array parts such as the BMC, the platform controller and the CPU socket's land grid array are checked with automated X ray inspection because their joints are hidden. Through hole connectors are soldered afterwards. Automated optical inspection, in circuit test and boundary scan through JTAG check that parts are present, the right way round and connected.

This is also the first place firmware enters the product. Flash chips are often programmed before they are placed, or programmed on the board through a header or JTAG. The BIOS flash, BMC flash, CPLD and sometimes the root of trust's initial image all receive a factory image here. Those images should be the vendor's signed production images; a debug or development image left in place at this step is a classic factory escape.

The ODM and OEM model

Two business models build most servers.

The model matters for security because it decides who holds the signing keys. In an OEM model the OEM's keys sign the BIOS and BMC images and the OEM runs the update service. In an ODM model with a customer controlled BMC stack, the customer may hold the BMC signing key and the ODM may hold the BIOS key. When you buy, the first question is simply: for each firmware image in this box, whose key signs it, and who can sign a replacement?

Why OCP's DC-SCM split the board in two

OCP's Datacenter-ready Secure Control Module specification, version 1.0 dated 11 March 2021, formalises a split that large operators wanted. It moves common management, security and control features off the processor motherboard and onto a smaller, common module. The spec defines a Host Processor Module (HPM), "similar to today's motherboard with BMC and Security circuitry removed," and the DC-SCM card that plugs into it through a standard connector, the DC-SCI.

According to the specification, the DC-SCM carries the BMC, one or more (typically two) BMC flash devices, one or more (typically two) BIOS flash devices, a DC-SCM CPLD, an optional RoT security processor that attests the BMC, BIOS and other firmware, and a TPM. It defines horizontal, vertical and internal form factors.

The supply chain effect is large. The parts of the server that hold keys and boot firmware live on one small board that an operator can source separately, standardise across platforms and replace within a hardware generation, while the host board becomes closer to commodity. The OCP specification lists this as a benefit for both operators and developers: management and security upgrades can be deployed within a platform generation without redesigning the more complex boards.

What firmware ships in a server, and who signs each image?

NIST SP 800-193 is the clearest public catalogue of server firmware. It lists, among others, the embedded controller or super I/O, the TPM, the BMC, the host processor's boot firmware, NICs, GPUs and storage controllers and devices, and explains why each matters. On NICs, for example, it warns that compromised NIC firmware "could serve as a launch pad for other exploits in the system," and that a NIC's expansion ROM, which the host processor executes during boot, needs the same protection.

The table below combines that list with how signing generally works in the industry. Signing arrangements vary by vendor and generation, so treat the right hand column as the question to ask, not as a guarantee.

What the standards require of updates

NIST SP 800-147B, published in August 2014, is the server specific guide to protecting the system BIOS. It covers basic, managed and blade servers and defines four features: authenticated BIOS update mechanisms, where digital signatures stop unauthentic update images from running; an optional secure local update that requires physical presence; firmware integrity protections against modification outside the update process; and non-bypassability, so that neither the main processor nor any other component can skip the protections. It devotes a section to service processors, the older name for BMCs, because some of them can update the system BIOS and some cannot.

One sentence in its executive summary is worth reading twice: the guidelines "do not attempt to prevent installation of an inauthentic BIOS through the supply chain," nor replacement of the BIOS chip, nor installs through secure local update. Signed updates protect the field. They do not, on their own, prove that what left the factory was right. That gap is what platform certificates and attestation try to close.

NIST SP 800-193, Platform Firmware Resiliency Guidelines, published in May 2018, broadened the scope from BIOS to all platform firmware and organised it into three principles:

• Protection: firmware code and critical data stay in an authentic, integrity protected state, and updates go through an authenticated update mechanism anchored in a Root of Trust for Update (RTU).
• Detection: a Root of Trust for Detection (RTD) notices when firmware or critical data has been corrupted or changed by something other than an authorised update.
• Recovery: a Root of Trust for Recovery (RTRec) restores firmware and critical data to a known good state. The document notes the authors deliberately avoided "RTR" as an acronym because it already means Root of Trust for Reporting.

SP 800-193 requires that an authenticated update mechanism anchored in the RTU be the only way to update a device's firmware, unless someone is physically present and uses a secure local update. That is the requirement you are really asking about when you ask a vendor "who signs this?"

What happens on the factory floor?

After board assembly, board, chassis and parts come together at system integration (often called L10 when the factory builds whole racks). This is where most of the firmware and identity in your server is set.

Build to order and configuration

Operators install the ordered CPUs, DIMMs, drives, NICs, risers, PSUs and accelerators, route cables and power the system up on a test station. The factory then flashes the firmware set this configuration was qualified with, often a pinned "golden" set qualified months earlier rather than the newest release. A server can arrive with security fixes already waiting.

Burn-in and test

Burn-in runs the system under load, often warm, for hours to shake out early failures such as marginal DIMMs, weak joints and failing drives. Tests exercise memory, storage, ports and PCIe slots, read sensors through the BMC and check the event log. Failures are reworked and retested.

Asset tagging and FRU data

The factory writes identity data that you will read later:

• SMBIOS tables, which the BIOS builds and the OS reads, carry the system manufacturer, product name, serial number, UUID and an asset tag. The dmidecode project lists system manufacturer, model name, serial number, BIOS version and asset tag among the fields this data typically holds.
• FRU (field replaceable unit) records in small EEPROMs on the board, PSUs and other parts hold part numbers and serial numbers. ipmitool fru print reads them.
• Physical labels and barcodes, which should match both of the above.
• Customer asset tags, which many buyers ask the factory to program so that the server arrives already matching their inventory system. Redfish exposes an AssetTag property on the ComputerSystem resource for the same purpose.

Provisioning keys and certificates

Keys arrive in two waves.

The first wave happens at the silicon vendor. The Caliptra specification gives a concrete public example. During high volume manufacturing (HVM), the tester programs a NIST compliant Unique Device Secret (UDS) into fuses, sets the chip into a manufacturing security state and asks Caliptra's ROM for an IDevID certificate signing request. The CSR is read out through JTAG or the SoC interface and endorsed by the vendor's provisioning CA, which runs on an HSM appliance connected to the HVM line. From then on the chip can prove which physical die it is. The spec adds that Caliptra 2.0 protects the integrity of the IDevID CSR, because with Caliptra 1.0 alone an attacker sitting between the chip and the provisioning CA could submit a CSR of their own. The same specification calls operational security during manufacturing critical, and also places it out of scope. That is an honest statement of where trust in the factory begins.

TPMs follow a similar pattern: the TPM maker creates or injects the endorsement key (EK) and issues an EK certificate during manufacturing.

The second wave happens at the server maker. Once the platform is built and tested, the manufacturer can issue a TCG Platform Certificate that binds the platform's identity to its roots of trust (the TPM's EK, a DICE identity, or an IDevID) and lists its components. Some operators also provision their own keys at the factory or on first boot, such as custom Secure Boot keys or an LDevID from their own CA.

Ship

The server ships, often with tamper evident seals. The question then becomes whether the buyer can prove that what arrived is what the factory built.

Step table: from board fab to a racked server

What are OCP specs like DC-SCM and Caliptra, and why do they matter for trust?

The Open Compute Project publishes open hardware specifications that large operators and suppliers share. Three groups of OCP work matter directly for how a server earns trust.

DC-SCM: one module for management and security

As covered above, DC-SCM puts the BMC, its flash, the BIOS flash, the CPLD, an optional root of trust and the TPM on one module. For trust, its value is consistency: one root of trust design and one BMC firmware stack can be qualified and deployed across many host boards, rather than each motherboard reinventing them. OCP's hardware management project lists DC-SCM 2.0 designs alongside the 1.0 specification, and related work on server component resilience and GPU firmware update.

Caliptra: a root of trust inside the chip

Caliptra's repository describes it as the specification, silicon logic, ROM and firmware for a Root of Trust for Measurement (RTM) block inside a chip, targeting "datacenter-class SoCs like CPUs, GPUs, DPUs, TPUs." It started at OCP; major specification revisions are published at OCP while the code and documentation live in the CHIPS Alliance project, a Series of LF Projects, LLC, under the Apache 2.0 license. The specification we read is revision 2.1.

What Caliptra gives a chip is identity, measured boot and attestation. Its ROM derives keys following TCG DICE, its IDevID is endorsed by the vendor's provisioning CA, its LDevID mixes in field programmable entropy so an owner can renew the identity, and its mutable firmware carries security version numbers (SVNs) that are raised when a security critical issue is fixed, so a chip can refuse to roll back to vulnerable firmware. Caliptra supports both ECDSA secp384r1 and the post quantum ML-DSA-87 for endorsement, according to the specification.

If every CPU, GPU and NIC carries a root of trust that reports signed measurements of its own firmware, you can verify them without trusting the BMC's word alone.

OCP S.A.F.E.: reviewing firmware before you buy

OCP's Security Appraisal Framework and Enablement program, S.A.F.E., "standardizes firmware security reviews across the data center supply chain." Independent review providers assess a device's firmware against published criteria, and approved products and findings reports are published on the program's GitHub repository. A S.A.F.E. report is one of the few public, standardised pieces of evidence about a device's firmware that does not come from the vendor, so ask whether major components have one.

How do TCG platform certificates and DICE support supply chain verification?

Platform certificates

The TCG Platform Certificate Profile defines the platform certificate as "a signed statement describing characteristics of a platform that can affect the platform's trustworthiness." Version 2.0, revision 39, published 29 July 2024, says a platform certificate asserts that a specific platform contains one or more unique roots of trust (a TPM, DICE and so on), trusted building blocks and a specific set of components. As of 2.0, the root of trust is no longer limited to the TPM endorsement key, so the same certificate can bind to a DICE identity or an IDevID.

The certificate types map directly onto the supply chain:

The profile allows the certificate to be an X.509 attribute certificate (RFC 5755) or a public key certificate (RFC 5280). An attribute certificate is used when the attributes change on a different schedule from the key, which is normal for servers whose parts get swapped. A key certificate fits when the platform has an IDevID that can prove possession with a CSR.

The profile is careful about trust: any entity can issue a platform certificate, and relying parties must establish trust in the issuer before using one. That is, the certificate is only as good as your decision about which manufacturers' and resellers' signing CAs you accept.

How a verifier uses it

The TCG profile describes platform certificates as endorsements that a verifier uses when it evaluates evidence from the platform being checked. In plain terms, on delivery:

1. The server's TPM or DICE root proves it holds the key the certificate names.
2. The verifier checks the certificate's signature against the manufacturer's CA, and any deltas against the integrators' CAs.
3. The verifier collects the real component list from the running system and compares it with the certificate.
4. Any mismatch, such as a different drive serial, is flagged before the server joins production.

The NSA's open source Host Integrity at Runtime and Start-up (HIRS) project implements this flow. Its README calls it a proof of concept prototype "not intended for production," built around an Attestation CA that can validate a platform's configuration and firmware against artifacts the OEM provides, including endorsement certificates, platform certificates and reference integrity manifests. The NSA's companion tool paccor "creates, signs, inspects, and validates TCG Platform Certificates," with certgen, assemble, validate and view commands.

DICE

DICE (Device Identifier Composition Engine) solves the identity problem for components too small or too specialised for a TPM: NIC controllers, SSD controllers, root of trust blocks. The TCG DICE work group describes the goal as security with "minimal silicon requirements": simple silicon features plus software techniques that give a device a strong cryptographic identity, attest its software and help deploy and verify updates safely.

The mechanism, described conceptually: the silicon holds a Unique Device Secret that only the first boot stage can read. That stage measures the next firmware layer and combines the secret with the measurement to derive a Compound Device Identifier (CDI) for that layer, then locks the original secret away. Each layer repeats the step for the next. Keys derived from a CDI therefore depend on the exact firmware that booted. Change the firmware and the derived identity changes, which a verifier sees immediately. The Caliptra specification describes its own implementation: the real UDS is computed only during cold boot, used to derive the CDI and then cleared by hardware straight away.

Caliptra also explains why DICE identities suit servers that change hands: "the new owner is not burdened with the identity of the previous owner," and DICE based certificates work with standard PKI lifecycle management and revocation lists.

SPDM: how the measurements travel

DMTF's Security Protocol and Data Model, DSP0274 (version 1.4.1, 26 June 2026), is the protocol that carries certificates and signed measurements between a device and a requester such as the BMC, with messages including GET_CERTIFICATE, CHALLENGE and GET_MEASUREMENTS. Redfish exposes the results through the ComponentIntegrity resource, and the Redfish SoftwareInventory schema includes a Measurement property described as "a DSP0274-defined measurement block." The Redfish post shows how to request a fresh, nonce bound measurement.

Comparison: what each mechanism proves

How do you inventory server firmware on arrival?

The goal on arrival is a record, per server, of every firmware component and version, every serial number that matters, and the platform certificate, all compared against what you ordered. The steps below are read only. They change nothing on the server.

Step 1: from the BMC with Redfish

Redfish exposes firmware under the UpdateService. The Redfish specification (DSP0266 version 1.25.0, 7 August 2026) uses the same collection as its own example of an expanded request: GET /redfish/v1/UpdateService/FirmwareInventory?$expand=. Each member is a SoftwareInventory resource; schema version 1.15.0 defines properties including Version, Updateable, Manufacturer, ReleaseDate, LowestSupportedVersion, SoftwareId and WriteProtected.

Run this from a management host on the isolated BMC network, with the BMC's CA certificate rather than -k, and a read only account:

BMC=https://10.10.0.21
CA=./bmc-ca.pem

# Create a session and capture the token (read only account)
TOKEN=$(curl -s --cacert "$CA" -D - -o /dev/null \
  -H 'Content-Type: application/json' \
  -d '{"UserName":"inventory-ro","Password":"'"$BMC_PASS"'"}' \
  "$BMC/redfish/v1/SessionService/Sessions" \
  | awk -F': ' 'tolower($1)=="x-auth-token"{print $2}' | tr -d '\r')

# List every firmware component with version and updateability
curl -s --cacert "$CA" -H "X-Auth-Token: $TOKEN" \
  "$BMC/redfish/v1/UpdateService/FirmwareInventory?\$expand=." \
  | jq -r '.Members[] | [.Id, .Name, .Version, .Manufacturer // "", .ReleaseDate // "", (.Updateable|tostring)] | @tsv'

# System identity: serial, UUID, asset tag, BIOS version
curl -s --cacert "$CA" -H "X-Auth-Token: $TOKEN" \
  "$BMC/redfish/v1/Systems" | jq -r '.Members[]."@odata.id"' \
  | while read -r sys; do
      curl -s --cacert "$CA" -H "X-Auth-Token: $TOKEN" "$BMC$sys" \
        | jq '{SerialNumber, UUID, AssetTag, BiosVersion, Model, Manufacturer}'
    done

Not every BMC supports $expand; if yours does not, fetch the collection and then each member. Delete the session when finished with an HTTP DELETE on the session URI returned in the Location header.

Step 2: from the host with dmidecode

dmidecode reads the SMBIOS tables. Its own documentation warns that it does not scan hardware, it "only reports what the BIOS told it to," and that DMI data should not be blindly trusted. Use it as one source among several.

sudo dmidecode -s system-manufacturer
sudo dmidecode -s system-product-name
sudo dmidecode -s system-serial-number
sudo dmidecode -s system-uuid
sudo dmidecode -s bios-version
sudo dmidecode -s bios-release-date
sudo dmidecode -t chassis | grep -i 'asset tag'

# SMBIOS Type 45, Firmware Inventory Information (SMBIOS 3.5 and later),
# on platforms and dmidecode versions that support it
sudo dmidecode -t 45

The SMBIOS specification (DSP0134 version 3.8.0, 5 August 2024) describes Type 45 as an inventory of firmware components "such as platform firmware, BMC, as well as firmware for other devices," with one structure per component, and notes it was added in version 3.5. Many platforms do not populate it yet, which is itself useful information for your vendor conversation.

Step 3: from the host with fwupd

fwupd is the Linux project that aims "to make updating firmware on Linux automatic, safe, and reliable," with metadata from the Linux Vendor Firmware Service (LVFS). Even on servers where you will not update through fwupd, its read only commands are a good second opinion:

# All devices fwupd can see, with current firmware versions
fwupdmgr get-devices --json > fwupd-devices.json

# Host security attributes (Secure Boot, BIOS write protection, and so on)
fwupdmgr security

# Firmware update history recorded by fwupd on this host
fwupdmgr get-history

The fwupdmgr manual describes security as listing the "host security attributes" used to judge how secure the machine is. Coverage of server components depends on which vendors publish to LVFS and which fwupd plugins support your hardware, so expect gaps.

Step 4: in band IPMI, without enabling IPMI over LAN

ipmitool's README describes it as a command line interface to the BMC that can read sensors, display the System Event Log and print "Field Replaceable Unit (FRU) inventory information." Run it in band, from the host operating system through the local IPMI driver, so you do not need to switch on IPMI over LAN (which the Redfish post explains how to keep off):

sudo modprobe ipmi_devintf ipmi_si 2>/dev/null
sudo ipmitool mc info        # BMC firmware revision and IPMI version
sudo ipmitool fru print      # board, product and PSU part and serial numbers
sudo ipmitool sel elist | tail -n 50   # recent events, including factory test leftovers

Step 5: device level firmware

# NIC firmware versions, per interface
for i in $(ls /sys/class/net | grep -v lo); do echo "$i: $(ethtool -i "$i" 2>/dev/null | grep firmware-version)"; done

# NVMe drive model, serial and firmware revision (read only)
for d in /dev/nvme[0-9]; do sudo nvme id-ctrl "$d" | grep -E '^(mn|sn|fr) '; done

# SATA and SAS drives
for d in /dev/sd?; do sudo smartctl -i "$d" | grep -E 'Model|Serial|Firmware'; done

# PCIe devices, including option ROM presence
sudo lspci -vv | grep -E '^[0-9a-f]|Expansion ROM|Subsystem'

# TPM manufacturer and firmware version
sudo tpm2_getcap properties-fixed | grep -A2 -E 'TPM2_PT_MANUFACTURER|TPM2_PT_FIRMWARE_VERSION'

Step 6: the platform certificate

If the vendor supplies a platform certificate, find out where: some deliver it on the system (for example in a vendor defined location on storage or in flash), others by download keyed to the serial number. A platform attribute certificate is not a normal X.509 public key certificate, so openssl x509 will not parse it. To look inside the DER structure:

openssl asn1parse -inform DER -in platform-cert.der | less

For real validation (signature against the manufacturer's CA, binding to the TPM EK certificate, component comparison), use a tool built for the profile, such as the NSA's paccor validate and view commands or the HIRS Attestation CA in a lab. Follow each tool's own documentation for arguments.

Step 7: compare and record

Join the outputs into one record per server and compare it with the purchase order, the vendor's firmware baseline and the platform certificate. Keep it as your "as received" baseline.

What should a buyer ask a server vendor?

The CISA HBOM framework, published 25 September 2023 by the ICT Supply Chain Risk Management Task Force, gives buyers a consistent way to ask about hardware components and lists use cases that map to the data fields a supplier should provide. It notes that the framework records who provides each component's firmware but "stops short of proposing a framework for examining the provenance" of that firmware. Firmware is where the hardest questions sit, so ask them directly. NIST SP 800-161 Revision 1 (May 2022, updated 1 November 2024) gives the wider supply chain risk context: it addresses products that may contain malicious functionality, "are counterfeit, or are vulnerable due to poor manufacturing and development practices."

Timeline of the standards behind server trust

Common mistakes

• Assuming factory firmware is current. Factories flash a qualified set that can be months old. Inventory on arrival and update before production.
• Inventorying only BIOS and BMC. NICs, drives, RAID controllers, PSUs, CPLDs and the TPM all carry firmware. NIST SP 800-193 lists most of them for a reason.
• Trusting dmidecode alone. Its maintainers say it reports what the BIOS provides, not what the hardware is. Cross check against Redfish and device level tools.
• Enabling IPMI over LAN to run an inventory. Use in band ipmitool from the host or Redfish over HTTPS instead.
• Accepting platform certificates without deciding whom to trust. The TCG profile says any entity can issue one. Decide which manufacturer and reseller CAs you accept before you validate anything.
• Ignoring delta certificates. If a reseller swapped a drive or added a NIC and issued no delta certificate, the Base certificate will not match, and that mismatch is the signal you want. Do not "fix" it by ignoring components.
• Treating signed updates as proof of a good factory image. SP 800-147B says plainly that its guidelines do not attempt to prevent an inauthentic BIOS arriving through the supply chain.
• Running an operator built BMC stack with the default development key. As our Redfish guide explains, OpenBMC builds sign images with a development key unless the builder supplies a production key.
• Skipping the end of support question. A server with five years of planned life and three years of firmware support becomes unpatchable in year four.
• Losing the "as received" record. Without it you cannot tell later whether a firmware change was yours.

FAQ

How is a server motherboard made?

A designer turns the CPU maker's reference design into a schematic and a multi layer PCB layout. A PCB plant images, etches, laminates, drills and plates the layers, then electrically tests the bare board. An assembly line prints solder paste, places components, reflows them, inspects hidden joints with X ray, runs in circuit and boundary scan tests, and programs the BIOS, BMC and CPLD flash.

What is the difference between an ODM and an OEM server?

An OEM sells servers under its own brand, owns the firmware builds and support, and usually signs the BIOS and BMC images. An ODM designs and manufactures boards and systems, often to a large customer's specification, and that customer may run its own BMC firmware and keys. The difference matters most for who holds signing keys and who ships security updates.

What firmware is in a server?

At minimum: UEFI or BIOS, CPU microcode, BMC firmware, CPLD logic, root of trust and TPM firmware, NIC firmware and option ROMs, RAID or HBA controller firmware, drive firmware and power supply firmware. GPUs and other accelerators add their own. NIST SP 800-193 discusses most of these as platform firmware that needs protection, detection and recovery.

What is a TCG platform certificate?

A signed statement, defined by the TCG Platform Certificate Profile, that a specific platform contains particular roots of trust and a specific set of components. The manufacturer issues a Base certificate for the configuration as shipped, and integrators or resellers issue Delta certificates for later changes. Buyers use it to check that what arrived matches what was built.

What is DICE in hardware security?

DICE, the Device Identifier Composition Engine from the Trusted Computing Group, gives small components a cryptographic identity tied to the firmware they booted. A hardware secret is combined with a measurement of each firmware layer to derive that layer's identity, so changed firmware produces a different identity. Root of trust designs such as Caliptra use it.

What is Caliptra?

Caliptra is an open source silicon root of trust specification, RTL, ROM and firmware for data center chips such as CPUs, GPUs and DPUs. It started at the Open Compute Project and is developed in the CHIPS Alliance. It gives a chip a DICE based identity, measured boot and attestation.

How do I check firmware versions on a new server?

Query the BMC's Redfish UpdateService/FirmwareInventory collection, then cross check from the host with dmidecode, fwupdmgr get-devices, in band ipmitool mc info, ethtool -i for NICs and nvme id-ctrl or smartctl -i for drives. Compare the versions with the vendor's current security baseline before the server goes into production.

Does an HBOM include firmware?

CISA's HBOM framework covers hardware components and can record the provider of each component's firmware, but the framework itself says it stops short of firmware provenance. For firmware contents, ask the vendor for software SBOMs of the BIOS and BMC images.

Where Safeguard fits

Most of this post is hardware, factory process and firmware, and Safeguard does not do that work: it does not scan firmware binaries, generate HBOMs, attest platforms or manage servers and BMCs. The fit is narrower and practical. The tooling that runs your acceptance process, such as Redfish inventory scripts, platform certificate validation services, provisioning containers and any operator built BMC tree, is ordinary software with open source dependencies, and Safeguard scans that with safeguard scan --dir . for a repository or --image for a container image. If a vendor hands you a BIOS or BMC firmware SBOM in SPDX or CycloneDX, safeguard scan --sbom <file> matches the listed components against vulnerability databases. That checks the vendor's list, not the firmware binary, so it is only as complete as the SBOM you were given.

A newly racked server also pulls a full operating system, agents and container images the moment it is provisioned, and that software ages from day one. The patch discipline you apply to firmware baselines applies just as much to the open source packages and images that land on the server after it boots.

Fix it without waiting for upstream

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 demos below show Safeguard on ordinary software projects, not on server hardware or firmware. They apply to the code your infrastructure team writes around server acceptance: the Python or Go tools that query Redfish, the services that validate platform certificates, and the container images that run your provisioning jobs.

The first demo is a real Safeguard CLI session. After install, safeguard opens the interactive terminal, you ask it to fix the lodash CVE in a repository, 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. Point the same flow at your inventory or provisioning repository and it proposes the dependency fix and runs your tests before anything is committed.

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

Acceptance and BMC networks are usually isolated, as they should be. The local runner demo shows how to set up the runner on your own machine, approve it with its device code, and then scan from the terminal. A runner on a build host or jump host inside that zone can scan the provisioning tooling that lives there without opening the network to the outside.

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

If your team uses Claude, the third demo shows how to connect Claude to the Safeguard MCP server with OAuth and choose which tools Claude can use. An engineer can then ask about vulnerabilities in the projects that hold your acceptance tooling, using only the tools you allowed.

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

To try it on your own repositories, download Safeguard and follow the CLI documentation.

Quick check

Sources

• NIST, SP 800-193 Platform Firmware Resiliency Guidelines (May 2018)
• NIST, SP 800-193 full text (PDF)
• NIST, SP 800-147B BIOS Protection Guidelines for Servers (August 2014)
• NIST, SP 800-147B full text (PDF)
• NIST, SP 800-161 Rev. 1 Cybersecurity Supply Chain Risk Management Practices (May 2022, updated November 2024)
• CISA, Hardware Bill of Materials (HBOM) Framework for Supply Chain Risk Management (25 September 2023)
• CISA, CISA and NSA Release Joint Guidance on Hardening Baseboard Management Controllers (14 June 2023)
• Trusted Computing Group, TCG Platform Certificate Profile page (archived copy)
• Trusted Computing Group, TCG Platform Certificate Profile Version 2.0 Revision 39 (29 July 2024, archived PDF)
• Trusted Computing Group, DICE work group page (archived copy)
• Open Compute Project, DC-SCM Specification Revision 1.0 (11 March 2021)
• Open Compute Project, Hardware Management Module wiki
• Open Compute Project, S.A.F.E. program
• Open Compute Project, Server Mezzanine and NIC 3.0 specifications
• CHIPS Alliance, Caliptra repository README
• CHIPS Alliance, Caliptra specification, revision 2.1
• DMTF, Redfish Specification DSP0266 version 1.25.0 (7 August 2026)
• DMTF, Redfish SoftwareInventory schema v1.15.0
• DMTF, SPDM Specification DSP0274 version 1.4.1 (26 June 2026)
• DMTF, SMBIOS Specification DSP0134 version 3.8.0 (5 August 2024)
• NSA Cybersecurity, HIRS README
• NSA Cybersecurity, paccor README
• fwupd, project README
• fwupd, fwupdmgr manual
• LVFS, Introduction
• dmidecode, project page
• ipmitool, README

Last reviewed: 23 October 2026. Firmware baselines, specifications and vendor programs change often; check the linked specifications and your server vendor's documentation for the versions that apply to your hardware.