SBOM Requirements: CRA, FDA, Federal Contracts, and PCI DSS

Four sets of rules now ask for a software bill of materials (SBOM), each in a different way. Section 524B of the US Federal Food, Drug, and Cosmetic Act has required an SBOM in premarket submissions for cyber devices since March 29, 2023. From December 11, 2027, the EU Cyber Resilience Act (CRA) requires manufacturers of products with digital elements to keep an SBOM in a commonly used, machine-readable format, covering at least top-level dependencies, in their technical documentation, with no duty to publish it. US federal agencies may require a current SBOM on request through contract terms under OMB memorandum M-26-05, and PCI DSS requirement 6.3.2 requires an inventory of custom software and its third-party components. One program built to CISA's 2026 minimum elements, in SPDX or CycloneDX, meets all four.

Which laws and contracts require an SBOM?

The table compares the drivers product security teams meet most often. They differ on depth, format, and audience, so a program built around one usually falls short of another.

What does the Cyber Resilience Act require in an SBOM?

The CRA sets cybersecurity requirements for hardware and software products with digital elements sold in the EU, and our Cyber Resilience Act guide covers its scope, product classes, and conformity assessment. The SBOM duty sits in the vulnerability handling requirements. Annex I, Part II, point (1) of Regulation (EU) 2024/2847 requires manufacturers to identify and document the vulnerabilities and components in their products, including by drawing up an SBOM "in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products." Article 3(39) defines an SBOM as a formal record of the details and supply chain relationships of the components in a product's software.

Three provisions decide who sees it. Annex VII, point 2(b) places the SBOM in the technical documentation as part of the vulnerability handling information, and Annex VII, point 8 lets a market surveillance authority obtain it through a reasoned request when it needs the SBOM to check compliance with Annex I. Recital 77 states that manufacturers "should not be obliged to make the SBOM public," and Annex II, point 9 asks the user instructions to say where the SBOM can be accessed only if the manufacturer decides to share it with users. Article 13(25) also lets authorities collect SBOMs from a whole product category for a Union-wide dependency assessment, and recital 22 asks them to protect the confidentiality of what they receive.

The regulation names no format. Article 13(24) lets the Commission specify the format and elements by implementing act, taking European or international standards into account. Germany's Federal Office for Information Security (BSI) has published a detailed reading in Technical Guideline TR-03183-2, version 2.1.0, written to give manufacturers early sight of the kind of requirements the CRA brings. It requires CycloneDX 1.6 or later or SPDX 3.0.1 or later, a separate SBOM for each software version, recursive dependency resolution for every component in the scope of delivery, and a SHA-512 hash for each component.

The SBOM also serves two neighboring duties. Article 13(5) requires due diligence on third-party components, including free and open-source components, and Article 13(6) requires a manufacturer that finds a vulnerability in a component to report it to whoever maintains that component and to share any fix it wrote. Reporting of actively exploited vulnerabilities and severe incidents under Article 14 has applied since September 11, 2026, and a current SBOM is how a manufacturer finds out within hours whether an exploited component ships in its product. Our guide to CRA reporting obligations covers that clock.

What does the FDA require for medical device SBOMs?

Section 524B of the FD&C Act (21 U.S.C. 360n-2), added by the Consolidated Appropriations Act, 2023, requires the sponsor of a premarket submission for a cyber device to "provide to the Secretary a software bill of materials, including commercial, open-source, and off-the-shelf software components." A cyber device is one that includes software validated, installed, or authorized by the sponsor, can connect to the internet, and has characteristics that could be vulnerable to cybersecurity threats. The requirement took effect 90 days after the law was signed on December 29, 2022, which FDA puts at March 29, 2023.

FDA's guidance, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, sets out what reviewers expect; the current edition, issued February 3, 2026 to align with the Quality Management System Regulation, supersedes the June 27, 2025 version. It asks for machine-readable SBOMs consistent with the baseline attributes in NTIA's October 2021 document Framing Software Component Transparency, covering manufacturer-developed components, third-party components, and upstream dependencies. FDA adds two fields per component that no other regime in this guide asks for: the level of support from the component's maker, such as actively maintained or abandoned, and the end-of-support date. The submission should also identify all known vulnerabilities in the device and its components, including those in CISA's Known Exploited Vulnerabilities catalog, with a risk assessment and the controls that address each one. FDA treats the SBOM as part of configuration management, updated whenever the software in a marketed device changes.

Do US federal contracts require an SBOM?

A federal contract requires an SBOM only when its terms say so. Executive Order 14028 of May 12, 2021 listed "providing a purchaser a Software Bill of Materials (SBOM) for each product directly or by publishing it on a public website" among the software supply chain practices it directed the government to define. NTIA published The Minimum Elements for a Software Bill of Materials on July 12, 2021, with seven data fields and SPDX, CycloneDX, and SWID tags as the accepted formats. OMB memorandum M-22-18 of September 14, 2022 required agencies to collect secure development self-attestations from software producers and allowed them to require SBOMs in solicitations based on the software's criticality, and M-23-16 of June 9, 2023 extended its deadlines.

Two later actions changed that framework. Executive Order 14306 of June 6, 2025 struck the plan in Executive Order 14144 for CISA to validate producer attestations and publish the results; neither order mentions SBOMs, so EO 14028's SBOM language stands. On January 23, 2026, OMB memorandum M-26-05 rescinded M-22-18 and M-23-16, made the secure software development attestation form optional, and told agencies they may adopt contract terms requiring a producer to provide a current SBOM upon request. For cloud platforms, the memo says the term should cover the runtime production environment. Review existing contracts for SBOM and attestation clauses written under M-22-18, because a clause stays in a contract after the memo behind it is rescinded.

The reference for SBOM content is now CISA's 2026 Minimum Elements for a Software Bill of Materials, published July 29, 2026 with NSA, FBI, and 15 international partner agencies after public comment on an August 2025 draft. The document states that it updates and replaces NTIA's 2021 list. It adds an SBOM author signature, data format name and version, generation context, tool name and version, and SBOM version, and it adds a hash value, hash algorithm, and license for each component. Coverage now means every component, including transitive dependencies, with no minimum depth. It names SPDX and CycloneDX, drops SWID tags, and expects a new SBOM with each build or release.

What does PCI DSS 6.3.2 require, and is it an SBOM?

PCI DSS v4.0.1 requirement 6.3.2 requires an entity to maintain an inventory of its bespoke and custom software and of the third-party components built into that software, so it can manage vulnerabilities and patches. It was one of the 51 future-dated requirements in version 4, which the PCI Security Standards Council confirmed took effect on March 31, 2025. The requirement never uses the term SBOM, sets no format, and requires no one outside the entity to receive the inventory, which makes it closer to an asset register than to the documents the CRA and FDA expect.

The two meet in the build. An SBOM generated for each bespoke application is that inventory in machine-readable form, with versions, identifiers, and dependency relationships attached, so a team that already produces SBOMs can meet 6.3.2 from the same data. A hand-kept spreadsheet can satisfy the wording, but it cannot show within minutes whether a newly disclosed library flaw sits in the payment flow.

What should an SBOM clause in a customer contract say?

A customer that asks for an SBOM in a contract needs terms both sides can test. Name the format and minimum version, for example CycloneDX 1.6 or SPDX 3.0.1 and later, the versions BSI's guideline accepts. Point to CISA's 2026 minimum elements for the fields, require all components including transitive dependencies, and set a new SBOM at each release. Specify the delivery channel, such as a customer portal or an API with access control, and the confidentiality terms, since an SBOM maps the product's attack surface. Decide whether you will issue VEX statements for vulnerabilities that do not affect the product, and for how long after a version's end of support you will keep answering. Suppliers should offer the SBOM their pipeline already produces instead of agreeing to a different format for each customer.

SPDX or CycloneDX: which SBOM format should you use?

Use either, generate it natively in the build, and keep the ability to convert. Both formats are named in CISA's 2026 minimum elements, and both are international standards. ISO/IEC 5962:2021 standardizes SPDX version 2.2.1, and an ISO edition based on SPDX 3.0 entered its final approval stage on October 19, 2026. SPDX 3.0 organizes the specification into profiles, including Software, Security, Licensing, Build, AI, and Dataset. Ecma International publishes CycloneDX as ECMA-424; the first edition appeared in June 2024, and the second edition of December 2025 standardizes CycloneDX 1.7, which describes software and hardware components, services, dependencies, vulnerabilities, cryptographic assets, and machine learning models.

The identifiers inside the SBOM matter more than the format. CISA's 2026 elements say each component should carry at least one identifier, using common identifiers such as a Common Platform Enumeration (CPE) name or a Package URL (PURL), and may add intrinsic identifiers such as SWHID or OmniBOR. PURL names a package with one syntax across ecosystems such as npm, Maven, and PyPI, and Ecma standardized it as ECMA-427 in December 2025. CPE is the naming scheme the National Vulnerability Database uses, so carrying both lets one SBOM match more vulnerability sources. Pick one format as the system of record, pin its version in the build tooling, and convert only when a customer requires the other.

What is VEX, and how does it relate to an SBOM?

A Vulnerability Exploitability eXchange (VEX) statement tells a customer whether a product is affected by a vulnerability in one of its components. It answers the question an SBOM raises: the SBOM shows that a vulnerable version of a library is present, and the VEX states whether the product is affected, not affected, fixed, or under investigation, with a justification when it is not affected. Keep VEX in a separate document, because the SBOM changes with each release while VEX status changes as analysis finishes. BSI's TR-03183-2 makes that a rule: an SBOM must not contain vulnerability information, and BSI recommends CSAF for distributing it.

Several formats carry VEX. The Common Security Advisory Framework (CSAF) 2.0, an OASIS Standard since November 18, 2022, includes a VEX profile. OpenVEX is a minimal, community-governed format designed to be embedded in other documents. CycloneDX expresses exploitability natively, and the SPDX 3.0 Security profile defines VEX relationships for the four statuses. FDA already expects an assessment of known vulnerabilities in SBOM components, and CISA's 2026 minimum elements name VEX as an area for future work. Produce VEX from the same triage queue your vulnerability management program runs, so the public statement and the internal ticket never disagree; our guide to building a vulnerability management program describes that queue.

What does a usable SBOM program look like?

A usable program produces a correct SBOM for every release without manual assembly and ties each SBOM to the vulnerability process. The figure shows what each regime expects of the SBOM, and the program below meets all of it.

Build it in six parts, in this order.

1. Generate it in the build. Produce the SBOM in the CI pipeline from the artifact you ship, record CISA's generation context, and store the SBOM with the release. Each new build or release gets a new SBOM, and each correction gets a new SBOM version.
2. Go past the top level. Resolve transitive dependencies for everything you deliver, as CISA's 2026 elements and BSI's guideline expect, and mark unknown components as unknown so gaps stay visible. Add binary analysis for third-party firmware and vendor libraries that arrive without their own SBOM.
3. Identify and hash each component. Record the producer, version, PURL, and CPE, plus a hash and its algorithm; SHA-512 meets BSI's requirement.
4. Sign and version the SBOM. Sign it with a key held in a key management service, number each version, and keep every version as long as the CRA requires you to keep technical documentation: at least ten years after the product is placed on the market, or the support period if that is longer.
5. Connect it to vulnerability management. Feed each SBOM to your software composition analysis tool, match components against advisories and CISA's KEV catalog every day, and publish VEX statements from the same triage.
6. Deliver it on request. Hold SBOMs in a portal or API with access control, share them under confidentiality terms, and log which customer or authority received which version.

How BD Emerson builds SBOM programs

We start by mapping which rules reach each product (the CRA, FDA's premarket expectations, federal contract terms, PCI DSS, and your customers' clauses) and then design one SBOM program to the strictest of them. Our Cyber Resilience Act compliance team runs readiness and gap assessments against Annex I, designs the SBOM and VEX process, supports the technical documentation, and tests product security. Our DevSecOps consultants put SBOM generation, hashing, and signing into your build pipeline, and our vulnerability management practice connects stored SBOMs to triage and VEX. BD Emerson is not a notified body and does not perform third-party conformity assessment, so the firm preparing you has no stake in the assessment's outcome. We do not resell SBOM or software composition analysis tools and take no license margin, so our tooling advice follows what your pipeline needs.

Frequently asked questions

Is an SBOM mandatory under the Cyber Resilience Act? The CRA makes it mandatory from December 11, 2027. Annex I, Part II, point (1) requires manufacturers of products with digital elements to draw up a software bill of materials in a commonly used, machine-readable format covering at least the top-level dependencies. The SBOM belongs in the technical documentation, and a market surveillance authority can request it when it needs the SBOM to check compliance with Annex I.

Does the CRA require manufacturers to publish their SBOM? The CRA does not require publication. Recital 77 of the Cyber Resilience Act says manufacturers should not be obliged to make the SBOM public. The SBOM sits in the technical documentation, which market surveillance authorities can request. If a manufacturer chooses to share the SBOM with users, Annex II, point 9 requires the user information to say where the SBOM can be accessed.

What are the minimum elements of an SBOM? CISA's 2026 Minimum Elements, published July 29, 2026, replace NTIA's 2021 list. The SBOM metadata covers the author, author signature, data format name and version, generation context, timestamp, tool name and version, and SBOM version. Each component needs a name, producer, version, identifiers such as PURL or CPE, a hash value and algorithm, a license, and its dependency relationships, with transitive dependencies included.

Does the FDA require an SBOM for medical devices? For cyber devices, it does. Section 524B of the FD&C Act has required sponsors to provide an SBOM covering commercial, open-source, and off-the-shelf components in premarket submissions since March 29, 2023. FDA's February 3, 2026 guidance asks for a machine-readable SBOM, each component's support level and end-of-support date, and an assessment of known vulnerabilities, including those in CISA's Known Exploited Vulnerabilities catalog.

Which SBOM format is required, SPDX or CycloneDX? No law requires one over the other. The CRA asks for a commonly used, machine-readable format without naming one, and CISA's 2026 minimum elements name both SPDX and CycloneDX. Both are international standards: SPDX 2.2.1 as ISO/IEC 5962:2021 and CycloneDX 1.7 as ECMA-424. Germany's BSI guideline for the CRA accepts CycloneDX 1.6 or later and SPDX 3.0.1 or later.

What is the difference between an SBOM and VEX? An SBOM lists the components in a product and how they relate. A VEX statement says whether a specific vulnerability in one of those components affects the product: affected, not affected, fixed, or under investigation. Keep them as separate documents, because the SBOM changes with each release while VEX status changes as analysis finishes. CSAF 2.0, OpenVEX, CycloneDX, and SPDX 3.0 can all carry VEX.

How often should an SBOM be updated? Generate a new SBOM for every build or release you ship, as CISA's 2026 minimum elements and BSI's TR-03183-2 both expect, and issue a revised SBOM when you correct an error or learn more about a component. FDA asks that the SBOM be updated whenever software in a marketed device changes. Matching stored SBOMs against new vulnerability advisories should run every day.

If you are building an SBOM program for the CRA, an FDA submission, or a federal contract, our Cyber Resilience Act compliance team can map which rules reach each product, put SBOM generation and signing into your build, and connect SBOMs and VEX to your vulnerability process.