Usama · Founder
Key takeaways
From December 11, 2027, the EU Cyber Resilience Act requires makers of products with digital elements to draw up a software bill of materials. The law itself says little about what goes in it. Annex I, Part II, point 1 asks for an SBOM "in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products" (Regulation (EU) 2024/2847). It does not list fields.
Two documents fill that gap, and both were updated recently. In July 2026, CISA and partner agencies from more than a dozen countries published the 2026 Minimum Elements for an SBOM. Germany's BSI maintains Technical Guideline TR-03183-2, now at version 2.1.0, which is written with the CRA in mind. If you are choosing SBOM software or setting up your build pipeline, you want output that satisfies both. This guide compares them field by field and suggests what an EU maker should actually include.
Short on time?
One question each, with a short answer and a link to its full section.
Question 1 of 8
No. It asks for a commonly used, machine-readable format covering at least top-level dependencies. CycloneDX and SPDX are the two formats both guides recognise.
Read the full section: Does the CRA require a specific SBOM format?Question 2 of 8
The CRA does not require you to publish it to users. It forms part of your technical documentation, which market surveillance authorities can request.
Read the full section: Do I have to publish my SBOM?Question 3 of 8
Generate CycloneDX 1.6 or later, or SPDX 3.0.1 or later, in JSON. BSI requires those versions. CISA names both formats as common.
Read the full section: Format and version rulesQuestion 4 of 8
Mostly. Add tool name and version, generation context, SBOM version and a signature, and record component producer names alongside contact details.
Read the full section: If I follow BSI TR-03183-2, do I also meet CISA's 2026 elements?Question 5 of 8
SHA-512 of the deployable file, with the algorithm named. CISA allows a NIST-approved algorithm. BSI fixes the hash at SHA-512.
Read the full section: Hash algorithmQuestion 6 of 8
Past the CRA floor of top-level dependencies. CISA asks for all components. BSI requires recursive resolution through everything in your delivery.
Read the full section: How deep to goQuestion 7 of 8
From December 11, 2027, when the main CRA obligations take effect.
Read the full section: When does the CRA SBOM duty apply?Question 8 of 8
Say whether the data is unknown or withheld. Do not leave the field silently blank.
Read the full section: What your SBOM software should output for the CRANeither document is the law. CISA says plainly that its minimum elements "do not create new requirements". They describe a baseline. BSI's guideline is a German technical guideline, not an EU standard.
Still, both are useful to an EU maker:
This is where the two differ most sharply.
BSI is strict. A new or updated SBOM must be JSON or XML, and valid against CycloneDX 1.6 or later or SPDX 3.0.1 or later. Only officially released versions of those specifications may be used. BSI also expects the latest version of its own guideline to be used, with the previous version allowed for six months after a new one comes out.
CISA does not mandate a format. It names SPDX and CycloneDX as the formats in common use, and it adds two fields so the recipient knows what they are reading: SBOM Data Format Name and SBOM Data Format Version. It also says versions declared deprecated by the format's maintainers should not be used.
In practice: generate CycloneDX 1.6+ or SPDX 3.0.1+ in JSON, and you meet both.
The table below maps the fields of the two documents against each other. "Required" for BSI means its required tables (5.2.1 and 5.2.2). "Additional" means BSI requires the field when the information exists. CISA's list is from Table 1 of its 2026 document.
| Topic | CISA 2026 minimum elements | BSI TR-03183-2 v2.1.0 |
|---|---|---|
| Format | SBOM Data Format Name and Data Format Version fields. SPDX and CycloneDX named as common formats | Required: JSON or XML, CycloneDX 1.6+ or SPDX 3.0.1+ |
| Who made the SBOM | SBOM Author: name of the entity that created the SBOM | Creator of the SBOM: email address, or a URL if no email exists |
| When | SBOM Timestamp: last change to the SBOM data | Timestamp of data compilation. UTC recommended |
| SBOM version | SBOM Version field. Semantic Versioning allowed, starting at 1 | Not in BSI's field tables |
| Where to find the SBOM | Covered as a practice (Distribution and Delivery), e.g. a version-specific URL | Additional: SBOM-URI |
| Tool used | SBOM Tool Name and SBOM Tool Version | Not in BSI's field tables |
| Lifecycle stage | SBOM Generation Context (e.g. source or build) | SBOM must hold the information available during the build |
| Signature | SBOM Author Signature | Not in BSI's field tables |
| Who made the component | Component Producer: name of the entity | Component creator: email address, or a URL |
| Component name | Component Name. Multiple names allowed | Required. If no name exists, the actual filename |
| Component version | Component Version. Mark as unknown if none is given | Required. If none exists, the file's modification date in RFC 3339 format |
| Filename | Not a CISA field | Required: actual filename, without the path |
| Identifiers | Component Identifiers: at least one, such as CPE or PURL | Additional: other unique identifiers such as CPE or purl |
| Hash | Component Hash Value and Hash Algorithm, of the executable artifact. NIST-approved algorithm | Required: SHA-512 of the deployable component. Source code hash is optional |
| Licence | Component License, SPDX identifiers where possible, or marked unknown | Required: distribution licences. Additional: original licences. Optional: effective licence. SPDX identifiers mandatory |
| Dependencies | Component Dependency Relationship | Required: direct dependencies, with completeness clearly indicated |
| Depth | Coverage: all components, including transitive ones. No minimum depth | Recursive resolution through everything you deliver, up to the first component outside the delivery |
| File properties | Not CISA fields | Required: executable, archive and structured properties |
| Source and download links | Not CISA fields | Additional: source code URI and URI of the deployable form |
| Security contact | Not a CISA field | Optional: URL of the creator's security.txt |
| Unknown data | Explicitly state whether data is unknown or withheld | Completeness of each dependency list must be stated |
CISA wants the *name* of the SBOM author and the component producer. BSI wants an *email address or URL* for both. These are not in conflict. Most formats let you record a name and a contact together, so fill both.
CISA lets you pick any algorithm approved by a body such as NIST, and asks you to record which one you used. BSI fixes it at SHA-512, taken over the deployable file. If you record SHA-512 and name it, you meet both.
Both point to SPDX licence identifiers. BSI goes further. It requires SPDX identifiers or expressions, then the ScanCode LicenseDB if SPDX has no match, then a `LicenseRef-` identifier of your own. It also says licence text must not be used as a substitute for an identifier. It separates the licence a component is distributed under from the licence its creator assigned and the licence you actually use it under.
The CRA's legal floor is top-level dependencies. CISA asks for all components, with no minimum depth. BSI requires recursive resolution through everything in your delivery, down to and including the first component outside it. If your SBOM software only lists what your manifest declares, it will fall short of both guides even if it meets the CRA's floor.
CISA's 2026 update added several fields about the SBOM itself: tool name and version, generation context, SBOM version, and a signature. BSI does not list these. They cost almost nothing to add, and they help a customer or authority judge how the SBOM was produced.
A practical target that satisfies the CRA floor, BSI and CISA together:
When you compare SBOM software, test it against this list with one of your real products. Many tools produce valid CycloneDX or SPDX, but fewer fill BSI's file properties, filenames and SHA-512 hashes by default.
Your suppliers matter too. If a component arrives as a binary from a supplier, you depend on their SBOM. BSI allows you to reference a supplier's SBOM instead of merging it, but only if it meets the guideline, and you remain responsible for its availability. Our SBOM and supplier evidence service helps makers set up generation in the pipeline and collect usable SBOMs from suppliers. For the wider timeline, see our page on CRA dates, and for the terms used here, the CRA glossary.
No. It asks for a commonly used, machine-readable format covering at least top-level dependencies. CycloneDX and SPDX are the two formats both CISA and BSI recognise.
The CRA does not require you to publish it to users. It forms part of your technical documentation, which market surveillance authorities can request.
Mostly. Add CISA's SBOM metadata fields (tool name and version, generation context, SBOM version, signature) and record component producer names alongside contact details.
From December 11, 2027, when the main CRA obligations take effect.
Not sure whether your SBOMs would hold up to a reasoned request? We will review a sample SBOM from your pipeline against both documents and tell you plainly what is missing. Book a free 30-minute call.
CycloneDX and SPDX for every release, plus supplier bills and component search.
Founder of Samisoftz. He writes these pages and builds the software. About Usama
You'll talk to Usama, who'd build it.
30 minutes · no slides · a written answer if it's not a fit
One fixed price, in writing, the same day you ask · a delivery date agreed in writing · about 4 hours of your engineers' time · the price only changes if the scope does.
NDA before anything sensitive · the drill runs on sample data · no production access · every document is yours.
