HBOM Requirements for Procurement: What to Ask Hardware Suppliers

To buy hardware safely, ask every supplier for a hardware bill of materials (HBOM) that names each component, its manufacturer and part number, where it was made and assembled, its date or lot code, and the firmware it runs. Then put the rules around that data in the contract: Section 889 and the FCC Covered List, counterfeit part controls, end of life notice, and a dated firmware update commitment.

This post is the procurement companion to our hardware series. It assumes you know what an HBOM is (our HBOM vs SBOM explainer covers that) and focuses on the buying side: which regulations actually create obligations, which HBOM fields answer each obligation, what contract language looks like, what to check when the pallet arrives, and how to score suppliers so the answers change who you buy from. Every regulatory statement below was checked against the text on acquisition.gov, fcc.gov, the EU Publications Office (the official source behind EUR-Lex) and CISA, as fetched on 23 October 2026. The templates are illustrative starting points, not legal advice; have counsel adapt them to your contracts and jurisdiction.

Key takeaways

• The CISA HBOM Framework is voluntary. It tells buyers which fields to request for which use case, and says plainly that using it does not mean you have complied with any regulation.
• Section 889 is the hard US federal rule for telecom and video surveillance gear. FAR 52.204-25 bars covered equipment as a "substantial or essential component" and requires a report within one business day, with brand, model and part number.
• The FCC Covered List keeps growing. Since December 2025 it has added foreign produced drones, routers, power inverters and advanced robotic devices, each with conditional approval exceptions.
• DFARS 252.246-7007 and 7008 set the defense bar for counterfeit parts: buy from original manufacturers or authorized suppliers first, trace parts to acceptance, report suspect parts to GIDEP.
• The EU Cyber Resilience Act covers hardware. At least five years of support in most cases, the end month and year stated at purchase, updates kept available for 10 years, and an SBOM. Reporting applies since 11 September 2026; the rest from 11 December 2027.
• Attestations go stale; HBOMs do not. Restricted lists change, so ask for data you can recheck, not a signed letter.
• Score with gates first, weights second. A failed Section 889 answer is a stop, not a low score.

Timeline: the rules behind hardware procurement requirements

Why procurement is where hardware transparency gets decided

Software teams can generate an SBOM from source or a container image after the fact. Hardware buyers cannot. You cannot work out the fab, the assembly site, the lot code or the sub-tier distributor of a chip by looking at a finished server. That information lives only in the supplier's records, and your bargaining power to get it peaks before the purchase order is signed.

CISA's framework recommends requesting HBOMs as one of many supply chain checks, alongside security questionnaires and SBOM requests, and admits formats are not yet fully interoperable. So the buyer has to specify fields in writing; "send us your HBOM" will not produce comparable answers.

Most hard obligations here fall on whoever sells to a regulated buyer: the federal contractor carries Section 889 reporting, the defense contractor the counterfeit parts system, the EU manufacturer the CRA. If that is you, your suppliers' data is your evidence. If it is not, the same rules still give you a well tested checklist.

What the regulations actually require

This section sticks to what each text says. Scope matters, because a requirement copied into a contract out of context can bind a supplier to something that does not fit.

Section 889 and FAR 52.204-25

FAR 52.204-25 (November 2021 version) implements Section 889 of the FY2019 National Defense Authorization Act. Covered telecommunications equipment means telecom equipment produced by Huawei Technologies Company or ZTE Corporation, and, for public safety, government facility security, surveillance of critical infrastructure and other national security purposes, video surveillance and telecom equipment produced by Hytera, Hikvision or Dahua. Subsidiaries and affiliates are included, as is equipment from entities the Secretary of Defense reasonably believes are connected to the government of the People's Republic of China.

Three parts of the clause shape what you ask a supplier.

The prohibition. The contractor may not provide equipment, systems or services that use covered equipment "as a substantial or essential component of any system". That term means any component "necessary for the proper function or performance" of the equipment. It is about function, not price or size, so a small radio module can qualify. Only a component level list can answer the question.

The exceptions. Services that connect to third party facilities (backhaul, roaming, interconnection) are excluded, as is telecom equipment that "cannot route or redirect user data traffic or permit visibility into any user data or packets". A supplier relying on the second exception should say so per component, with the reason.

The reporting duty. If the contractor finds covered equipment during performance, or a subcontractor at any tier tells it, it must report within one business day: contract and order numbers, supplier name, unique entity identifier and CAGE code if known, brand, model number (OEM number, manufacturer part number or wholesaler number), item description and available mitigation. Within 10 more business days it adds mitigation details and prevention efforts. Defense contractors report through DIBNet. The clause flows down to all subcontracts, including for commercial products.

That reporting list is a list of HBOM fields. A supplier that cannot give you brand, model and part number for components cannot help you meet a one business day clock.

The companion provisions are where offerors make statements you can rely on. FAR 52.204-26 (October 2020) has the offeror check SAM's excluded parties list and represent whether it does or does not provide, and, after a reasonable inquiry, use, covered equipment. FAR 52.204-24 is the fuller disclosure when it cannot say "does not". A reasonable inquiry is designed to uncover information "in the entity's possession" and "excludes the need to include an internal or third-party audit". The federal standard is what the company already knows; an HBOM request is how a buyer makes sure it knows enough.

The FCC Covered List

The FCC publishes the Covered List under the Secure and Trusted Communications Networks Act of 2019 and 47 CFR 1.50002: equipment and services "deemed to pose an unacceptable risk to the national security of the United States". The version we fetched is dated 21 October 2026. Besides the five Section 889 manufacturers (added 12 March 2021), several telecom service providers and some software entries, it now has category entries:

• uncrewed aircraft systems and critical components produced in a foreign country (22 December 2025), with time limited exceptions for Blue UAS Cleared List items and qualifying domestic end products, plus conditional approvals;
• routers produced in a foreign country (23 March 2026), except those granted a conditional approval;
• foreign produced power inverters and advanced robotic devices (28 July 2026), with conditional approval exceptions.

Two consequences follow. Country of production now matters for whole product categories, which makes HBOM location fields directly relevant. And the list moves, so your contract should require notice when a delivered item becomes covered, not just a certification on the day of sale. Scope questions about category entries belong with counsel.

DFARS 252.246-7007 and 252.246-7008: counterfeit electronic parts

DFARS 252.246-7007 (January 2023) applies its main paragraphs only to contractors subject to the Cost Accounting Standards. They must keep "an acceptable counterfeit electronic part detection and avoidance system"; failure can mean purchasing system disapproval, withheld payments and disallowed costs. Its definitions are the most useful text in this area for writing HBOM requirements. A counterfeit part includes "used electronic parts represented as new, or the false identification of grade, serial number, lot number, date code, or performance characteristics". Of its twelve system criteria, the ones that become supplier asks are risk based inspection and testing, traceability "from the original manufacturer to product acceptance", quarantine and reporting of suspect parts to the contracting officer and GIDEP (with no return to the supply chain until authenticity is settled), flow down to all tiers that buy, sell or test electronic parts, screening of GIDEP reports, and control of obsolete parts.

DFARS 252.246-7008 (January 2023) sets the sourcing order. Contractors first buy from original manufacturers, their authorized suppliers, or suppliers that buy only from those two. Only then may they use contractor approved suppliers, vetted with established counterfeit prevention standards, taking responsibility for authenticity. Any other source, or any part that cannot be confirmed new and not commingled with used or returned stock, requires written notice to the contracting officer plus inspection, testing and authentication. Contractors that are neither the original manufacturer nor an authorized supplier need risk based traceability, or authentication records where traceability fails.

Together these name the HBOM fields counterfeit avoidance depends on: original manufacturer, manufacturer part number, actual supplier, whether it was authorized, and date or lot code. Our post on hardware and firmware inventory shows where those fields sit in a real inventory.

The EU Cyber Resilience Act

Regulation (EU) 2024/2847 defines a "product with digital elements" as "a software or hardware product and its remote data processing solutions", including components sold separately. Routers, cameras, controllers and laptops sold in the EU are in scope, subject to its exclusions. The obligations that matter to buyers:

• Third party components (Article 13(5)). Manufacturers must exercise due diligence when integrating third party components.
• Support period (Article 13(8)). Set to reflect expected use, and "at least five years" unless the product is expected to be used for less.
• Update availability (Article 13(9)). Each security update stays available for at least 10 years after issue, or the rest of the support period if longer.
• End date at purchase (Article 13(19)). The support end date, "including at least the month and the year", must be clear at the time of purchase.
• Vulnerability handling (Annex I, Part II). Manufacturers must "identify and document vulnerabilities and components", including an SBOM "in a commonly used and machine-readable format covering at the very least the top-level dependencies", ship security updates separately from feature updates where feasible, distribute them securely and free of charge.
• User information (Annex II). A vulnerability contact, the support end date, secure decommissioning instructions and, only if the manufacturer chooses to share it, where the SBOM can be found.

Article 14 reporting of actively exploited vulnerabilities has applied since 11 September 2026; the rest applies from 11 December 2027. Note what the CRA does not do: it does not require the manufacturer to hand the buyer an SBOM or an HBOM. If you want them, ask in the contract.

The CISA HBOM Framework and NIST SP 800-161

The CISA framework (25 September 2023) groups use cases into compliance, security and availability. It names FY2019 NDAA Section 889 as a government compliance use case and lists adherence to product change notices (PCNs) and buying only from OEM authorized vendors as internal quality use cases. Two footnotes belong in any procurement policy: the examples are not legal advice, and use of the framework "does not mean that a company has complied with any U.S. regulations". It also leaves SBOMs out of scope and, for firmware, records only basics such as the provider. So a complete request needs an HBOM, a firmware SBOM per component and an update commitment.

NIST SP 800-161 Rev 1 (May 2022, updated 1 November 2024) gives control language to cite. SR-4 asks for documented provenance and calls SBOMs "complementary, not substitutive" to vendor assessments. SR-11 says anti-counterfeit policy should address contract clauses and reporting to bodies such as GIDEP, and that authenticity "should be addressed in contracts when procuring component servicing and repair support". SA-22 recommends authorized distributors for unsupported components. SR-6 covers supplier assessments and SR-13 a supplier inventory.

Which rule needs which HBOM field

This is the table to hand your sourcing team. Field names are from Appendix C of the CISA framework; CycloneDX property names are from the official cdx:device taxonomy.

Two points from the framework shape this table. Where a field has no 1:1 mapping, such as a single "country of origin" field versus CISA's several location fields, the person building conversion tooling has to choose a mapping. Where a field does not exist, the producer should create a user defined field and agree its meaning with the requester. Put those agreements in an exhibit to the contract so they survive staff changes on both sides.

For a deeper look at how CycloneDX separates the physical part from the code that runs on it, see CycloneDX component types for firmware and devices and our IoT guide to hardware and software in one BOM.

How to ask about country of origin without getting a useless answer

"Country of origin" is the field buyers most often get wrong. A single customs country for the finished good says nothing about where the radio chip was fabricated or the board assembled. The CISA framework splits location into separate fields: main and alternative finished good manufacturing locations, component manufacturing location, and assembly and test location, each with an ISO 3166 country and subdivision code (its example is "US-MA"). For semiconductors it recommends recording the supplier and the fab or foundry as separate data points.

Make each of those a separate column, and ask for alternative sites, since many products are built in more than one place. CISA's worked example gives you the negotiating argument: because restriction lists change, "an attestation of compliance from a supplier is not helpful except for a specific point in time", while an HBOM stays useful when listings are amended.

Also ask for entity identifiers (unique entity identifier, CAGE code) and the parent company, not names alone. The framework's Appendix D notes that Section 889 restrictions reach subsidiaries and affiliates, and that entity names suffer from abbreviations, rebrands and mergers.

End of life, change notices and the support period

Hardware fails security quietly in two ways: the part you qualified changes without notice, or the product stops getting firmware fixes while it is still in your racks. Both are contract problems first.

Product change notices. Require written notice before any change to form, fit, function, manufacturing site or sub-tier source of an HBOM listed component, with an updated HBOM. CISA lists adherence to PCNs as a quality use case and suggests a new HBOM whenever the vendor changes a product's version.

End of life and last time buy. Require a minimum notice period, a last time buy window and the authorized source for continued supply. DFARS 252.246-7007 makes control of obsolete parts a system criterion, and 252.246-7008 shows why: once parts leave production, buyers drift to unvetted sources. NIST SA-22 says to use authorized distributors for unsupported components.

Security support period. For EU sales from 11 December 2027, the CRA sets a floor: usually five years or more, an end month and year at purchase, updates kept available for 10 years. Ask every supplier for the same, per model, in the quote. Our post on why firmware below the OS goes unpatched explains why a dated support period matters most for firmware.

Firmware update commitments to ask for

An HBOM tells you what is in the box. It does not tell you whether the code in each part will be fixed. Ask for these separately:

1. A firmware SBOM per firmware component, per release. The CRA requires manufacturers to draw up an SBOM covering at least top level dependencies, but leaves sharing it to them. Ask for CycloneDX or SPDX, machine readable, delivered with each firmware release.
2. Security fixes separate from feature updates where technically feasible, matching CRA Annex I Part II point (2), so you can patch without accepting functional change.
3. Free security updates during the support period, with advisory messages, matching Annex I Part II point (8).
4. Machine readable advisories, such as CSAF, and VEX statements for "not affected" decisions, so you can triage upstream library advisories without a support ticket.
5. A signed update channel, with the signing approach and rollback protection described. Our motherboard evolution post covers where BIOS, UEFI, TPM and BMC firmware live.
6. A coordinated vulnerability disclosure policy and a contact address, both of which the CRA requires the manufacturer to publish.
7. Notification of actively exploited vulnerabilities affecting delivered products, on a stated timeline. The CRA's 24 and 72 hour clocks run to EU authorities, not to you; your contract has to create the customer notification.

Contract clause template

The following is an illustrative clause set for a hardware purchase agreement or master supply agreement. It is not legal advice. Clauses that implement FAR or DFARS requirements must use the exact regulatory text your contracting officer specifies, and the bracketed items need to be set by your legal and sourcing teams.

EXHIBIT [X]: HARDWARE TRANSPARENCY AND SUPPLY CHAIN SECURITY
(Illustrative template. Not legal advice. Adapt with counsel.)

1. Definitions.
   "HBOM" means a hardware bill of materials for each Deliverable, nested to
   the level set out in Schedule 1, using the field names in Appendix C of
   CISA's "A Hardware Bill of Materials Framework for Supply Chain Risk
   Management" (September 2023), or the agreed CycloneDX mapping in Schedule 2.
   "Firmware SBOM" means a software bill of materials, in CycloneDX or SPDX
   machine-readable format, for each firmware image shipped on a Deliverable.
   "Covered Item" means any equipment or service that is covered
   telecommunications equipment or services under FAR 52.204-25, or that
   appears on the FCC Covered List, as either is amended from time to time.

2. HBOM delivery.
   2.1 Supplier shall deliver an HBOM for each Deliverable model and revision
       with its quotation and again before first shipment.
   2.2 The HBOM shall include, at minimum, the fields marked "Required" in
       Schedule 1, including manufacturer, manufacturer part number, supplier
       (where not purchased from the manufacturer), manufacturing location,
       assembly and test location, ISO 3166 location codes, and lot or date
       code where the part carries one.
   2.3 Supplier shall deliver an updated HBOM within [30] days of any change
       to a listed component, manufacturing site or sub-tier supplier, and in
       any case with each new product revision.
   2.4 Each HBOM shall be delivered with a SHA-256 digest and a detached
       signature verifiable with a key identified in Schedule 3.

3. Restricted sources.
   3.1 Supplier represents that no Deliverable contains a Covered Item as a
       substantial or essential component, as those terms are defined in
       FAR 52.204-25, except as disclosed in writing and accepted by Buyer.
   3.2 Supplier shall notify Buyer within [1] business day of identifying,
       or being notified by any sub-tier supplier of, a Covered Item in a
       Deliverable, including brand, model number, manufacturer part number,
       supplier identity and available mitigation, and shall provide further
       mitigation details within [10] business days.
   3.3 Supplier shall notify Buyer within [5] business days if a Deliverable
       or a component listed in its HBOM becomes a Covered Item after delivery.

4. Authentic parts.
   4.1 Supplier shall obtain electronic parts from the original manufacturer,
       its authorized suppliers, or suppliers that obtain parts exclusively
       from those sources, and shall identify in the HBOM any part obtained
       otherwise.
   4.2 Supplier shall maintain traceability records from the original
       manufacturer to delivery for [all / critical] electronic parts, or
       inspection, testing and authentication records where traceability
       cannot be established, and shall provide them on request.
   4.3 Supplier shall quarantine and report suspect counterfeit parts to Buyer
       within [X] days and shall not return them to the supply chain until
       authenticity is determined. [Where DFARS 252.246-7007/7008 apply,
       those clauses govern and are incorporated by reference.]

5. Lifecycle.
   5.1 Supplier shall state, per Deliverable model, the end date (month and
       year) of the security support period, which shall be no shorter than
       [5] years from [first shipment / Buyer acceptance].
   5.2 Supplier shall give at least [12] months' written notice of end of
       life or end of sale for any Deliverable or HBOM-listed critical
       component, with a last-time-buy window of at least [6] months.
   5.3 Supplier shall give at least [90] days' written notice of any change
       to form, fit, function, manufacturing site or sub-tier source of an
       HBOM-listed critical component.

6. Firmware and vulnerabilities.
   6.1 Supplier shall deliver a Firmware SBOM with each firmware release.
   6.2 During the support period, Supplier shall provide security updates
       free of charge, separately from functionality updates where
       technically feasible, through a signed update mechanism.
   6.3 Supplier shall publish machine-readable security advisories (for
       example CSAF) and shall provide VEX statements on request.
   6.4 Supplier shall notify Buyer of any actively exploited vulnerability
       affecting a Deliverable within [72] hours of becoming aware of it.
   6.5 Supplier shall keep each security update available for download for
       at least [10] years after release or the remainder of the support
       period, whichever is longer.

7. Flow down and audit.
   7.1 Supplier shall flow down the substance of sections 2 to 6 to sub-tier
       suppliers of HBOM-listed critical components.
   7.2 Buyer may audit compliance with this Exhibit on [30] days' notice,
       no more than [once] per year, and at any time after a reported
       incident.

8. Remedies.
   Failure to deliver a conforming HBOM or Firmware SBOM is a material
   nonconformity. [Set remedies: withhold acceptance, cure period,
   replacement at Supplier cost, termination right.]

A few drafting notes. Clause 3.1 copies the federal concepts deliberately so that a commercial supplier who also sells to the government can reuse evidence it already has. Clause 4 paraphrases the DFARS sourcing order for commercial use; it does not replace the clauses themselves where they apply. Clause 5.1 mirrors the CRA floor so that the same exhibit works for EU and non EU purchases. Clause 6.4 exists because no regulation creates a direct notification duty to you.

Supplier questionnaire template

Send this with the RFP. Each question has the evidence you should accept and how it scores. Again, this is an illustrative template.

Keep it short. Seventeen pointed questions with evidence requests beat a hundred checkboxes filled in from memory.

How to score hardware suppliers

Use a two stage model: gates, then weighted scores.

Stage 1: gates. G1, G2 and G3 are pass or fail. A "yes" to G1 or G2 without an applicable exception or approval removes the offer, regardless of price. A refusal to provide any HBOM (G3) also removes it for critical systems; for low risk peripherals you might accept a later delivery date in writing.

Stage 2: weighted score. Score each remaining question 0 to 3, then weight by category.

Then set thresholds by system criticality. A reasonable starting point: 2.5 or higher for systems that would stop operations or touch regulated data, 1.5 or higher for general IT, and anything for disposable peripherals. Record the score with the award decision, and rescore at renewal. NIST SP 800-161 SR-6 (supplier assessments and reviews) and SR-13 (supplier inventory) give you the control language to hang this on.

Do not average away a bad answer: a 3 on lifecycle does not fix a 0 on sourcing, so check category minimums too. And score evidence, not claims. If H3 says lot codes are recorded but the sample HBOM has none, score the sample.

Step by step: acceptance checks when hardware arrives

Requirements only work if someone checks them. These steps assume the supplier delivers a CycloneDX JSON HBOM with a SHA-256 digest and a detached signature, and that you received the public key out of band. Adapt the paths and tools to your environment. Nothing here modifies the device.

1. Verify the HBOM file you received is the one the supplier signed

# Compare the delivered digest with one you compute
sha256sum hbom-model-x200-rev3.cdx.json
cat hbom-model-x200-rev3.cdx.json.sha256

# Verify a detached signature with a key received out of band
# (example using OpenSSL with an RSA or ECDSA public key)
openssl dgst -sha256 -verify supplier-hbom-signing.pub \
  -signature hbom-model-x200-rev3.cdx.json.sig \
  hbom-model-x200-rev3.cdx.json

2. Validate the file against the CycloneDX schema

# Using the official CycloneDX CLI
cyclonedx validate --input-file hbom-model-x200-rev3.cdx.json \
  --input-format json --fail-on-errors

A schema pass only proves structure. It says nothing about whether the content is complete, which is what the next steps check.

3. Check required fields are present

# Hardware components missing a manufacturer or part number property
jq -r '.components[]
  | select(.type == "device")
  | select((.manufacturer == null) or
           ([.properties[]? | select(.name == "buyer:hbom:manufacturer_pn")] | length == 0))
  | .name' hbom-model-x200-rev3.cdx.json

# Components with no lot number recorded
jq -r '.components[]
  | select(.type == "device")
  | select([.properties[]? | select(.name == "cdx:device:lotNumber")] | length == 0)
  | .name' hbom-model-x200-rev3.cdx.json

The buyer:hbom: prefix stands for whatever user defined property names you agreed with the supplier in the contract schedule. The CISA framework expects exactly this kind of agreed field where a format has no native equivalent.

4. Screen manufacturers and locations against your restricted list

# restricted.txt: one manufacturer or entity name per line, maintained by
# compliance from the FCC Covered List and your own policy
jq -r '.components[] | [.name, (.manufacturer.name // "UNKNOWN")] | @tsv' \
  hbom-model-x200-rev3.cdx.json | grep -i -F -f restricted.txt

# List every manufacturing and assembly location code for review
jq -r '.components[]
  | [.name, ([.properties[]? | select(.name|test("loc_code")) | .value] | join(","))]
  | @tsv' hbom-model-x200-rev3.cdx.json | sort -k2

String matching finds only exact names. CISA's Appendix D is blunt about entity resolution: names vary, companies rebrand, and restrictions extend to subsidiaries and affiliates. Treat a clean grep as "no obvious match", not as clearance, and keep the review with someone who knows the corporate structures involved.

5. Compare a delivered unit with its HBOM

On a sample of received units, boot a known clean live environment and collect what the hardware reports about itself, then compare with the HBOM rows.

# Board, system firmware and memory part numbers (Linux, as root)
dmidecode -t baseboard -t bios -t memory | grep -E 'Manufacturer|Product Name|Version|Part Number|Serial'

# PCI devices with vendor and device IDs
lspci -nn

# Storage model and firmware revision
nvme list

# NIC driver and firmware version
ethtool -i eth0

Mismatches are not automatically counterfeit. Suppliers substitute approved alternates, and the CISA framework has fields for alternative manufacturers for that reason. But every mismatch should either map to a disclosed alternate in the HBOM or trigger a question to the supplier before acceptance. For a fuller collection walkthrough, including Windows and Redfish, see hardware and firmware inventory from chips to boards.

6. Record the result and the firmware baseline

Store the HBOM, its digest, the acceptance results and the observed firmware versions against the asset record. Load the firmware SBOMs the supplier gave you into whatever system you use for software composition analysis, so a future library advisory can be matched to the devices that carry it.

Procurement lifecycle: who asks for what, and when

Where Safeguard fits, honestly

Safeguard does not generate HBOMs, collect hardware inventories, verify part authenticity, screen entities against government lists or inspect firmware binaries. The procurement controls in this post belong to your sourcing, legal, compliance and receiving teams, and the hardware facts come from your suppliers.

The overlap is on the software side of the same supplier relationship. Safeguard's Third Party Risk Manager, which is generally available, lets you onboard vendors and request SBOMs from them, including the firmware SBOMs this post tells you to require. Once a supplier's SBOM is in Safeguard, it can be analysed like any other SBOM: components are matched against vulnerability databases, and you can see which of your products contain a given component and version. Safeguard also accepts CSAF and VEX uploads, so a supplier's "not affected" statements can sit next to the SBOM they apply to. All of that depends on what the supplier declares. Safeguard does not discover what is inside a firmware image on its own.

Common mistakes

• Asking for "an HBOM" without a field list. You will get a spreadsheet of finished goods. Name fields, nesting depth and format in a schedule.
• Accepting one country of origin. Ask for fabrication, assembly and test locations separately, with ISO codes.
• Treating a compliance letter as durable. The 2025 and 2026 Covered List additions show lists move. Require notice when a delivered item becomes covered.
• Copying DFARS clauses into commercial contracts unchanged. 7007's main paragraphs apply only to contractors under the Cost Accounting Standards. Paraphrase the intent; incorporate the real clauses only where they apply.
• Forgetting sub-tier suppliers. Section 889 reporting and DFARS both reach lower tiers. Flow your exhibit down too.
• No firmware terms. An HBOM without firmware SBOMs and update commitments tells you what you bought, not whether it stays patched.
• Schema validation as acceptance. A valid file can still lack the fields you need.
• Scoring claims instead of samples. Ask for a real HBOM for one offered model and score that.

FAQ

What should I ask a hardware supplier for in an HBOM?

For each component: manufacturer, manufacturer part number, the actual supplier if different, type, version (including firmware version), manufacturing and assembly and test locations with ISO 3166 codes, and lot or date code. For semiconductors, ask for the fab or foundry separately. Use CISA Appendix C field names so answers compare.

Is an HBOM legally required for US federal procurement?

No general rule requires one, and the CISA framework is voluntary. But FAR 52.204-25 requires reports with brand, model and part number within one business day, and DFARS 252.246-7008 requires parts traceability in defense contracts. An HBOM is the practical way to have that data ready.

What does FAR 52.204-25 prohibit?

Providing the government any equipment, system or service that uses covered telecommunications equipment or services as a substantial or essential component, or as critical technology. Covered equipment includes telecom gear from Huawei and ZTE and, for specified security purposes, video surveillance and telecom gear from Hytera, Hikvision and Dahua, including affiliates.

Does the FCC Covered List apply to routers?

Yes, in its 21 October 2026 version: routers produced in a foreign country were added on 23 March 2026, except those granted a conditional approval. Check the live page and get counsel's view on scope.

What do DFARS 252.246-7007 and 252.246-7008 require?

7007 requires contractors subject to the Cost Accounting Standards to run a counterfeit electronic part detection and avoidance system with twelve criteria, including traceability and GIDEP reporting. 7008 sets the sourcing order, original manufacturers and authorized suppliers first, and requires notice when parts come from elsewhere.

How long must hardware get security updates under the EU Cyber Resilience Act?

The support period must reflect expected use and be at least five years unless the product is expected to be used for less. Its end month and year must be stated at purchase, and each security update must stay available for at least 10 years or the rest of the support period, whichever is longer. This applies from 11 December 2027.

Does the Cyber Resilience Act require suppliers to give buyers an SBOM?

No. Manufacturers must draw up an SBOM covering at least top level dependencies, but sharing it with users is their choice. Put SBOM delivery in your contract.

How do I score hardware suppliers on supply chain security?

Apply pass or fail gates first (covered equipment, Covered List status, willingness to deliver an HBOM), then score HBOM quality, sourcing, lifecycle and firmware security 0 to 3 with weights. Set thresholds by criticality and check category minimums.

Can Safeguard generate an HBOM for my hardware?

No. Safeguard does not generate HBOMs or inspect hardware. On the software side, its Third Party Risk Manager can request SBOMs from suppliers, it analyses those SBOMs against vulnerability data, and it accepts CSAF and VEX uploads.

Fix it without waiting for upstream

Hardware procurement and software supply chain hygiene meet at the firmware SBOM: the BMC, NIC and storage images you just required suppliers to document are built from open source components, and so are the inventory scripts, asset databases and agents you run on the hardware. The fit with hardware itself is indirect; nothing below changes a chip or a firmware image, but it keeps the open source software you build and ship on top of 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 connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. For this topic, the useful question afterwards is a reverse lookup: once a supplier's firmware SBOM is in your Safeguard inventory, you can ask which of your products contain a component that a new advisory names. The answer is only as complete as the SBOM the supplier delivered.

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 its device code and runs scans from the terminal. That fits a procurement or receiving workflow where supplier SBOMs arrive under NDA and you would rather scan them on a workstation you control.

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

The third 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 acceptance scripts and asset tooling in this post, which carry open source dependencies of their own.

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

• FAR 52.204-25, Prohibition on Contracting for Certain Telecommunications and Video Surveillance Services or Equipment
• FAR 52.204-24, Representation Regarding Certain Telecommunications and Video Surveillance Services or Equipment
• FAR 52.204-26, Covered Telecommunications Equipment or Services, Representation
• DFARS 252.246-7007, Contractor Counterfeit Electronic Part Detection and Avoidance System
• DFARS 252.246-7008, Sources of Electronic Parts
• FCC, List of Equipment and Services Covered by Section 2 of the Secure Networks Act (Covered List)
• Regulation (EU) 2024/2847, Cyber Resilience Act, on EUR-Lex
• Regulation (EU) 2024/2847, official text from the EU Publications Office
• CISA, Hardware Bill of Materials (HBOM) Framework for Supply Chain Risk Management (publication page)
• CISA, A Hardware Bill of Materials Framework for Supply Chain Risk Management (PDF)
• NIST SP 800-161 Rev 1, Cybersecurity Supply Chain Risk Management Practices (publication page)
• NIST SP 800-161 Rev 1 Update 1 (PDF)
• CycloneDX, Hardware Bill of Materials capability
• CycloneDX property taxonomy, cdx:device namespace

Last reviewed: 23 October 2026. Regulations and the FCC Covered List change; check the linked official texts before relying on any requirement.