SBOM Compliance: 2026 Requirements by Regulation and Industry

TL;DR Two laws require an SBOM by name for connected products: the EU Cyber Resilience Act and FDA Section 524B. Several more require a software inventory without using the word, including PCI DSS requirement 6.3.2. US federal procurement no longer has a uniform mandate: since January 2026, agencies decide case by case and may require an SBOM by contract. What goes in the file is set by guidance, now the CISA 2026 Minimum Elements and Germany's BSI TR-03183-2. One accurate inventory, built from what actually ships, can feed all of them.

What is SBOM compliance?

SBOM compliance means producing, maintaining, and handing over software bills of materials that satisfy whichever rules apply to your product, market, and customers.

There is no single SBOM compliance standard. The rules sort into three tiers, and they bind in different ways.

• Laws that require an SBOM by name. The EU CRA and FDA Section 524B. Miss these and the product does not reach the market.
• Rules that require an inventory without the word. PCI DSS 6.3.2, NIS2, DORA, and many procurement contracts. An SBOM is the practical way to meet them.
• Guidance that defines what the file contains. The CISA 2026 Minimum Elements, BSI TR-03183-2, and NIST's Secure Software Development Framework. None is law on its own, but regulators and customers write them into expectations and contracts.

Most compliance gaps come from treating the third tier as optional. A file can satisfy a law's text and still fail the customer questionnaire written against the guidance.

SBOM compliance requirements by regulation

EU Cyber Resilience Act

The CRA requires manufacturers to draw up an SBOM in a commonly used, machine-readable format covering at least top-level dependencies, and to keep it in the technical documentation for market surveillance authorities. That obligation applies from 11 December 2027. Article 14 reporting of actively exploited vulnerabilities, which needs the inventory to work, has applied since 11 September 2026. Medical devices and type-approved vehicles are excluded. The full breakdown, including an annotated example, is in EU CRA SBOM requirements.

FDA Section 524B

Section 524B(b)(3) of the FD&C Act requires sponsors of cyber device submissions to provide an SBOM covering commercial, open-source, and off-the-shelf software. FDA's February 2026 guidance adds each component's level of support and end-of-support date, and an assessment of known vulnerabilities. A missing SBOM is grounds for a Refuse to Accept decision. Details are in FDA SBOM requirements for medical devices.

US federal procurement

Executive Order 14028 started federal SBOM adoption in 2021, but no uniform federal SBOM mandate exists in 2026. On 23 January 2026, OMB Memorandum M-26-05 rescinded M-22-18 and M-23-16, the memos that required standardized secure-development attestations from software producers. Agencies now set their own risk-based assurance policies and may adopt contract terms requiring a current SBOM on request. For suppliers, that means the requirement arrives in the contract, agency by agency.

PCI DSS 4.0.1

Requirement 6.3.2 requires an inventory of bespoke and custom software and the third-party components built into it, maintained to support vulnerability and patch management. It became mandatory on 31 March 2025. PCI DSS never says "SBOM," but an SBOM is the most direct way to show an assessor the inventory exists and stays current.

NIS2 and DORA

Neither names the SBOM. NIS2 requires essential and important entities to manage supply chain security, and DORA requires financial entities to track ICT dependencies and third-party risk. Both push SBOM requests downstream to the suppliers of those entities, which is where most device makers feel them.

BSI TR-03183-2 and the CISA 2026 Minimum Elements

These two documents decide what a compliant SBOM contains. BSI TR-03183-2 v2.1.0 is the most detailed public interpretation of the CRA's SBOM requirement, with mandatory fields, formats, and depth. The CISA 2026 Minimum Elements replaced the 2021 NTIA baseline on 29 July 2026 and expanded it from seven fields to 17. Neither is law, and both now shape what regulators and customers ask for.

Other jurisdictions

• South Korea announced in October 2025 that SBOM submission for IT systems and products used in the public sector will be institutionalized by 2027.
• India's CERT-In published technical guidelines on SBOMs in October 2024 for government bodies, essential services, and software producers.
• The UK's Software Security Code of Practice, published May 2025, is voluntary. It does not mandate SBOMs by name but expects software composition awareness and vulnerability management.

What does a compliant SBOM contain in 2026?

The CISA 2026 Minimum Elements set the US baseline, BSI TR-03183-2 sets the EU working reference, and FDA adds lifecycle fields for medical devices. The 2021 NTIA list is no longer current.

Build to the union of these columns once, and one SBOM serves every regime. Build to the narrowest one, and you regenerate for every customer.

Which industries require SBOMs?

Any company shipping connected products into the EU, medical devices into the US, or software into federal and payment environments faces an SBOM requirement or an inventory requirement that an SBOM meets.

SBOM compliance vs traditional vulnerability scanning

A vulnerability scan answers whether code has known flaws today. SBOM compliance answers whether you can prove what is in a shipped product, to a regulator, on request, years later.

The two depend on each other. Scanning is how you populate the vulnerability side, and the SBOM is what makes a scan result attributable to a specific shipped version. Neither replaces the other.

How do you create SBOM compliance documentation?

Scope the regimes, generate one SBOM per release from what ships, enrich it, keep decisions separate, and package the evidence each regulator expects.

1. Map products to regimes. List which products go to which markets and customers, and which tier of rule each one triggers.
2. Generate an SBOM for every release. A new SBOM whenever any component changes, in SPDX or CycloneDX at versions current enough for BSI.
3. Generate from the shipped artifact. The build manifest records what you intended to ship. Only the delivered binary can supply hashes and reveal statically linked libraries and supplier code nobody declared.
4. Verify supplier SBOMs. Check every supplier-provided SBOM against the binary before it enters your inventory.
5. Enrich each component. Add identifiers, licenses, support status, and end-of-support dates.
6. Record decisions outside the SBOM. Exploitability calls go in VEX with the reasoning; advisories go out as CSAF.

1. Package per regime. The same inventory feeds a CRA technical file, an FDA premarket submission, and a PCI DSS assessment, each in the shape that reviewer expects.
2. Retain and version. Keep every SBOM retrievable for the support period, and for at least 10 years under the CRA.

The ongoing work behind steps 2 through 6 is SBOM management.

Managing open-source dependencies for SBOM compliance

Most SBOM compliance effort goes into open source, because most components are open source and most of those were chosen by someone else.

Black Duck's 2026 OSSRA report found that 64% of open-source components are transitive, pulled in by a direct dependency rather than selected by anyone. Three requirements land hardest on them.

• Depth. CISA 2026 asks for all components with no minimum depth, and BSI requires recursion to the first component outside your scope of delivery. A top-level list misses two thirds of what ships.
• License identifiers. CISA and BSI both expect licenses, and BSI requires SPDX identifiers rather than free text. A wrong or missing license field is a compliance finding in its own right; open source license types covers what each license obliges you to do.
• Support status. FDA expects each component's support level and end-of-support date. Abandoned open-source libraries are common in long-lived devices, and the field has to say so.

Embedded C and C++ make all three harder. With no standard package manager, open source arrives as vendored trees, copied files, and supplier blobs that no manifest records.

SBOM compliance challenges and risks

The hard part is rarely producing a file. It is producing one that is true, current, and defensible for every version still in the field.

• Binary-only components. Statically linked libraries, RTOS images, and supplier blobs leave no package record. A manifest-driven SBOM omits them and reads as complete.
• Supplier SBOM quality. Supplier files arrive in different formats and versions, with sparse fields and no proof they match what was delivered.
• Staleness. An SBOM describes one build on one day. Every patch makes the last one wrong.
• Format and version drift. BSI accepts only CycloneDX 1.6+ or SPDX 3.0.1+, and plenty of tooling still emits older versions.
• Overlapping regimes. The same product can face the CRA, FDA, and customer contracts at once, each asking for different fields and packaging.
• Vulnerability noise. A complete SBOM matched against vulnerability databases produces far more findings than are real. Without recorded exploitability decisions, the queue never shrinks; SBOM vulnerability management covers the triage.
• Retention. The CRA expects technical documentation to stay available for at least 10 years, which means an SBOM archive, not a folder of exports.

SBOM compliance best practices

1. Build to the strictest baseline you face. One SBOM that meets BSI, CISA, and FDA together beats three that each meet one.
2. Generate on every release, automatically. Tie generation to the release pipeline so no one has to remember.
3. Reconcile the build SBOM with the binary. Keep both and treat disagreements as findings.
4. Treat supplier SBOMs as claims. Verify before ingesting.
5. Keep vulnerability state out of the SBOM. Use VEX for decisions and CSAF for advisories.
6. Version and sign. Tie each SBOM to a release, and sign it so recipients can verify authenticity.
7. Decide what you share in advance. Define the regulator, customer, and internal views before anyone asks.
8. Name one owner. Product security, the PSIRT, or compliance, with named handoffs to the others.

How Finite State helps with SBOM compliance

Finite State generates SBOMs directly from firmware and binaries, with no source code required, and reconciles supplier SPDX and CycloneDX files against what the image contains. The result is one ground truth inventory per product that every regime draws from.

On top of that inventory, the platform monitors each version for newly disclosed vulnerabilities, records exploitability decisions as VEX with the reasoning attached, and exports SPDX, CycloneDX, VEX, and compliance packages mapped to the EU CRA, FDA guidance, IEC 62443, and ISO/SAE 21434. For CRA programs, managed CRA services cover the documentation and process work.

Key takeaways

• There is no single SBOM compliance standard. Two laws name the SBOM, several rules require an inventory, and guidance defines the content.
• US federal SBOM requirements are now contractual. OMB M-26-05 rescinded the uniform attestation memos in January 2026.
• The NTIA baseline is retired. CISA 2026 and BSI TR-03183-2 define current fields.
• CRA reporting is already live. The SBOM duty follows in December 2027.
• Build once to the strictest baseline. Then package per regime.
• Accuracy beats volume. An SBOM that omits binary-only components is a compliance gap, however well formatted.

One first move. List every product you ship, the markets it reaches, and the tier of rule each market triggers. The products with a law-tier requirement and no current SBOM are your first quarter of work.

FAQ

What is SBOM compliance?

SBOM compliance means producing, maintaining, and providing software bills of materials that meet the rules that apply to your product. Those rules range from laws that require an SBOM by name, such as the EU CRA and FDA Section 524B, to guidance like the CISA 2026 Minimum Elements that defines what the SBOM contains.

Is an SBOM legally required?

In some cases. The EU CRA requires an SBOM for products with digital elements from December 2027, and FDA Section 524B requires one for cyber device submissions. Elsewhere, SBOMs are typically required through contracts or used to meet inventory rules such as PCI DSS requirement 6.3.2.

Do US federal contractors still need to provide SBOMs?

Only where the contract requires it. OMB Memorandum M-26-05 of January 2026 rescinded the uniform attestation memos and lets each agency set risk-based requirements, including contract terms that require a current SBOM on request.

What are the minimum elements of a compliant SBOM?

The CISA 2026 Minimum Elements define 17 data fields, including SBOM author, timestamp, component producer, name, version, identifiers, hash, and license. They replaced the 2021 NTIA baseline of seven fields on 29 July 2026.

What format should a compliant SBOM use?

SPDX or CycloneDX. Both satisfy the CISA baseline and the CRA's commonly used format requirement. Germany's BSI TR-03183-2 requires CycloneDX 1.6 or later or SPDX 3.0.1 or later.

How often should an SBOM be updated for compliance?

Whenever the software changes, which in practice means every release. BSI TR-03183-2 requires a separate SBOM for each software version, and the CRA requires technical documentation to stay current through the support period.

How is SBOM compliance different from vulnerability scanning?

Scanning finds known vulnerabilities in code at a point in time. SBOM compliance requires a versioned, retained record of what each shipped product contains, with vulnerability decisions documented separately, so it can be produced for a regulator years after release.