Skip to content

Updates CRA document with BSI 2.1 #49

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
vpetersson merged 1 commit into from
Feb 3, 2026
Merged

Updates CRA document with BSI 2.1 #49

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
189 changes: 160 additions & 29 deletions compliance/eu-cra.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@
layout: page
permalink: /compliance/eu-cra/
title: "EU Cyber Resilience Act (CRA) SBOM Requirements"
description: "Complete guide to SBOM requirements under the EU Cyber Resilience Act, including format requirements, dependency coverage, and authority access obligations."
description: "Complete guide to CRA SBOM requirements with BSI TR-03183-2 technical specifications. Covers format requirements, data fields, dependency depth, and compliance checklist."
section: compliance
---

Expand All @@ -19,64 +19,195 @@ section: compliance

## Overview

The [EU Cyber Resilience Act](https://eur-lex.europa.eu/eli/reg/2024/2847/oj) (Regulation EU 2024/2847) is European law mandating cybersecurity requirements for products with digital elements. Unlike NTIA/CISA guidance, the CRA is **binding law** in the EU.
The [EU Cyber Resilience Act (CRA)](https://eur-lex.europa.eu/eli/reg/2024/2847/oj) (Regulation EU 2024/2847) mandates cybersecurity requirements for products with digital elements, including an SBOM requirement. Unlike US guidance documents, the CRA is **binding law** in the EU.

While the CRA does not enumerate specific SBOM fields (author, timestamp, supplier name, etc.), it **does explicitly require an SBOM** with specific format and scope requirements.
This page covers:

For a deeper dive into CRA compliance, see our post [CRA Explained: What the Cyber Resilience Act Means for Device Manufacturers]({{ site.url }}/blog/cra-explained-cyber-resilience-act-for-device-manufacturers/).
- **CRA legal baseline** - What the regulation text requires
- **BSI TR-03183-2** - Germany's Federal Office for Information Security (BSI) provides a [Technical Guideline](https://bsi.bund.de/dok/TR-03183-en) specifying concrete SBOM format and content requirements as a detailed interpretation of CRA obligations

## What the CRA Requires
> **Terminology note:** In BSI TR-03183-2, RFC 2119 keywords (MUST, SHALL, SHOULD, etc.) are normative **only when written in ALL CAPS**. (BSI TR-03183-2, Section 2)

**Annex I, Part II(1)** mandates that manufacturers must "identify and document vulnerabilities and components contained in products with digital elements, **including by drawing up a software bill of materials** in a commonly used and machine-readable format covering **at least the top-level dependencies** of the product."
---

## CRA Legal Baseline

### SBOM Requirement

Annex I, Part II(1) requires manufacturers to "identify and document vulnerabilities and components contained in products with digital elements, **including by drawing up a software bill of materials** in a commonly used and machine-readable format covering **at least the top-level dependencies** of the product."

| CRA Requirement | Description | Status |
| ----------------------- | ------------------------------------------------------- | -------- |
| Machine-readable SBOM | SBOM must be in a machine-readable format | Required |
| Commonly used format | Must use a commonly used format (e.g., CycloneDX, SPDX) | Required |
| Top-level dependencies | Must include at least top-level (direct) dependencies | Required |
| Component documentation | SBOM must reflect components contained in the product | Required |
| CRA Requirement | Description | Reference |
| ---------------------- | ------------------------------------------------------- | ------------------- |
| Machine-readable SBOM | SBOM must be in a machine-readable format | Annex I, Part II(1) |
| Commonly used format | Must use a commonly used format (e.g., CycloneDX, SPDX) | Annex I, Part II(1) |
| Top-level dependencies | Must include at least top-level (direct) dependencies | Annex I, Part II(1) |

## Technical Documentation and Authority Access
### Authority Access

The CRA requires drawing up an SBOM (Annex I, Part II(1)). Authorities can request the information and documentation needed to demonstrate conformity upon a reasoned request; in practice this includes the SBOM.
The CRA requires the SBOM as part of technical documentation. Market surveillance authorities may request this documentation upon a reasoned request to assess conformity.

| CRA Requirement | Description | Status |
| ---------------- | ---------------------------------------------------------------------------------- | ------------------------------ |
| SBOM production | Required as part of vulnerability handling (Annex I, Part II(1)) | Required |
| Authority access | Producible to market surveillance authorities upon reasoned request for conformity | Required upon reasoned request |
| Requirement | Description | Reference |
| ---------------- | ----------------------------------------------------------------- | ------------------- |
| SBOM production | Required as part of vulnerability handling | Annex I, Part II(1) |
| Authority access | Producible to market surveillance authorities on reasoned request | Article 52 |

## User Disclosure (Optional)
### User Disclosure (Optional)

**Annex II, Part I, point 9** states: "If the manufacturer decides to make available the software bill of materials to the user, [provide] information on where the software bill of materials can be accessed."
Annex II, Part I, point 9: "If the manufacturer decides to make available the software bill of materials to the user, [provide] information on where the software bill of materials can be accessed."

| CRA Requirement | Description | Status |
| Requirement | Description | Status |
| -------------------------- | ----------------------------------------------------------- | ------------------- |
| User delivery | Providing SBOM to end users | Optional |
| Access location disclosure | If SBOM is shared with users, must state where to access it | Required if sharing |

## Future Specifications
### Future Specifications

The CRA empowers the European Commission to "specify the format and elements of the software bill of materials" via implementing acts (Annex I, Part II(1)).

---

## BSI TR-03183-2: Concrete SBOM Requirements

[BSI TR-03183-2](https://bsi.bund.de/dok/TR-03183-en) (v2.1.0, August 2025) from Germany's Federal Office for Information Security provides detailed technical specifications for CRA-compliant SBOMs. Key requirements follow.

> **Note on interpretations:** BSI TR-03183-2 represents the **first published technical interpretation** of CRA SBOM requirements by an EU member state authority. Other EU countries may publish their own interpretations, which could differ in specific requirements. As additional national interpretations emerge, we will update this page to reflect the evolving compliance landscape.

### Compliance Versioning

To be compliant with the Technical Guideline, the **most recent version MUST be used**. The immediately preceding version MAY be used for up to **six months** after a new version is issued. (Section 7)

### Required Formats

SBOMs MUST be in JSON or XML format and follow one of these specifications:

| Format | Minimum Version | Reference |
| --------- | --------------- | --------- |
| CycloneDX | 1.6 or higher | Section 4 |
| SPDX | 3.0.1 or higher | Section 4 |

Only officially released versions are compliant. (Section 4)

### Scope and Dependency Depth

BSI requires a **"delivery item SBOM"** - recursive dependency resolution MUST be performed on each path downward at least up to and including the **first component outside the scope of delivery**. That first external component must at least be **identified** (creator, name, version, other unique identifiers). (Section 5.1)

"Scope of delivery" means all software parts delivered with the product; parts acquired separately are not included. (Section 8.1.11)

### Required Data Fields: SBOM Level

Each SBOM MUST contain (Table 2, Section 5.2.1):

| Data Field | Description |
| --------------- | --------------------------------------------------------------------------- |
| Creator of SBOM | Email address of the SBOM creator; if unavailable, a URL (homepage/project) |
| Timestamp | Date and time of SBOM compilation (UTC recommended) |

### Required Data Fields: Each Component

For each component, the following MUST be provided (Table 3, Section 5.2.2):

| Data Field | Description |
| ---------------------------- | -------------------------------------------------------------------------------------------- |
| Component creator | Email address or URL of the entity that created/maintains the component |
| Component name | Name assigned by creator; if none, the actual filename |
| Component version | Version identifier (SemVer/CalVer recommended); if none, file modification date per RFC 3339 |
| Filename | Actual filename of the component (not file system path) |
| Dependencies | Enumeration of direct dependencies; **completeness MUST be clearly indicated** |
| Distribution licences | SPDX licence identifier/expression for licences under which the component can be used |
| Hash of deployable component | SHA-512 checksum of the deployed/deployable component |
| Executable property | "executable" or "non-executable" |
| Archive property | "archive" or "no archive" |
| Structured property | "structured" or "unstructured" (if component has both, use "structured") |

### Additional Data Fields (Conditional)

The CRA explicitly empowers the European Commission to "specify the format and elements of the software bill of materials" via implementing acts. This means specific field-level requirements (similar to NTIA/CISA minimum elements) may be added in the future through delegated legislation.
These MUST be provided **if they exist** and fit the SBOM format (Tables 4-5, Sections 5.2.3-5.2.4):

## Key Takeaway
**SBOM level:**

The CRA requires an SBOM covering at least top-level dependencies in a machine-readable, commonly used format. Organizations should align with [NTIA]({{ site.url }}/compliance/ntia-minimum-elements/)/[CISA]({{ site.url }}/compliance/cisa-minimum-elements/) minimum elements to ensure their SBOMs satisfy both US and EU expectations.
| Data Field | Description |
| ---------- | ---------------- |
| SBOM-URI | URI of this SBOM |

**Component level:**

| Data Field | Description |
| ----------------- | ----------------------------------------------------------- |
| Source code URI | URI of the source code (repository URL or specific version) |
| Deployable URI | URI pointing directly to the downloadable form |
| Other unique IDs | CPE, Package URL (purl), SWID, etc. |
| Original licences | Licence(s) assigned by the component creator |

### Optional Data Fields

May be included if they exist (Table 6, Section 5.2.5):

| Data Field | Description |
| ----------------- | ------------------------------------------------------- |
| Effective licence | Licence under which the SBOM creator uses the component |
| Source code hash | Checksum of source code (algorithm TBD by BSI) |
| security.txt URL | URL of the component creator's security.txt (RFC 9116) |

### Licence Requirements

Licences MUST be referenced by **SPDX licence identifier or expression**. Licence text MUST NOT be used as a substitute for an identifier. (Section 6.1)

If no SPDX identifier exists, consult the [Scancode LicenseDB](https://scancode-licensedb.aboutcode.org/) using prefix `LicenseRef-scancode-[...]`. For truly unknown licences, use `LicenseRef-<entity>-[...]`. (Section 6.1)

### Vulnerability Information

**SBOMs MUST NOT contain vulnerability information.** SBOM data is static; vulnerability information is dynamic. Use **CSAF** or **VEX** for vulnerability communication instead. (Section 3.1, 8.1.14)

### One SBOM Per Version

A **separate SBOM MUST be generated for each software version**. If any component changes, a new software version MUST be assigned. (Section 3.1)

### BOM References

SBOMs of used components MAY be referenced instead of merged, if they are TR-03183-2 compliant. The SBOM provider is responsible for availability of referenced SBOMs. When referencing, the referencing SBOM MUST extract and include creator, name, and version from the referenced BOM. (Section 3.2.5, 5.1)

---

## Practical Compliance Checklist

1. **Generate an SBOM** for each software version as required by CRA Annex I, Part II(1)
2. **Use CycloneDX 1.6+ or SPDX 3.0.1+** in JSON or XML format
3. **Cover the scope of delivery** plus recursive dependencies to the first external component (at minimum, identify that component)
4. **Indicate completeness** of dependency enumeration for each component
5. **Include all required component fields**: creator, name, version, filename, dependencies, distribution licences, SHA-512 hash, executable/archive/structured properties
6. **Use SPDX licence identifiers** - never use licence text as a substitute
7. **Do not embed vulnerability information** - use CSAF/VEX instead
8. **Digitally sign** the SBOM so recipients can verify authenticity (recommended)
9. **Be prepared to provide** the SBOM to market surveillance authorities upon request
10. **If sharing with users**, document where the SBOM can be accessed

---

## Schema Mappings

For CycloneDX and SPDX field mappings, see our [Schema Crosswalk]({{ site.url }}/compliance/schema-crosswalk/).
BSI TR-03183-2 Section 8.2 provides detailed JSON mappings for CycloneDX 1.6 and SPDX 3.0.1.

For general CycloneDX and SPDX field mappings, see our [Schema Crosswalk]({{ site.url }}/compliance/schema-crosswalk/).

BSI maintains a CycloneDX property taxonomy for TR-03183-2 specific fields: [github.com/BSI-Bund/tr-03183-cyclonedx-property-taxonomy](https://github.com/BSI-Bund/tr-03183-cyclonedx-property-taxonomy)

---

## Related Frameworks

- [EU NIS2 Directive]({{ site.url }}/compliance/eu-nis2/) - EU cybersecurity law for critical entities
- [NTIA Minimum Elements]({{ site.url }}/compliance/ntia-minimum-elements/) - Recommended baseline for SBOM content
- [NTIA Minimum Elements]({{ site.url }}/compliance/ntia-minimum-elements/) - US baseline for SBOM content
- [CISA Framing Document]({{ site.url }}/compliance/cisa-framing/) - CISA guidance on SBOM attributes

---

## Official Source
## Official Sources

- [EU Cyber Resilience Act (Regulation 2024/2847)](https://eur-lex.europa.eu/eli/reg/2024/2847/oj)
- [BSI TR-03183-2: Software Bill of Materials (SBOM)](https://bsi.bund.de/dok/TR-03183-en) - v2.1.0, August 2025

---

**Disclaimer:** This page represents our interpretation of the referenced frameworks and standards. While we strive for accuracy, we may have made errors or omissions. This content is provided for informational purposes only and does not constitute legal advice. For compliance decisions, consult the official source documents and seek qualified legal counsel.
**Disclaimer:** This page represents our interpretation of the EU Cyber Resilience Act and BSI TR-03183-2. While we strive for accuracy, we may have made errors or omissions. This content is provided for informational purposes only and does not constitute legal advice. For compliance decisions, consult the official source documents and seek qualified legal counsel.

[← Back to Compliance Overview]({{ site.url }}/compliance/)
25 changes: 25 additions & 0 deletions compliance/schema-crosswalk.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -17,6 +17,8 @@ This page maps SBOM properties to their specific field paths in CycloneDX, SPDX

**Note:** The CISA Framing document's published crosswalk table references CycloneDX v1.6. This page uses CycloneDX 1.7 schema paths, which are largely compatible but include some updates (e.g., tools object structure).

**BSI TR-03183-2 Note:** For EU CRA compliance via BSI TR-03183-2, SBOMs MUST use **CycloneDX 1.6+** or **SPDX 3.0.1+** in JSON or XML format. See the [EU CRA page]({{ site.url }}/compliance/eu-cra/) for full requirements.

---

## Document-Level Metadata
Expand Down Expand Up @@ -77,8 +79,31 @@ This page maps SBOM properties to their specific field paths in CycloneDX, SPDX

---

## BSI TR-03183-2 Component Properties

BSI TR-03183-2 requires additional component properties not covered by standard SBOM fields. These use the [BSI CycloneDX property taxonomy](https://github.com/BSI-Bund/tr-03183-cyclonedx-property-taxonomy) for CycloneDX and `software_additionalPurpose` for SPDX.

| Property | CycloneDX 1.6+ | SPDX 3.0.1 |
| ----------------------- | ---------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- |
| Filename | `components[].properties[name="bsi:component:filename"]` | `software_File.name` via `hasDistributionArtifact` relationship |
| Executable property | `components[].properties[name="bsi:component:executable"]` | Add `executable` to `software_additionalPurpose` list |
| Archive property | `components[].properties[name="bsi:component:archive"]` | Add `archive` to `software_additionalPurpose` list |
| Structured property | `components[].properties[name="bsi:component:structured"]` | Add `container` (structured) or `firmware` (unstructured) to `software_additionalPurpose` |
| Effective licence | `components[].properties[name="bsi:component:effectiveLicense"]` | Custom relationship with `relationshipType: other` and `comment: hasEffectiveLicense` |
| Hash (deployable) | `components[].externalReferences[type="distribution"].hashes[alg="SHA-512"]` | `software_File.verifiedUsing` via `hasDistributionArtifact` relationship |
| Dependency completeness | `compositions[].aggregate` (complete/incomplete/unknown) | `Relationship.completeness` (complete/incomplete/noAssertion) |

**Notes:**

- BSI requires **SHA-512** specifically for the deployable component hash
- The BSI property taxonomy uses the `bsi:` namespace prefix for CycloneDX properties
- For detailed JSON examples, see [BSI TR-03183-2 Section 8.2](https://bsi.bund.de/dok/TR-03183-en)

---

## Related Pages

- [EU CRA Requirements]({{ site.url }}/compliance/eu-cra/) - CRA SBOM requirements with BSI TR-03183-2 specifications
- [CLE: Common Lifecycle Enumeration]({{ site.url }}/compliance/cle/) - Standard for machine-readable lifecycle events
- [CISA Framing Document]({{ site.url }}/compliance/cisa-framing/) - Authoritative source for baseline attribute definitions
- [NTIA Minimum Elements]({{ site.url }}/compliance/ntia-minimum-elements/) - US baseline for SBOM data fields
Expand Down