HBOM in Regulated Industries: Medical, Automotive, Defense, Telecom

No regulator in medical devices, automotive, defense or telecom requires a file called an HBOM today. They require evidence an HBOM makes easy: FDA wants an SBOM per cyber device, UN R155 and R156 want supplier risk managed and hardware tied to software versions, DFARS wants parts traced to their maker, and FAR and the FCC ban equipment by producer.

The practical answer is one hardware bill of materials (HBOM) linked to firmware and software SBOMs, exported in the slice each regulator asks for. This post quotes what each sector's rules say and ends with a step by step build. For background, see HBOM vs SBOM and hardware and firmware inventory from chips to boards; the software side of each sector is linked in its section below.

Key takeaways

• No sector rule names the HBOM as a deliverable. The rules ask about SBOMs, supplier risk, part sourcing and prohibited producers; an HBOM answers them.
• FDA: section 524B, effective 29 March 2023, requires an SBOM for cyber devices. The February 2026 guidance treats firmware and programmable logic as software and counts USB, Ethernet and serial ports as internet connectivity.
• Automotive: UN R155 requires supplier related risks to be identified and managed per vehicle type. UN R156 requires software versions and "relevant hardware components" to be uniquely identified.
• Defense: DFARS 252.246-7007 and 7008 require electronic parts traced to the original manufacturer and bought from authorized sources first. CMMC is not a hardware rule and is paused in Phase 1.
• Telecom: FAR 52.204-25 bans five named producers' equipment for federal buyers. The FCC Covered List now also lists foreign produced routers, drones, power inverters and robotic devices.
• EU: the CRA covers hardware products, requires an SBOM of at least top level dependencies, applies in full from 11 December 2027, and excludes medical devices, type approved vehicles and defence only products.
• Build once, export many. One HBOM keyed by part number, producer, source type, country of production and firmware link answers every regulator here.

Timeline: the rules that touch hardware data

Sector comparison: what each regulator asks for

Every sector asks some version of "what is inside, who made it, where did it come from, and how long will it be supported." SBOMs answer the software half. The hardware half usually still lives in spreadsheets exported from ERP or product lifecycle systems.

Does any regulator require an HBOM by name?

Not yet, in any of the texts we checked. CISA's HBOM Framework, published on 25 September 2023, is guidance for buyers and suppliers, not a regulation. CISA describes it as providing "a consistent naming methodology for attributes of components" and guidance on which HBOM information fits which purpose. It is a shared vocabulary that procurement teams and suppliers can adopt voluntarily.

If you wait for a mandate, you will build the record under deadline when an auditor or contracting officer asks a hardware question. Built now from engineering and procurement data, each request becomes a filtered export.

CycloneDX already supports this. Its HBOM capability page says the format can represent "processors, embedded systems, IoT devices, and industrial control systems," with hardware attributes documented "alongside associated firmware and configurations." Our post on one bill of materials for IoT devices shows how to keep hardware and software in a single document.

Medical devices: FDA section 524B and the 2026 guidance

For the full software story, read our post on FDA premarket cybersecurity and SBOM requirements in 2026. Here we focus on where hardware enters the FDA's thinking.

What the law requires

Section 3305 of FDORA, enacted on 29 December 2022, added section 524B to the FD&C Act. Since 29 March 2023, a 510(k), PMA, PDP, De Novo or HDE for a "cyber device" must show the device meets section 524B(b).

Section 524B(c) defines a cyber device as one that includes software validated, installed or authorized by the sponsor, has the ability to connect to the internet, and contains technological characteristics that could be vulnerable to cybersecurity threats. Section 524B(b)(3) then requires the manufacturer to provide an SBOM "including commercial, open-source, and off-the-shelf software components."

What the guidance says about the SBOM

The current guidance is titled "Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions." Issued on 3 February 2026 under docket FDA-2021-D-1158, it supersedes the 27 June 2025 version.

For each submission, FDA recommends machine readable SBOMs consistent with the minimum elements in the October 2021 NTIA document "Framing Software Component Transparency." On top of those, for every software component, FDA asks for:

• The level of support from the component's maker, for example actively maintained, no longer maintained or abandoned.
• The component's end of support date.

FDA also asks for all known vulnerabilities in the device and its components, including those in CISA's Known Exploited Vulnerabilities Catalog.

Note that the guidance still cites the 2021 NTIA minimum elements, although CISA published newer 2026 minimum elements in July 2026. Cover both until FDA updates its reference.

Where hardware shows up

Hardware appears in four places an HBOM supports.

Firmware and programmable logic are software. FDA says it considers a cyber device "to include devices that are or contain software, including software that is firmware or programmable logic." Any FPGA bitstream or radio firmware belongs in the SBOM, and its chip in the HBOM.

Hardware interfaces count as internet connectivity. FDA treats a device as able to connect to the internet if it has network or cloud connections, radio links such as Wi-Fi, cellular, Bluetooth or Bluetooth Low Energy, magnetic inductive communications, or "hardware connectors capable of connecting to the internet (e.g., USB, ethernet, serial port)." So cyber device status can turn on what is on the board.

Security architecture views include the hardware. FDA's list of assets for security architecture diagrams starts with "device hardware itself (including assessments for any commercial platforms)." It also recommends hardware based security and authenticated firmware updates.

Updates depend on hardware. FDA asks for devices designed to receive firmware patches, with hardware impacts considered. That plan needs to know which board revision each fielded unit has.

What an HBOM adds for a device maker

When a radio module's Bluetooth firmware gets an advisory, the SBOM may list the firmware version. The HBOM tells you which models and board revisions carry that module and who supplied it. That is what you need to scope the postmarket response that section 524B(b)(1) requires, a plan to "monitor, identify, and address, as appropriate, in a reasonable time, postmarket cybersecurity vulnerabilities and exploits." Our post on medical device firmware SBOMs and coordinated disclosure covers the disclosure side.

The hardware equivalent of FDA's end of support date is a part's end of life notice, which the SBOM alone will not show.

Automotive: UN R155 and UN R156

Our UNECE WP.29 explainer covers the overall regime. The hardware relevant parts are narrower and worth quoting precisely.

UN R155: supplier related risks

UN Regulation No. 155 covers cyber security and the cyber security management system (CSMS). It entered into force as an annex to the 1958 Agreement on 22 January 2021. Three provisions bear on supply chain data.

• Paragraph 7.2.2.5 requires the manufacturer to demonstrate how its CSMS "will manage dependencies that may exist with contracted suppliers, service providers or manufacturer's sub-organizations."
• Paragraph 7.3.2, under the requirements for vehicle types, says the manufacturer "shall identify and manage, for the vehicle type being approved, supplier-related risks."
• Paragraph 5.1.1(a) has the approval authority or technical service check that the manufacturer has collected and verified the required information "through the supply chain" to show that supplier related risks are identified and managed.

Paragraph 3.2.2 adds that where information is supplier know-how, "the manufacturer or their suppliers shall make available sufficient information" for the checks, treated as confidential.

The CSMS certificate is valid for at most three years, and the paragraph 7.3.1 allowance for type approvals before 1 July 2024 has expired.

R155 never mentions an HBOM, but managing supplier related risks per vehicle type is hard without knowing which electronic control units (ECUs), from which suppliers, are in it.

UN R156: hardware tied to software versions

UN Regulation No. 156 covers software updates and the software update management system (SUMS). It also entered into force on 22 January 2021. It is the most explicit hardware requirement in this post.

Paragraph 7.1.1.2 requires "a process whereby information regarding all initial and updated software versions, including integrity validation data, and relevant hardware components of a type approved system can be uniquely identified." Paragraph 7.1.1.3 requires RX Software Identification Number (RXSWIN) information to be tracked before and after each update.

That is an HBOM linked to SBOMs in all but name: for each type approved system, which hardware and which software versions are present, tracked across updates.

What an HBOM adds for an automaker or tier 1

• Per ECU hardware identity. Part number, hardware revision, supplier and main processor, for R156.
• Software per hardware. A link to each ECU's firmware SBOM, version and integrity data.
• Supplier risk inputs. Supplier, location and source type, for the R155 assessment.
• Compatibility rules. Which software versions are approved for which hardware revisions.

Defense: counterfeit parts, Section 889 and CMMC

Our post on SBOMs for defense contractors under CMMC covers the software side. For hardware, the concrete rules predate CMMC.

DFARS 252.246-7007: counterfeit part detection and avoidance

The current clause is dated January 2023. It requires covered contractors to establish and maintain "an acceptable counterfeit electronic part detection and avoidance system." An important scoping note: the clause's own text says paragraphs (a) through (e) apply only if the contractor is subject to the Cost Accounting Standards.

The clause defines an electronic part as "an integrated circuit, a discrete electronic component (including, but not limited to, a transistor, capacitor, resistor, or diode), or a circuit assembly." It defines a counterfeit electronic part to include "used electronic parts represented as new, or the false identification of grade, serial number, lot number, date code, or performance characteristics."

Paragraph (c) lists twelve areas the system must address. Several map directly to HBOM fields:

• (c)(4) "tracking of electronic parts from the original manufacturer to product acceptance by the Government," including parts inside assemblies.
• (c)(6) reporting and quarantining suspect parts, with reports to the Government-Industry Data Exchange Program (GIDEP).
• (c)(9) flow down to subcontractors at all levels of the supply chain that buy or sell electronic parts.
• (c)(12) control of obsolete electronic parts.

DFARS 252.246-7008: sources of electronic parts

This clause, also dated January 2023, sets the order of preference. The contractor must first obtain parts that are in production or in stock from the original manufacturer, its authorized suppliers, or suppliers that obtain parts exclusively from those sources. Only if parts are not available that way may it use "contractor-approved suppliers," vetted with counterfeit prevention standards, with the contractor responsible for authenticity.

So every part record needs its source type, plus lot code, date code and obsolescence status, the fields a counterfeit report cites.

FAR 52.204-25: the Section 889 prohibition

FAR 52.204-25, dated November 2021, implements Section 889 of the FY2019 NDAA. It defines covered telecommunications equipment to include equipment "produced by Huawei Technologies Company or ZTE Corporation," and, for specified national security purposes, video surveillance and telecommunications equipment produced by Hytera, Hikvision or Dahua, including their subsidiaries and affiliates.

Paragraph (b)(1) bars agencies, on or after 13 August 2019, from procuring covered equipment as a substantial or essential component of any system. Paragraph (b)(2) bars them, on or after 13 August 2020, from contracting with an entity that uses covered equipment, whether or not that use is tied to a federal contract. If a contractor finds covered equipment during performance, paragraph (d) requires a report "within one business day," with a follow up "within 10 business days."

An HBOM answers it when the producer field holds the actual manufacturer of each telecom or video component, including white label modules, resolved to a parent entity.

CMMC: what it does and does not ask

CMMC is about protecting Federal Contract Information (FCI) and Controlled Unclassified Information (CUI), not about what hardware is in a product. According to the DoD CIO, Level 1 is an annual self assessment against the 15 requirements in FAR 52.204-21, and Level 2 is assessed against the 110 requirements of NIST SP 800-171 Revision 2. The contract clause is DFARS 252.204-7021, dated November 2025.

The status changed this year. The DoD CIO's CMMC page says the first phase began on 10 November 2025, that on 13 July 2026 the Department "announced the immediate suspension" of Phase II, originally scheduled for 10 November 2026, and that CMMC implementation "is paused in Phase 1." It also says this does not remove the obligation to protect information under DFARS 252.204-7012.

So CMMC is not an HBOM rule. An HBOM helps only indirectly, by showing which hardware sits inside the boundary where CUI is processed.

Telecom: the FCC Covered List

Our post on telecommunications supply chain security covers carrier software. For hardware, the FCC Covered List is the rule that has moved fastest.

What the Covered List is

Under the Secure and Trusted Communications Networks Act of 2019, the FCC publishes a list of equipment and services "deemed to pose an unacceptable risk to the national security of the United States." As updated on 21 October 2026, it includes:

• Telecommunications equipment produced by Huawei and by ZTE, and video surveillance and telecommunications equipment produced by Hytera, Hikvision and Dahua for public safety and national security uses, all added on 12 March 2021.
• Certain security software and several carriers' services, added between 2022 and 2026.
• Uncrewed aircraft systems and their critical components produced in a foreign country, added on 22 December 2025, with exceptions such as conditional approvals.
• Routers produced in a foreign country, except those with a conditional approval, added on 23 March 2026.
• Foreign produced power inverters and advanced robotic devices, except those with a conditional approval, added on 28 July 2026.

The FCC notes that listed producers "should be read to include the subsidiaries and affiliates," and that category entries cover only equipment capable of the functions in the Secure Networks Act. For the category entries, check the definitions in the associated National Security Determinations.

Why this makes country of production an HBOM field

The early entries name companies; the 2025 and 2026 entries name categories by where they are produced, with per device conditional approvals. Buyers now need to know where each router, drone component or inverter was produced. The drone entry covers "UAS critical components," so eligibility can depend on parts several tiers down. Without producer and country of production at component level, you must ask every supplier each time the list changes.

EU: the Cyber Resilience Act as the horizontal rule

Our post on CRA SBOM obligations covers the software requirements in depth. Three points matter for hardware.

Hardware products are in scope

Regulation (EU) 2024/2847 of 23 October 2024 defines a product with digital elements as "a software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately." Routers, sensors, controllers and modules sold on their own are products in their own right. Spare parts that replace identical components to the same specification are excluded.

The SBOM requirement and its limits

Annex I, Part II, point (1) requires manufacturers to "identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products." The SBOM goes into the technical documentation and must be given to a market surveillance authority on a reasoned request.

Article 13 requires manufacturers to "exercise due diligence when integrating components sourced from third parties," including free and open source components, and sets a support period that "shall be at least five years" except where the product is expected to be used for less time. An HBOM with lifecycle status per part shows whether your parts will last that long.

Who the CRA does not cover

Article 2 is useful for sector teams. The CRA does not apply to products covered by Regulation (EU) 2017/745 on medical devices, Regulation (EU) 2017/746 on in vitro diagnostic devices, Regulation (EU) 2019/2144 on motor vehicle type approval, products certified under Regulation (EU) 2018/1139 in aviation, marine equipment under Directive 2014/90/EU, or products "developed or modified exclusively for national security or defence purposes."

So telecom equipment is in CRA scope, while medical devices, approved vehicles and defence only products follow their own regimes. A module sold into both a medical device and a consumer router may face both.

The dates

The CRA applies from 11 December 2027. Article 14 reporting of actively exploited vulnerabilities and severe incidents has applied since 11 September 2026, including to products placed on the market before December 2027, and Chapter IV on notified bodies has applied since 11 June 2026.

What a cross-sector HBOM record should contain

Once you lay the rules side by side, a minimum record emerges. These are our recommended fields, with the requirement each one serves. They are not taken from any single standard.

The CISA framework's nesting model, where a finished good contains assemblies that contain components, is the right shape for this. Each assembly you can break down gets its own record, linked to its parent.

Step by step: one HBOM that answers four regulators

We build a small CycloneDX HBOM for an example device, validate it and run each regulator's question as a query. All values are placeholders.

1. Model the device, its parts and its firmware

Record each device and its firmware as separate components, with regulatory fields in a properties namespace you control.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 1,
  "metadata": {
    "timestamp": "2026-10-23T09:00:00Z",
    "component": {
      "type": "device",
      "bom-ref": "product-gw200",
      "name": "GW-200 Connected Gateway",
      "version": "rev C",
      "supplier": { "name": "Example Devices Inc." }
    }
  },
  "components": [
    {
      "type": "device",
      "bom-ref": "mcu-u1",
      "name": "Main microcontroller",
      "version": "B1",
      "supplier": { "name": "Example Semiconductor" },
      "properties": [
        { "name": "example:hbom:mpn", "value": "EXS-MCU-4410-B1" },
        { "name": "example:hbom:originalManufacturer", "value": "Example Semiconductor" },
        { "name": "example:hbom:parentEntity", "value": "Example Semiconductor Holdings" },
        { "name": "example:hbom:sourceType", "value": "authorized-distributor" },
        { "name": "example:hbom:countryOfProduction", "value": "MY" },
        { "name": "example:hbom:lotCode", "value": "L2611A" },
        { "name": "example:hbom:dateCode", "value": "2611" },
        { "name": "example:hbom:interfaces", "value": "usb,uart" }
      ]
    },
    {
      "type": "firmware",
      "bom-ref": "mcu-u1-fw",
      "name": "Gateway application firmware",
      "version": "4.2.1",
      "hashes": [
        { "alg": "SHA-256", "content": "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08" }
      ],
      "externalReferences": [
        { "type": "bom", "url": "urn:cdx:5b2c1f0e-7d1a-4c55-9c4e-1f1d2a3b4c5d/1" }
      ]
    },
    {
      "type": "device",
      "bom-ref": "radio-m2",
      "name": "Wi-Fi and Bluetooth module",
      "version": "2.0",
      "supplier": { "name": "Example Radio Co." },
      "properties": [
        { "name": "example:hbom:mpn", "value": "ERC-WB20" },
        { "name": "example:hbom:sourceType", "value": "original-manufacturer" },
        { "name": "example:hbom:countryOfProduction", "value": "VN" },
        { "name": "example:hbom:lifecycle", "value": "nrnd" },
        { "name": "example:hbom:endOfLifeNotice", "value": "2026-06-30" },
        { "name": "example:hbom:interfaces", "value": "wifi,bluetooth-le" }
      ]
    },
    {
      "type": "firmware",
      "bom-ref": "radio-m2-fw",
      "name": "Radio module firmware",
      "version": "7.14.0"
    }
  ],
  "dependencies": [
    { "ref": "product-gw200", "dependsOn": ["mcu-u1", "radio-m2"] },
    { "ref": "mcu-u1", "dependsOn": ["mcu-u1-fw"] },
    { "ref": "radio-m2", "dependsOn": ["radio-m2-fw"] }
  ]
}

The bom external reference links the firmware's own SBOM through a BOM-Link URN.

2. Validate it against the schema

Use the official CycloneDX CLI.

# Validate the HBOM against the CycloneDX 1.6 JSON schema
cyclonedx validate --input-file gw200-hbom.json --input-format json --input-version v1_6 --fail-on-errors

Schema validation proves structure, not truth, so also check that every device has the properties you require.

# List device components missing a country of production or source type
jq -r '
  .components[]
  | select(.type == "device")
  | select(
      ([.properties[]?.name] | index("example:hbom:countryOfProduction") | not)
      or ([.properties[]?.name] | index("example:hbom:sourceType") | not)
    )
  | .name
' gw200-hbom.json

3. Answer the FCC and Section 889 question

Does any component come from a listed producer, or fall in a listed category by country of production?

# Print every device with its producer, parent entity and country of production
jq -r '
  .components[]
  | select(.type == "device")
  | [ .name,
      ((.properties // []) | map(select(.name=="example:hbom:originalManufacturer"))[0].value // "UNKNOWN"),
      ((.properties // []) | map(select(.name=="example:hbom:parentEntity"))[0].value // "UNKNOWN"),
      ((.properties // []) | map(select(.name=="example:hbom:countryOfProduction"))[0].value // "UNKNOWN") ]
  | @tsv
' gw200-hbom.json

Match producer and parent against your covered entity list, and country against the category rules. Treat "UNKNOWN" as a finding.

4. Answer the DFARS sourcing question

Use the same pattern to list devices whose example:hbom:sourceType is anything other than original manufacturer or authorized distributor. Each one needs inspection and test records and a lot and date code you can match against GIDEP reports.

5. Answer the FDA and CRA lifecycle question

Will any part go out of support before the product does? Reuse the query pattern on example:hbom:lifecycle, selecting values such as nrnd, eol or obsolete.

Here the radio module comes back. Compare its end of life notice with the CRA support period, and reflect it in the FDA cybersecurity management plan.

6. Answer the UN R156 question

The dependencies block already says which firmware runs on which part. For a vehicle, repeat it per ECU and keep a table of approved software versions per hardware revision and RXSWIN, updated with every campaign.

7. Store, sign and refresh

Version and sign each HBOM release, and regenerate it whenever the bill of materials changes. An alternate part on the line is an HBOM change.

Where Safeguard fits, honestly

Safeguard does not generate HBOMs. It does not inventory physical parts, verify part authenticity, check producers against the FCC Covered List, scan firmware binaries or manage devices. The hardware records in this post come from your product lifecycle system, your procurement data and your suppliers.

The overlap is the software half, which every one of these regulators also asks about. Safeguard generates and analyses SBOMs in SPDX and CycloneDX, and accepts SBOMs your hardware and firmware suppliers give you, for example with safeguard scan --sbom radio-module-sbom.json from the CLI. It matches the components declared in those SBOMs against vulnerability databases with EPSS and KEV enrichment, shows which of your projects and products contain a given component and version, and accepts CSAF and VEX uploads so a supplier's "not affected" statements are recorded next to the finding. Its third party risk module can request SBOMs from suppliers. All of this depends on the supplier declaring what is inside the firmware; Safeguard does not discover it from the binary. It also covers the apps and update servers you build around regulated devices.

Common mistakes

• Recording the brand, not the producer. Section 889 and the FCC Covered List turn on who produced the equipment, including subsidiaries and affiliates.
• Leaving country of production blank. The FCC now lists some categories by where they are produced.
• One record for hardware and firmware. Updating firmware then overwrites the hardware history. Keep them as separate, linked components.
• Treating CMMC as a hardware rule. It is about protecting FCI and CUI. Do not let it distract from DFARS 252.246-7007.
• Assuming the CRA covers everything you sell in the EU. Medical devices, type approved vehicles and defence only products are outside it.
• Missing the end of life notice. The SBOM alone will not show it.
• Sharing the whole record with everyone. An HBOM with suppliers, lot codes and locations is commercially sensitive. Restrict access.

FAQ

Is an HBOM required by FDA for medical devices?

No. Section 524B of the FD&C Act requires an SBOM for cyber devices, and FDA's February 2026 guidance asks for machine readable SBOMs with support level and end of support dates. An HBOM helps but is not a named deliverable.

Does UN R155 require a software or hardware bill of materials?

Neither by name. R155 requires the manufacturer to manage dependencies on suppliers and to identify and manage supplier related risks for each vehicle type. R156 requires software versions and relevant hardware components to be uniquely identified, which is close to an HBOM linked to SBOMs.

Does CMMC require an SBOM or HBOM?

No. CMMC assesses protection of Federal Contract Information and Controlled Unclassified Information against FAR 52.204-21 and NIST SP 800-171 Revision 2. It is currently paused in Phase 1.

What DFARS rules apply to counterfeit electronic parts?

DFARS 252.246-7007 requires a counterfeit electronic part detection and avoidance system with twelve criteria, including tracking parts from the original manufacturer and reporting to GIDEP. DFARS 252.246-7008 sets the order of sources, starting with the original manufacturer and its authorized suppliers.

What is the FCC Covered List and how does it affect hardware?

It is the FCC's list of equipment and services deemed an unacceptable national security risk. It now includes categories such as foreign produced routers and drone components, which makes country of production essential hardware data.

What does Section 889 prohibit?

FAR 52.204-25 bars federal agencies from buying covered telecommunications and video surveillance equipment from Huawei, ZTE, Hytera, Hikvision and Dahua as a substantial or essential component, and from contracting with entities that use such equipment. Contractors must report covered equipment found during performance within one business day.

Does the EU Cyber Resilience Act apply to hardware?

Yes. A product with digital elements is "a software or hardware product," including separately sold components. It applies in full from 11 December 2027, but excludes medical devices, type approved vehicles and defence only products.

Which format should I use for an HBOM in a regulated industry?

CycloneDX supports hardware directly with device and firmware component types and a properties mechanism for fields such as source type and country of production. Use the same format as your SBOMs so the two can link.

Fix it without waiting for upstream

Every regulator in this post asks about software too: FDA wants the open source and off the shelf components in a cyber device, the CRA wants them in the technical documentation, and the companion apps, cloud services and update servers around regulated hardware all pull open source dependencies. The fit with the hardware itself is indirect, because nothing below touches parts or firmware binaries, but it keeps the open source software you build and ship around 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 companion app or update server shipped with a regulated device.

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 regulated engineering teams who keep supplier firmware SBOMs on internal systems and want to scan them where they already live.

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 products contain a component named in a supplier advisory, as long as that supplier's SBOM 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

• FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (guidance page)
• FDA, Cybersecurity in Medical Devices guidance, issued 3 February 2026 (PDF)
• UNECE, UN Regulation No. 155, Cyber security and cyber security management system (PDF)
• UNECE, UN Regulation No. 156, Software update and software update management system (PDF)
• EUR-Lex, Regulation (EU) 2024/2847, Cyber Resilience Act
• Acquisition.gov, FAR 52.204-25, Prohibition on Contracting for Certain Telecommunications and Video Surveillance Services or Equipment
• Acquisition.gov, DFARS 252.246-7007, Contractor Counterfeit Electronic Part Detection and Avoidance System
• Acquisition.gov, DFARS 252.246-7008, Sources of Electronic Parts
• Acquisition.gov, DFARS 252.204-7021, Contractor Compliance with the CMMC Level Requirements
• DoD CIO, About CMMC
• FCC, List of Equipment and Services Covered by Section 2 of the Secure Networks Act (Covered List)
• CISA, Hardware Bill of Materials (HBOM) Framework for Supply Chain Risk Management
• CycloneDX, Hardware Bill of Materials (HBOM) capability

Last reviewed: 23 October 2026. Regulatory programs in this post, especially CMMC and the FCC Covered List, change often; check the linked primary sources for the current status.