.svg)
Investors InquiryRequest a Demo
Download Product Brochure
34
Download Cybeats Marketplace Brochure
The CRA itself names no format. Annex I Part II point (1) requires an SBOM in a commonly used, machine-readable format covering at least the top-level dependencies of the product, and Article 13(24) lets the Commission specify the format and elements later through implementing acts. Until it does, Germany's BSI TR-03183-2 is the most concrete published baseline in the EU. Version 2.1.0 accepts CycloneDX 1.6 or higher and SPDX 3.0.1 or higher, serialised as JSON or XML, and only in officially released versions of those specifications.
One rule catches people out: an SBOM must not carry vulnerability information. BSI TR-03183-2 keeps the two apart, because an SBOM describes a fixed software composition while vulnerability status changes constantly. Vulnerability data belongs in CSAF or VEX documents that reference the SBOM. For the same reason, a separate SBOM is required for every version of a product.
| Data field | Status | What it must carry |
|---|---|---|
| Creator of the SBOM | Required, SBOM level | Email address of the entity that created the SBOM, or a URL such as the creator's home page if no email address exists. |
| Timestamp | Required, SBOM level | Date and time the SBOM data was compiled. BSI recommends UTC, or Zulu time. |
| SBOM-URI | Additional, SBOM level | The URI of the SBOM itself. |
| Component creator | Required | Email address of the entity that created and, where applicable, still maintains the component, or a URL if no email address exists. |
| Component name | Required | The name the component creator assigned. If no name was assigned, the actual filename. |
| Component version | Required | The creator's version identifier. Semantic or calendar versioning should be used. If no version exists, the file modification date as an RFC 3339 date-time. |
| Filename of the component | Required | The actual filename, not its file system path. |
| Dependencies on other components | Required | Every component this one directly depends on or contains. The completeness of that list must be clearly indicated. |
| Distribution licences | Required | The licence or licences under which a licensee may use the component. |
| Hash value of the deployable component | Required | A SHA-512 checksum of the component in its deployed or deployable form, as a file on storage. |
| Executable property | Required | Either executable or non-executable. |
| Archive property | Required | Either archive or no archive. |
| Structured property | Required | Either structured or unstructured. A component with both kinds of part must be recorded as structured. |
| Source code URI | Additional | The URI of the component's source code, ideally the exact version used in its repository. |
| URI of the deployable form | Additional | A URI pointing directly at the deployable, for example downloadable, form of the component. |
| Other unique identifiers | Additional | Identifiers for looking the component up elsewhere, such as Common Platform Enumeration (CPE) or Package URL (purl). |
| Original licences | Additional | The licences assigned by the component's creator, as distinct from the distribution licences. |
| Effective licence | Optional | The licence under which the creator of this SBOM actually uses the component. |
| Hash value of the source code | Optional | A checksum of the component's source code. BSI notes that no algorithm for hashing a source tree has been fixed yet. |
| URL of the security.txt | Optional | The location of the component creator's security.txt, per RFC 9116. |
Required means the field must always be present. Additional means it must be provided whenever it exists and the chosen format supports it. Optional means it may be included. Where information genuinely cannot exist, for example the filename or hash of a component that is never deployed as a separate file, BSI allows it to be omitted.
Source: BSI TR-03183-2, Cyber Resilience Requirements for Manufacturers and Products, Part 2: Software Bill of Materials, version 2.1.0, 20 August 2025.
| Step | Actively exploited vulnerability (Article 14(2)) | Severe incident (Article 14(4)) |
|---|---|---|
| Early warning | Within 24 hours of becoming aware | Within 24 hours of becoming aware |
| Notification | Within 72 hours of becoming aware. Covers the general nature of the exploit and the vulnerability, corrective or mitigating measures taken, and measures users can take. | Within 72 hours of becoming aware. Covers the nature of the incident, an initial assessment, corrective or mitigating measures taken, and measures users can take. |
| Final report | No later than 14 days after a corrective or mitigating measure is available. | Within one month of submitting the 72 hour notification. This is the deadline most summaries get wrong by copying the 14 day figure across. |
| Intermediate report | Only if the coordinating CSIRT requests one, under Article 14(6). | Only if the coordinating CSIRT requests one, under Article 14(6). |
| Telling users | Required under Article 14(8), where appropriate in a structured, machine-readable format. | Required under Article 14(8), where appropriate in a structured, machine-readable format. |
The SBOM and reporting duties are spread across the annexes and the articles, and they do not all start on the same day. This is the map.
| Provision | What it requires | Applies from |
|---|---|---|
| Article 14(1) and (2) | Report an actively exploited vulnerability: early warning within 24 hours, vulnerability notification within 72 hours, final report within 14 days of a fix being available. | 11 September 2026 |
| Article 14(3) and (4) | Report a severe incident: early warning within 24 hours, incident notification within 72 hours, final report within one month of that notification. | 11 September 2026 |
| Article 14(7) | File through the notification end-point of the CSIRT designated as coordinator in your member state of main establishment, accessible to ENISA at the same time. | 11 September 2026 |
| Article 14(8) | Inform impacted users of the vulnerability or incident and any mitigation they can apply, where appropriate in a structured, machine-readable format that is easily automatically processable. The CRA names no format. BSI TR-03183-3 points to OASIS CSAF 2.0, standardised as ISO/IEC 20153:2025. | 11 September 2026 |
| Article 16 | ENISA establishes and operates the single reporting platform. The receiving CSIRT disseminates the notification to other coordinators, and may delay that on justified cybersecurity grounds. | 11 September 2026 |
| Article 69(3) | By way of derogation from Article 69(2), the Article 14 reporting duties apply to every in-scope product placed on the market before 11 December 2027, whether or not it is ever substantially modified. | 11 September 2026 |
| Annex I, Part II, point (1) | Identify and document vulnerabilities and components, including by drawing up an SBOM in a commonly used, machine-readable format covering at least the top-level dependencies of the product. | 11 December 2027 |
| Annex VII, point 8 | Hold the SBOM as part of the technical documentation and supply it further to a reasoned request from a market surveillance authority. There is no duty to publish it. | 11 December 2027 |
| Annex II, point 9 | If you choose to make the SBOM available to users, the product information must say where they can access it. | 11 December 2027 |
| Article 13(25) | Market surveillance authorities may request SBOMs for a Union-wide software dependency assessment decided by ADCO, reported on in anonymised, aggregated form. | 11 December 2027 |
| Article 24(3) | Open source software stewards carry the Article 14(1) duty where they are involved in developing the product, and Article 14(3) and (8) where a severe incident affects the systems they provide for that development. | 11 December 2027 |
| Article 13(24) | The Commission may specify the format and elements of the SBOM by implementing act, taking European and international standards into account. No such act has been adopted. | Not yet exercised |
Article 64 sets ceilings, and each member state lays down its own rules within them. Missing the SBOM obligation sits in the highest tier, alongside the Article 14 reporting duties.
| What was breached | Maximum fine | Basis |
|---|---|---|
| The Annex I essential requirements, Article 13, or Article 14 | EUR 15 000 000, or 2,5 % of total worldwide annual turnover for the preceding financial year, whichever is higher. | Article 64(2) |
| Duties on importers, distributors, notified bodies and related obligations | EUR 10 000 000, or 2 % of total worldwide annual turnover, whichever is higher. Covers Articles 18 to 23, 28, 30(1) to (4), 31(1) to (4), 32(1) to (3), 33(5), 39, 41, 47, 49 and 53. | Article 64(3) |
| Incorrect, incomplete or misleading information given to a notified body or market surveillance authority | EUR 5 000 000, or 1 % of total worldwide annual turnover, whichever is higher. | Article 64(4) |
| A microenterprise or small enterprise that misses the 24 hour early warning | The fines in Article 64(3) to (9) do not apply to that missed deadline under Article 14(2)(a) or 14(4)(a). | Article 64(10)(a) |
| An open source software steward, for any infringement | The fines in Article 64(3) to (9) do not apply. | Article 64(10)(b) |
Member states set the actual rules under Article 64(1); the figures above are the ceilings the CRA fixes. Article 64(5) requires regard to the nature, gravity and duration of the infringement, whether fines have already been applied to the same operator for something similar, and the size and market share of the operator, with microenterprises and SMEs named specifically.
.svg)
