Compliance Drivers
Why SBOMs stopped being optional — US EO 14028, EU Cyber Resilience Act, and sector rules.
Compliance drivers
Why SBOMs stopped being optional: executive action in the US, a product-regulation regime in the EU, and sector rules that quietly require the same inventory under different names.
Not legal advice. This page summarises the technical substance of each regime so you can map it to SBOM fields. Confirm scope, dates, and obligations with counsel for your products and markets.
US: Executive Order 14028 and the NTIA minimum elements
Executive Order 14028 (May 2021) directed US federal agencies to require SBOMs from software suppliers. The National Telecommunications and Information Administration followed in July 2021 with The Minimum Elements For a Software Bill of Materials, which remains the practical definition of "an SBOM" almost everywhere:
- Supplier name
- Component name
- Version of the component
- Other unique identifiers
- Dependency relationship
- Author of SBOM data
- Timestamp
The rule is format-agnostic — both SPDX and CycloneDX satisfy it. See the field-level mapping for how each standard expresses the seven elements.
EU: Cyber Resilience Act
Regulation (EU) 2024/2847 — the Cyber Resilience Act — is the most consequential development for SBOM programmes. It entered into force in late 2024 and applies in phases:
| Date | What | Note |
|---|---|---|
| 2024-12-10 | Entry into force | Regulation (EU) 2024/2847 |
| 2026-06-11 | Chapter IV applies | Articles 35–51, on conformity assessment bodies (in force now) |
| 2026-09-11 | Article 14 applies | Vulnerability and incident reporting duties begin (in force now) |
| 2027-12-11 | Main obligations apply | The full conformity regime, including technical documentation requirements |
The CRA requires manufacturers of products with digital elements to produce technical documentation that includes an SBOM, in a commonly used and machine-readable format, covering at least the top-level dependencies. In practice that means:
- State the exact specification version you used — CycloneDX 1.7 (ECMA-424 2nd edition) or SPDX 3.0.1 — rather than just "SBOM".
- Cover top-level dependencies at minimum; transitive depth is a competitive advantage, not a requirement.
- Keep the SBOM under change control so it matches the shipped build.
- Expect the SBOM to be part of a conformity package, not a standalone artefact.
Post-quantum and CBOM
A separate driver is cryptography inventory. US OMB M-23-02 and National Security Memorandum 10 push federal agencies toward post-quantum migration, and NIST's CNSA 2.0 suite defines target algorithms. You cannot migrate what you have not inventoried — which is exactly what a Cryptographic Bill of Materials is for.
CycloneDX 1.7 is the most mature vehicle here: the CBOM component type plus the new algorithmFamily object
(primitive type, security strength, NIST status, mode-of-operation requirements) and the closed curve
enumeration make "which components still use RSA-2048?" a machine-checkable query rather than a grep.
Sector rules
| Regime | What it asks for |
|---|---|
| FDA (US medical devices) | Pre-market cybersecurity submissions expect an SBOM as part of the device's software documentation. |
| PCI DSS v4.x | Requires maintaining an inventory of bespoke and third-party software components, updated to support vulnerability management. |
| DORA / financial-sector operational resilience | ICT asset and dependency inventories for critical financial entities — functionally an SBOM requirement. |
| Defence / industrial procurement | Increasingly contractual: specific format plus specific spec version, often with a completeness assertion. |
What to actually ship
Regardless of regime, an SBOM that survives scrutiny has the same properties:
- Seven NTIA elements present and non-empty for every component — not just the top-level one.
- An explicit spec version in the document header.
- A completeness assertion — say what you know you have not covered.
- Rebuilt per build and identified with a serial number, so it can be tied to an artefact.
- Attributable — author, tool, and timestamp; CycloneDX 1.7's
citationslets you go further and attribute individual fields. - Sharing classification — a TLP marking if it leaves your organisation.
- Paired VEX so consumers can distinguish "has vulnerable library" from "is vulnerable".
These are the outputs of two layers of the compliance assurance framework — knowing what you ship, and controlling what leaves. The other three layers are governance, supply-chain verification and sustainment.
Dates and requirements summarised as of September 2026. Regulatory text is authoritative; verify applicability and timelines for your specific products.