Which Regulations Require Which BOM? SBOM, AIBOM, CBOM, HBOM by Regime

As of October 2026, the software bill of materials is the only BOM any law requires by name: the EU Cyber Resilience Act requires manufacturers to draw one up, and US law requires one in FDA submissions for cyber devices. AIBOMs, CBOMs, HBOMs, SaaSBOMs and VEX documents appear only in guidance, contracts and market practice.

US federal policy moved twice in four years, from "agencies may require an SBOM" in 2022 to "agencies may write a contract term asking for one" in 2026. CISA replaced the NTIA minimum elements in July 2026, and the EU AI Act asks for documentation that reads like an AIBOM without using the word. This post quotes what each text says, names its format language, and ends with one evidence pack you can reuse.

Key takeaways

• Law requires an SBOM in two places: the EU Cyber Resilience Act (main obligations from 11 December 2027) and section 524B(b)(3) of the US FD&C Act for cyber device submissions, in force now.
• US federal procurement is contract by contract. OMB M-26-05 rescinded M-22-18 and M-23-16 on 23 January 2026; agencies "may choose" to require an SBOM upon request.
• CISA's 2026 Minimum Elements replaced the NTIA 2021 list on 29 July 2026, adding ten fields such as component hash, license and SBOM author signature.
• No regime makes CycloneDX or SPDX mandatory. The CRA says "commonly used and machine-readable"; CISA names both as widely used.
• The EU AI Act never says "bill of materials", but Annex IV asks for third party models, software versions and dataset provenance, which an AIBOM carries.
• CBOM, HBOM, SaaSBOM, OBOM and VEX are not mandated by name anywhere we could find, though M-26-05 points agencies to CISA's HBOM framework.

The whole map in one table

The table below is the answer to the title question. Each row is explained, with sources, in the sections that follow.

If you only remember one line: build an SBOM that meets the CISA 2026 elements, in SPDX or CycloneDX, signed, with per-component support data and a vulnerability status file next to it. That one pack covers the CRA, FDA and any federal contract term written today.

US federal policy: EO 14028, M-22-18, M-23-16 and what replaced them

What EO 14028 actually says

Executive Order 14028, published in the Federal Register on 17 May 2021, is where "SBOM" entered US federal policy. Section 4(e) told NIST to issue guidance on practices that enhance software supply chain security. Item (vii) on that list is "providing a purchaser a Software Bill of Materials (SBOM) for each product directly or by publishing it on a public website". Section 10(j) defines the term as "a formal record containing the details and supply chain relationships of various components used in building software".

The order directs NIST and agencies to write guidance; it places no duty on vendors by itself. It also accepts publishing an SBOM on a public website, a choice the CRA later chose not to force.

M-22-18 and M-23-16: the attestation era

OMB M-22-18, issued on 14 September 2022, required agencies to collect a self-attestation from software producers that they follow NIST SSDF practices. The SBOM was optional and agency driven. The memo said an SBOM "may be required by the agency in solicitation requirements, based on the criticality of the software". When required, the memo said SBOMs "must be generated in one of the data formats defined in" the NTIA minimum elements report "or successor guidance as published by" CISA. Those formats were SPDX, CycloneDX and SWID tags. It also told agencies to consider reciprocity, meaning an SBOM already held by one agency could serve another.

M-23-16, dated 9 June 2023, changed the attestation deadlines. It did not add an SBOM duty.

M-26-05: the current state

On 23 January 2026, OMB Memorandum M-26-05, "Adopting a Risk-based Approach to Software and Hardware Security", rescinded both memos. It says M-22-18 "imposed unproven and burdensome software accounting processes". What remains is short and worth reading in full, because it shapes every federal SBOM conversation in 2026:

• Agencies "shall continue to maintain a complete inventory of software and hardware".
• Agencies "may also choose to adopt contractual terms that require a software producer to provide a current software bill of materials (SBOM) upon request".
• A footnote adds that for a cloud platform, the contract term should require "an SBOM of the runtime production environment upon request". That is the closest any US policy document comes to a SaaSBOM requirement, and it still says SBOM.
• The memo lists references agencies can use: NIST SP 800-218, CISA's 2025 draft minimum elements, and CISA's "A Hardware Bill of Materials (HBOM) Framework for Supply Chain Risk Management" from September 2023.

So the HBOM framework is now named in a federal memo, as a reference, and the SBOM is a contract term an agency may choose.

We cover attestation and the later cryptography contract rules in OMB M-26-05 ended the federal software attestation mandate. The point here: a federal SBOM request now arrives as a contract clause, most likely citing the CISA minimum elements.

CISA minimum elements: NTIA 2021 versus CISA 2026

The 2021 NTIA list

The NTIA report "The Minimum Elements For a Software Bill of Materials" of July 2021 set seven data fields: Supplier Name, Component Name, Version of the Component, Other Unique Identifiers, Dependency Relationship, Author of SBOM Data and Timestamp. For automation support it named SPDX, CycloneDX and SWID tags.

The 2026 CISA update

CISA published "2026 Minimum Elements for a Software Bill of Materials (SBOM)" on 29 July 2026 with NSA, FBI and fifteen international agencies, including Germany's BSI, France's ANSSI, India's CERT-In and Japan's METI. It "updates and replaces" the NTIA list; its version history shows a 2.0 draft on 22 August 2025 and the final 2.1 on 29 July 2026.

The ten new data fields are SBOM Author Signature, SBOM Data Format Name, SBOM Data Format Version, SBOM Generation Context, SBOM Tool Name, SBOM Tool Version, SBOM Version, Component Hash Value, Component Hash Algorithm and Component License. Supplier Name became Component Producer because it "has proven ambiguous in practice, particularly around distributors of software". Access Controls was folded into Distribution and Delivery.

Three details matter when a regulator reads your SBOM:

1. Format. Organizations "should accept any widely used, interoperable, and machine-processable SBOM format" and should avoid SBOMs for new software in deprecated format versions. SWID is no longer listed as a widely used SBOM format.
2. Unknown versus withheld. Authors "should explicitly state whether the information is unknown to the SBOM author or whether the SBOM author is withholding the information".
3. Scope. The elements "do not create new requirements". They bind only when a contract or rule points at them.

For SaaS and AI the document adds no elements: it notes that shared responsibility in SaaS "may limit some SBOM use cases" and points AI to the G7 guidance below.

To choose between versions for a customer, see which SBOM minimum elements to follow, 2021 or 2026.

FDA premarket: the one US statute that requires an SBOM today

What section 524B requires

Section 524B of the Federal Food, Drug, and Cosmetic Act applies to anyone submitting a 510(k), PMA, PDP, De Novo or HDE for a "cyber device". The statute 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 has characteristics that "could be vulnerable to cybersecurity threats". Section 524B(b)(3), as FDA's guidance summarises it, "requires manufacturers of cyber devices to provide an SBOM, including commercial, open-source, and off-the-shelf software components".

The SBOM is statutory for a cyber device; only FDA's guidance on how to meet it is nonbinding.

What the February 2026 guidance asks for

FDA's guidance "Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions" was issued on 3 February 2026 and supersedes the June 27, 2025 version. On SBOMs it asks for:

• Machine-readable SBOMs consistent with the minimum elements, which FDA calls "baseline attributes", from the October 2021 NTIA document "Framing Software Component Transparency". Note that FDA cites the Framing document, not the July 2021 NTIA minimum elements report and not the CISA 2026 update.
• Two extra fields for every component: the "software level of support provided through monitoring and maintenance" (for example actively maintained, no longer maintained, abandoned), and "the software component's end-of-support date". These may go inside the SBOM or in a separate addendum.
• Format: "Industry-accepted formats of SBOMs are encouraged." No specific format is required.
• Known vulnerabilities: all known vulnerabilities in the device and its components, "including those identified in CISA's Known Exploited Vulnerabilities Catalog", with a safety and security risk assessment and the risk controls for each.
• Labeling: an SBOM for users "in a machine-readable format", made available "on a continuous basis".
• A justification if SBOM information cannot be provided.

What FDA says about hardware

The guidance covers software "including firmware" but does not ask for a hardware bill of materials; hardware appears in threat modeling and architecture views. For HBOM use in device makers' own programs, see HBOM in regulated industries.

The support fields are the part teams miss most: no generator produces them, so plan the enrichment step in the walkthrough. Our FDA premarket SBOM post covers reviewer expectations.

EU Cyber Resilience Act: SBOM in the law itself

The text

Regulation (EU) 2024/2847 writes the SBOM into binding text. Quoted from the Official Journal text:

• Definition, Article 3(39): "'software bill of materials' means a formal record containing details and supply chain relationships of components included in the software elements of a product with digital elements".
• The duty, Annex I Part II point (1): manufacturers shall "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".
• Format power, Article 13(24): "The Commission may, by means of implementing acts taking into account European or international standards and best practices, specify the format and elements of the software bill of materials".
• Technical documentation, Annex VII: point 2(b) lists vulnerability handling information "including the software bill of materials", and point 8 lists, "where applicable, the software bill of materials, further to a reasoned request from a market surveillance authority".
• User information, Annex II point 9: if the manufacturer decides to make the SBOM available to users, information on where it can be accessed.
• Confidentiality, recital 77: "Manufacturers should not be obliged to make the SBOM public."

Dates

The Commission's CRA page gives entry into force on 10 December 2024, reporting obligations from 11 September 2026, and main obligations from 11 December 2027, which is when the Annex I SBOM duty applies. Reporting of actively exploited vulnerabilities already applies, and an SBOM is the fastest way to know whether such a component ships in your product. The Commission published implementation guidance on 27 July 2026.

What the CRA does not say

The CRA does not name SPDX or CycloneDX, does not require transitive dependencies, and does not mention VEX, HBOM or cryptographic inventories. Until an implementing act under Article 13(24) exists, there is no EU-wide field list; CISA's 2026 document cites Germany's BSI TR-03183-2 as one national technical guideline. See SBOM rules compared and what the EU CRA SBOM requirement says.

EU AI Act: documentation an AIBOM can carry, with no AIBOM mandate

No bill of materials by name

Regulation (EU) 2024/1689 does not use the words "bill of materials" in Article 11, Article 53 or Annex IV, where technical documentation is defined. An "AIBOM mandate" is a market expectation, not the law. The documentation the law requires overlaps heavily with an AIBOM, though.

What Article 11 and Annex IV ask for

Article 11 requires providers of high-risk AI systems to draw up technical documentation before market placement, containing "at a minimum" the Annex IV elements, including:

• 1(a): the intended purpose, the provider's name and "the version of the system reflecting its relation to previous versions".
• 1(c): "the versions of relevant software or firmware, and any requirements related to version updates".
• 2(a): development methods "including, where relevant, recourse to pre-trained systems or tools provided by third parties and how those were used, integrated or modified".
• 2(c): the system architecture "explaining how software components build on or feed into each other".
• 2(d): datasheets describing training methodologies and the training data sets, "including a general description of these data sets, information about their provenance, scope and main characteristics".

General-purpose AI models: Article 53

Under Article 53(1), general-purpose AI model providers must keep technical documentation including training and testing (a), give documentation to downstream integrators (b), keep a copyright policy (c), and publish "a sufficiently detailed summary about the content used for training" on an AI Office template (d).

Dates after the AI Omnibus

Per the Commission's AI Act page, the Act entered into force on 1 August 2024; prohibitions applied from 2 February 2025, GPAI obligations from 2 August 2025 and most rules from 2 August 2026. The AI Omnibus, which entered into force on 27 July 2026, moved Annex III high-risk obligations to 2 December 2027 and Annex I product-embedded systems to 2 August 2028.

How Annex IV maps to AIBOM fields

An AIBOM can feed most Annex IV inventory facts but cannot replace the narrative parts: design choices, human oversight, validation results and risk management.

The G7 AI SBOM guidance

On 12 May 2026, CISA and G7 partners (Germany, Canada, France, Italy, Japan, the United Kingdom and the EU) released "Software Bill of Materials for AI, Minimum Elements", which CISA calls "not exhaustive or mandatory". CISA's page summary oddly says "super intelligence (SI) systems" while the title says AI; we treat it as AI guidance, as the 2026 minimum elements footnote does.

For the trend line, see AI-BOM becoming mandatory; for official tooling, the OWASP GenAI Security Project hosts the OWASP AIBOM Generator.

NIST SSDF and SP 800-161r1: what suppliers are expected to keep

SSDF (SP 800-218)

SSDF 1.1 (February 2022) treats the SBOM as an example of provenance data. Task PS.3.2 reads: "Collect, safeguard, maintain, and share provenance data for all components of each software release (e.g., in a software bill of materials [SBOM])." Its examples ask for "standards-based formats", integrity protection and an update whenever a component changes. PW.4.1 example 3 asks producers to obtain an SBOM for components they acquire.

The SSDF maps EO 14028 section 4(e)(vii), the SBOM item, to exactly one task: PS.3.2.

SP 800-161r1 (C-SCRM)

NIST SP 800-161r1, update 1 (changes as of 1 November 2024), puts SBOM guidance in several controls:

• SR-4 Provenance says enterprises "should consider producing SBOMs for applicable and appropriate classes of software, including purchased software, open source software, and in-house software", that SBOMs "should be produced using only NTIA-supported SBOM formats", and that SBOMs "should be digitally signed using a verifiable and trusted key". It warns against "the mistaken assumption that SBOM replaces" vulnerability management and vendor risk assessments.
• CM-8(10) says that if an open source project you rely on has no SBOM, you can contribute generation, fund it, or generate one yourself.
• Acquisition guidance asks that "logic-bearing products (i.e., hardware)" come with an SBOM: an SBOM of the software inside hardware, not an HBOM.

Where VDR fits

You will often read that SP 800-161r1 recommends a Vulnerability Disclosure Report. We searched the full upd1 text and did not find the term; CycloneDX's VDR page cites ISO/IEC 29147 instead. Treat VDR as a format choice, not a NIST requirement.

Where CBOM, HBOM, SaaSBOM and OBOM sit

None of the regimes above mandates these documents by name. Here is what each one does have, stated honestly.

HBOM is the most mature of these from a policy view: CISA built a framework and OMB now names it, so expect HBOM questions in US hardware procurement (see our HBOM guide and CISA HBOM framework explainer). CBOM is driven by post-quantum planning, but no rule names a CBOM format. SaaSBOM is a CycloneDX capability; regulators still say SBOM.

Which format each regime names or accepts

This replaces the common question "which format should I pick for which regulator". The honest answer is that no regulator in this list forces one.

Pick the format your toolchain produces best and your customers ingest. If a buyer needs the other, convert and keep the original as the record; the CycloneDX CLI README warns conversion "can result in the loss of some" information. See CycloneDX or SPDX for an agency's client and the global SBOM mandate tracker.

Walkthrough: one evidence pack for CRA, FDA and a federal contract

The goal: on every release, a signed SBOM meeting the CISA 2026 elements, FDA support data, a vulnerability status file and a validation report, using the official CycloneDX tools.

Step 1: install the generator

cdxgen moved to a new npm package name. Its README gives this install line:

npm install -g @cdxgen/cdxgen --ignore-scripts --min-release-age=2

Step 2: generate the SBOM from the build, not the source tree

Generate after dependencies resolve; CISA's Generation Context element asks you to state the lifecycle phase.

# Node.js example: install exactly what the lockfile says, then generate
npm ci
cdxgen -r -o bom.json --spec-version 1.6 .

# Container image you ship
cdxgen -t docker registry.example.com/infusion-gateway:4.2.0 \
  --spec-version 1.6 -o image-bom.json

cdxgen defaults to CycloneDX 1.7; --spec-version 1.6 helps recipients whose tools do not read 1.7 yet.

Step 3: what a minimal compliant SBOM looks like

This minimal document validates against the CycloneDX 1.6 JSON schema (bom-1.6.schema.json). It carries CISA 2026 metadata (author, timestamp, tool, lifecycle), a PURL, the real SHA-512 of the published express 4.21.2 tarball, an SPDX license ID, the dependency graph, and FDA support fields as namespaced properties, since CycloneDX 1.6 has no dedicated field for them.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 1,
  "metadata": {
    "timestamp": "2026-10-24T09:00:00Z",
    "lifecycles": [{ "phase": "build" }],
    "tools": {
      "components": [
        { "type": "application", "name": "cdxgen" }
      ]
    },
    "authors": [{ "name": "Example Devices Inc. product security team" }],
    "manufacturer": {
      "name": "Example Devices Inc.",
      "url": ["https://example.com"],
      "contact": [{ "email": "psirt@example.com" }]
    },
    "component": {
      "type": "application",
      "bom-ref": "pkg:generic/example-devices/infusion-gateway@4.2.0",
      "name": "infusion-gateway",
      "version": "4.2.0",
      "supplier": { "name": "Example Devices Inc." }
    }
  },
  "components": [
    {
      "type": "library",
      "bom-ref": "pkg:npm/express@4.21.2",
      "supplier": { "name": "OpenJS Foundation" },
      "name": "express",
      "version": "4.21.2",
      "purl": "pkg:npm/express@4.21.2",
      "hashes": [
        { "alg": "SHA-512", "content": "dbc1ea80c6409a28750b3b7d9f2eeaafa7a4daa75d17815c95b333c21091101e8e15f1fead7027b8d0b0a35ff016faed6e0b100dbe2449b5fd75ef6515bad79c" }
      ],
      "licenses": [{ "license": { "id": "MIT" } }],
      "properties": [
        { "name": "example:fda:levelOfSupport", "value": "actively maintained" },
        { "name": "example:fda:endOfSupportDate", "value": "unknown" }
      ]
    }
  ],
  "dependencies": [
    { "ref": "pkg:generic/example-devices/infusion-gateway@4.2.0", "dependsOn": ["pkg:npm/express@4.21.2"] },
    { "ref": "pkg:npm/express@4.21.2", "dependsOn": [] }
  ]
}

The dependency graph exceeds the CRA's top-level floor, metadata.manufacturer gives a vulnerability contact, and unknown for end of support follows CISA's rule to state unknowns rather than leave gaps.

Step 4: validate the schema, then the content

# Schema validation with the CycloneDX CLI; non-zero exit fails the build
cyclonedx-cli validate --input-file bom.json --input-version v1_6 --fail-on-errors

# Content checks with cdx-validate, including its CRA rule set
cdx-validate -i bom.json --benchmark cra

Per cdxgen's documentation, the cra benchmark runs eight checks "extracted from CRA Annex I and the ENISA SBOM guidance", such as a manufacturer contact, a urn:uuid serial number, dependency coverage of at least 75 percent, and license data on every component. That is the tool authors' reading of the CRA, not an official EU checklist.

Step 5: enrich for FDA support data

No generator knows when support ends. Keep a lookup your engineering team owns and merge it after generation:

# support.json maps purl to level of support and end-of-support date, e.g.
# {"pkg:npm/express@4.21.2": {"level": "actively maintained", "eos": "unknown"}}
jq --slurpfile s support.json '
  .components |= map(
    . as $c
    | ($s[0][$c.purl] // {level: "unknown", eos: "unknown"}) as $x
    | .properties = ((.properties // []) + [
        {name: "example:fda:levelOfSupport", value: $x.level},
        {name: "example:fda:endOfSupportDate", value: $x.eos}
      ])
  )' bom.json > bom-fda.json

Revalidate bom-fda.json, or export the lookup as an addendum, which FDA also accepts.

Step 6: sign the SBOM

CISA 2026 adds an SBOM Author Signature element and SP 800-161r1 says SBOMs "should be digitally signed". With Sigstore's cosign:

cosign sign-blob bom-fda.json --bundle bom-fda.sigstore.json

Sigstore's docs recommend the bundle form, and --yes skips prompts in CI. Recipients verify with cosign verify-blob against the expected signer identity and issuer.

Step 7: add the vulnerability status file and wire it into CI

Keep a VEX document (CycloneDX VEX, OpenVEX or CSAF VEX) next to each SBOM for FDA's vulnerability assessment and fast CRA reporting, and regenerate everything per release:

name: release-evidence
on:
  release:
    types: [published]
jobs:
  sbom:
    runs-on: ubuntu-latest
    permissions:
      contents: write
      id-token: write
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm ci
      - run: npm install -g @cdxgen/cdxgen --ignore-scripts
      - run: cdxgen -r -o bom.json --spec-version 1.6 .
      - run: cdx-validate -i bom.json --benchmark cra
      - uses: sigstore/cosign-installer@v3
      - run: cosign sign-blob bom.json --bundle bom.sigstore.json --yes
      - run: gh release upload "${{ github.event.release.tag_name }}" bom.json bom.sigstore.json
        env:
          GH_TOKEN: ${{ github.token }}

Pin actions to commit SHAs. The workflow enforces CISA's rule: "Each software version or update should have an associated SBOM."

Step 8: scan the SBOM you just produced

An SBOM does not tell you what is vulnerable in it. The Safeguard CLI scans the file directly:

safeguard scan --sbom bom.json

Results land as JSON under ./output, ready for the FDA assessment and your VEX file.

Where Safeguard fits

Safeguard's fit is direct for SBOMs and partial for other BOM types.

• SBOM generation and analysis (generally available): Safeguard generates SBOMs in SPDX (JSON, XML, RDF) and CycloneDX (JSON, XML), exports to more than 30 formats including CSV, Excel and PDF, offers a Deep Analysis option using its Griffin models, and rescans continuously on push, on a schedule or on release. That matches the "SBOM per release" expectation in CISA 2026 and SSDF PS.3.2.
• CSAF and VEX upload (generally available) for vendors' advisories alongside their SBOMs.
• License compliance (generally available): SPDX expression parsing, license policy, and NOTICE and attribution generation, which supports CISA's new Component License element.
• Attestation and signing (generally available): SLSA, Sigstore keyless signing through Fulcio and Rekor, in-toto and X.509, plus Kubernetes admission control. This is where the SBOM Author Signature element and 800-161r1's signing advice land.
• Third party risk management (generally available): onboard vendors, request SBOMs, projects or products from them, and score and monitor supplier risk. That is the consumer side of an M-26-05 contract term.
• Portal (generally available) for publishing, sharing and managing SBOMs, with EO 14028 verification and audit trails; the Trust Center inside it is in early access.
• Compliance and GRC suite (generally available) supporting EO 14028, NIST SSDF, SLSA and VEX.
• AI-BOM discovery is in early access. It inventories AI assets across code (SDK imports), cloud services such as SageMaker, Bedrock and Vertex, SaaS shadow AI and vector databases, and outputs CycloneDX ML-BOM and the SPDX AI profile. Treat it as early access when planning EU AI Act documentation.

What Safeguard does not do: generate HBOMs, CBOMs or cryptographic inventories, OBOMs, MBOMs, KBOMs, SaaSBOMs or dataset BOMs, author VDR, BOV, SWID or CoSWID, or convert formats beyond its listed exports. Use the official CycloneDX tooling for those. It is also no substitute for regulatory review of your whole submission.

Common mistakes

• Saying "the law requires CycloneDX" or "the law requires SPDX". None of the regimes here names a mandatory format. The CRA leaves format to a possible implementing act; FDA says industry-accepted formats.
• Telling a federal customer that SBOMs are required government-wide. Since M-26-05, it depends on the agency's contract. Quote the contract clause, not M-22-18.
• Stopping at the CRA floor. "At the very least the top-level dependencies" is a minimum. A direct-dependency-only SBOM will miss most of the components that carry known vulnerabilities.
• Leaving FDA support fields blank. Level of support and end-of-support date are not in any generator's default output. Without them a premarket SBOM is incomplete.
• Leaving fields empty instead of marking them unknown. CISA 2026 asks you to say whether information is unknown or withheld. An empty field looks like a tooling failure.
• Calling the EU AI Act an AIBOM mandate. It requires technical documentation. An AIBOM is a good way to produce part of it, not a named obligation.
• Generating one SBOM and never regenerating it. Every regime that talks about lifecycle (SSDF PS.3.2, CISA's Frequency element, FDA labeling "on a continuous basis") expects an SBOM per release.

FAQ

Is an SBOM legally required in the United States?

Only in specific cases: section 524B(b)(3) of the FD&C Act for cyber device submissions, and federal contracts where an agency adds an SBOM term under M-26-05. No general US law requires every vendor to produce one.

Does the EU Cyber Resilience Act require an SBOM?

Yes. Annex I Part II point (1) requires one "covering at the very least the top-level dependencies", applying from 11 December 2027. It need not be public, but authorities can request it.

Which SBOM format does the CRA require, SPDX or CycloneDX?

Neither by name. The text says "commonly used and machine-readable", and Article 13(24) lets the Commission specify format by implementing act.

Does the EU AI Act require an AIBOM?

No. Article 11 and Annex IV require technical documentation; an AIBOM in CycloneDX ML-BOM or SPDX 3.0.1 AI and Dataset profiles can carry much of it.

Is a CBOM required for post-quantum compliance?

No regime here names one. CycloneDX positions CBOM for post-quantum readiness, but no rule prescribes it.

Is an HBOM mandatory for federal hardware suppliers?

Not by regulation. M-26-05 lists CISA's HBOM Framework as a reference, and a contract can still require one.

What are the CISA 2026 SBOM minimum elements?

The July 2026 update replacing NTIA 2021. It renames Supplier Name to Component Producer and adds ten fields, including hash, license, signature, format name and version, and tool details. It creates no legal requirement by itself.

What does the FDA need in an SBOM beyond the minimum elements?

Per component, the level of support and the end-of-support date, in the SBOM or an addendum, plus an assessment of every known vulnerability, including those in CISA's KEV catalog.

Is VEX required by any regulation?

Not by name here. CISA 2026 describes VEX and CSAF as advisory formats, and a VEX document is a natural carrier for FDA's per-vulnerability assessment.

Does the SSDF require an SBOM?

As an example of provenance data under task PS.3.2. An SBOM per release with integrity protection is the usual evidence.

Fix it without waiting for upstream

Every regime in this post treats the BOM as a means to an end: knowing which shipped products contain a vulnerable component, then fixing them. A CRA-compliant SBOM or an FDA-ready component list only lists the vulnerable version; someone still has to ship the build that removes it.

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 Safeguard CLI session: it reads a finding and its advisory, asks before each command, upgrades lodash to 4.17.21, runs npm install and npm test with your approval, and pushes nothing. That is the step after your regulatory SBOM shows a vulnerable component: the fix lands, and the next SBOM and VEX file show it gone.

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

The second demo sets up the Safeguard runner on your own machine, approves it with a device code and scans from the terminal. Regulated teams that cannot send code out can generate and scan SBOMs where the build already runs, before files go into a CRA technical file or FDA submission.

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, so compliance staff can ask which products contain a component without exporting spreadsheets.

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

• EU Cyber Resilience Act, Regulation (EU) 2024/2847, EUR-Lex
• European Commission, Cyber Resilience Act policy page
• European Commission, guidance to support Cyber Resilience Act implementation (27 July 2026)
• EU AI Act, Regulation (EU) 2024/1689, EUR-Lex
• European Commission, AI Act regulatory framework page
• AI Act Service Desk, Article 11
• AI Act Service Desk, Article 53
• AI Act Service Desk, Annex IV
• Executive Order 14028, Federal Register (PDF)
• OMB M-22-18 (PDF)
• OMB M-23-16 (PDF)
• OMB M-26-05, Adopting a Risk-based Approach to Software and Hardware Security (PDF)
• CISA, Software Bill of Materials
• CISA, 2026 Minimum Elements for a Software Bill of Materials
• CISA, 2026 Minimum Elements (PDF)
• CISA, Software Bill of Materials for AI, Minimum Elements
• NTIA, The Minimum Elements For a Software Bill of Materials (2021, PDF)
• FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (3 Feb 2026, PDF)
• NIST SP 800-218, Secure Software Development Framework 1.1
• NIST SP 800-161r1-upd1, Cybersecurity Supply Chain Risk Management
• CycloneDX, Cryptography Bill of Materials
• CycloneDX, Hardware Bill of Materials
• CycloneDX, Vulnerability Disclosure Report
• CycloneDX specification, bom-1.6 JSON schema
• SPDX 3.0.1, AIPackage class
• SPDX 3.0.1, DatasetPackage class
• OWASP GenAI Security Project, OWASP AIBOM
• cdxgen README, CycloneDX GitHub
• cdx-validate documentation, CycloneDX GitHub
• CycloneDX CLI README
• Sigstore, signing blobs with cosign

Last reviewed: 24 October 2026.