SBOM compliance: the regulations and frameworks that require SBOMs

SBOM expectations now come from national guidelines, sector regulators, product-safety law and industry standards. This overview shows who requires what, and how binding each source is.

How to read SBOM requirements

SBOM obligations vary in three ways: who must produce or obtain an SBOM (manufacturer, supplier, consumer), how binding the source is (law, regulator directive, guideline, contract), and what content is expected (field list, depth, format). The summaries below reflect public documents as of September 2026.

India

Law-firm commentary describes CERT-In's guidelines as non-mandatory but strongly recommended ^[6]. Sector regulators can make them binding in practice, which SEBI has done for SBOMs. See CERT-In SBOM requirements and SBOM for banks.

European Union

The Cyber Resilience Act (Regulation (EU) 2024/2847) requires manufacturers of products with digital elements to identify and document components, "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" ^[7]. The SBOM belongs in the technical documentation and must be provided to market surveillance authorities on request; it need not be made public ^[8]. Reporting obligations for actively exploited vulnerabilities apply from 11 September 2026 ^[9], with the main obligations applying from 11 December 2027 ^[7].

Germany's BSI publishes TR-03183-2, a technical guideline on SBOMs linked to CRA requirements; version 2.1.0 is dated 3 September 2025 ^[10]. It requires CycloneDX 1.6 or later, or SPDX 3.0.1 or later, SHA-512 hashes, and excludes vulnerability data from the SBOM itself ^[11].

United States

Executive Order 14028 (May 2021) directed the publication of minimum SBOM elements and named providing SBOMs to purchasers as a secure-development practice ^[12]. OMB memorandum M-22-18 then allowed agencies to require SBOMs in solicitations ^[13]. In February 2026, OMB memorandum M-26-05 rescinded M-22-18 and its update, leaving agencies to decide whether to require SBOMs based on risk ^[14]. The technical baseline remains the 2026 Minimum Elements for an SBOM, published by CISA with the NSA and partners on 30 July 2026 ^[15].

For medical devices, section 524B of the FD&C Act requires cyber-device manufacturers to provide the FDA "a software bill of materials, including commercial, open-source, and off-the-shelf software components" ^[16].

Industry standards

PCI DSS v4.0 requirement 6.3.2, mandatory from 31 March 2025, requires an inventory of bespoke and custom software and the third-party components incorporated into it. It does not prescribe an SBOM format, but an SBOM is a practical way to meet it ^[17]. NIST's SSDF practice PS.3.2 calls for collecting and sharing provenance data for each release's components, with an SBOM as the example ^[18].

Common threads

• Formats: CycloneDX and SPDX appear in CERT-In, CISA and BSI guidance.
• Depth: ranges from top-level dependencies (CRA) to full transitive coverage (CISA 2026).
• Currency: SEBI and CERT-In expect SBOMs to be updated when software changes.
• Vulnerability status: CERT-In includes vulnerabilities in the SBOM and recommends VEX, while BSI keeps them out of the SBOM.

Mapping these differences is easier with a single inventory validated against several field policies; see SBOM validation.

How IntelliXBOM helps

IntelliXBOM validates SBOMs against required-field policies such as CERT-In's, maps the inventory to framework controls and produces timestamped evidence. It helps organisations address several of these requirements from one governed inventory; it does not certify compliance.

This article summarises public guidance for information only and is not legal advice; refer to the current official documents before acting.