CRA SBOM requirements: NTIA minimum elements vs BSI TR-03183-2

The Cyber Resilience Act (Regulation (EU) 2024/2847) requires manufacturers to draw up a software bill of materials (SBOM). It does not say which fields the SBOM must have. Two documents fill that gap in practice: the NTIA minimum elements (United States, 2021) and the BSI Technical Guideline TR-03183-2 (Germany). This page shows what each asks for, so you can pick a target for your own SBOM.

What the Regulation itself requires

Annex I, Part II, point 1 obliges manufacturers to identify and document vulnerabilities and components in the product, including by drawing up a software bill of materials in a commonly used and machine-readable format that covers, at the very least, the top-level dependencies of the products. The SBOM is part of the technical documentation (Annex VII), and market surveillance authorities can request it on a reasoned request, where needed to check compliance with Annex I. Nothing in the Regulation names CycloneDX, SPDX, NTIA or BSI. A harmonised standard or a Commission implementing act may detail the format later; until then, the two documents below are the common reference points.

NTIA minimum elements (2021)

The NTIA's "Minimum Elements For a Software Bill of Materials" has three parts. The data fields are:

| Field | Meaning | |---|---| | Supplier name | Who supplies the component | | Component name | Name given by the supplier | | Version | Version of the component | | Other unique identifiers | For example a package URL (purl) or CPE | | Dependency relationship | Which component includes which | | Author of SBOM data | Who created the SBOM | | Timestamp | When the SBOM data was assembled |

The other two parts are automation support (a machine-readable format: SPDX, CycloneDX or SWID) and practices: frequency of updates, depth, known unknowns, distribution and delivery, access control and accommodation of mistakes. The NTIA list is a baseline. It does not ask for hashes or licences.

BSI TR-03183-2

TR-03183-2 is part of the BSI's technical guideline on cyber resilience requirements for manufacturers, and it describes SBOM requirements in detail. It starts from the NTIA fields and adds more, in particular:

• a SHA-512 hash of the deployable component,
• the licence of each component, as SPDX identifiers or expressions,
• the filename and properties such as whether a component is executable, an archive or structured,
• a creator and timestamp for the SBOM itself, and a completeness indicator for the dependencies of each component,
• a stated minimum version of CycloneDX or SPDX (in version 2.1.0 of the guideline, CycloneDX 1.6 and SPDX 3.0.1).

Some identifiers (purl, CPE) are required only where available, and the version can be replaced by a modification date. The guideline is updated from time to time, including the minimum format versions, so read the current version on the BSI website before you build a pipeline around it.

Side by side

| Topic | CRA (Annex I Part II) | NTIA 2021 | BSI TR-03183-2 | |---|---|---|---| | Machine-readable format | Required ("commonly used") | Required (SPDX, CycloneDX, SWID) | Required (CycloneDX or SPDX, minimum versions stated) | | Depth | At the very least top-level dependencies | At minimum all top-level dependencies, with enough detail to trace transitive ones; known unknowns flagged | Dependencies per component with a completeness indicator; no separate depth rule found, check the current text | | Supplier, name, version | Implied | Required | Creator and name required; version or a modification date | | Unique identifier (purl, CPE) | Not specified | Required | Where available | | Dependency relationships | Not specified | Required | Required | | Author and timestamp | Not specified | Required | Required | | Hashes | Not specified | Not required | Required (SHA-512 of the deployable component) | | Licences | Not specified | Not required | Required (SPDX identifiers or expressions) | | Status | Law | Guidance | Guidance (not binding law) |

Which one should you aim for

• Minimum to be defensible: NTIA fields in CycloneDX or SPDX, generated by your build, covering at least top-level dependencies.
• Selling in Germany or to public bodies: aim for the BSI fields as well and ask the buyer which version they expect; it costs little if your build tool already emits hashes and licences.
• In every case: generate the SBOM from the build for every release, keep it with the release, and be ready to hand it over on request.

The SBOM checker tests a CycloneDX or SPDX JSON file against the NTIA elements and the Regulation's wording in your browser; the file is not uploaded. The repository check shows whether GitHub can export a dependency graph for your project.

Notes

This page is general information, not legal advice. The BSI guideline is not binding law, and its content changes between versions; check the primary sources (NTIA, BSI, EUR-Lex) before you rely on a detail.