CycloneDX or SPDX: which SBOM format for the CRA?

What does the CRA say about the format?

Annex I, Part II, point 1 requires manufacturers to identify and document vulnerabilities and 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 of the products. The Regulation names no specific format.

The Commission may specify the format and elements by implementing acts (Art. 13(24)). As of 23 October 2026 no such act has been adopted. The SBOM obligation applies from 11 December 2027.

Which versions of CycloneDX and SPDX apply in October 2026?

What does TR-03183-2 require per component?

For German manufacturers the guideline is the most precise statement of what an SBOM should contain. For the SBOM itself it requires the creator and a timestamp (§ 5.2.1), and for each component:

1. 1

   Creator of the component, as an e-mail address or URL.

2. 2

   Name and version. If there is no version, the modification date of the file.

3. 3

   File name of the component.

4. 4

   Dependencies on other components, with a statement of whether the list is complete.

5. 5

   Distribution licences.

6. 6

   Hash value of the shipped component, as SHA-512.

7. 7

   Whether the component is executable, an archive, and structured.

Which fields do the schemas themselves require?

That an SBOM is valid against its schema says little about its content. CycloneDX requires only bomFormat and specVersion in the document, and type and name for each component. SPDX 2.3 requires spdxVersion, dataLicense, SPDXID, name and creationInfo, and SPDXID, name and downloadLocation for each package. SPDX 3.0.1 requires only creationInfo for each element, with created, createdBy and specVersion.

None of the three schemas requires a version for each component, nor a hash. TR-03183-2 requires both. So check an SBOM twice: against the schema, and against the fields you need.

$ curl -s https://raw.githubusercontent.com/CycloneDX/specification/1.7.2/schema/bom-1.7.schema.json  \
| jq -c '.required, .definitions.component.required'

["bomFormat","specVersion"]
["type","name"]

$ curl -s https://raw.githubusercontent.com/spdx/spdx-spec/v2.3/schemas/spdx-schema.json  \
| jq -c '.required, .properties.packages.items.required'

["SPDXID","creationInfo","dataLicense","name","spdxVersion"]
["SPDXID","downloadLocation","name"]

$ curl -s https://spdx.org/schema/3.0.1/spdx-json-schema.json  \
| jq -c '."$defs".Element_props.allOf[1].required, ."$defs".CreationInfo_props.allOf[1].required'

["creationInfo"]
["created","createdBy","specVersion"]

$ curl -s https://api.github.com/repos/spdx/spdx-spec/releases  \
| jq -r '.[0:3][] | "\(.tag_name) \(.published_at[0:10]) prerelease=\(.prerelease)"'

v3.1-RC1 2026-01-24 prerelease=true
3.0.1 2024-12-17 prerelease=false
v3.0 2024-04-15 prerelease=false

How do CycloneDX and SPDX describe a firmware component?

For firmware, what counts most is whether a component is identified unambiguously, because matching it against vulnerabilities depends on that. Both formats carry the Package URL (purl) and CPE for this. CycloneDX has the component type firmware, SPDX 2.3 the purpose FIRMWARE, SPDX 3.0.1 the purpose firmware.

$ jq -r '.bomFormat, .specVersion' sbom.json

CycloneDX
1.6

$ jq '.metadata.component | {type,name}' sbom.json

{
  "type": "firmware",
  "name": "ble_freertos_amota.axf"
}

$ jq '.components[] | select(.name=="FreeRTOS") | {type,name,version,purl}'  \
sbom.json

{
  "type": "library",
  "name": "FreeRTOS",
  "version": "10.1.1",
  "purl": "pkg:generic/FreeRTOS@10.1.1"
}

Which differences matter day to day?

CycloneDX or SPDX: which should I use?

1. 1

   If a customer or auditor asks for TR-03183-2: CycloneDX 1.6 or later or SPDX 3.0.1 or later, JSON or XML.

2. 2

   If your toolchain already uses a format: stay with it. Tools convert between the two, but lose fields the target does not know.

3. 3

   A separate SBOM for each shipped firmware version, from the build that is shipped.

4. 4

   Keep vulnerability status separately: the SBOM says what is inside, VEX and CSAF say which of it is exploitable.