Cyber Resilience Act: SBOM and vulnerability reporting incoming (also for Open Source)

The Cyber Resilience Act (Reg. EU 2024/2847) is moving forward: authorities from 11 June 2026, vulnerability reporting from September, SBOM and full obligations from December 2027. What changes, also for Open Source.

ComplianceCybersecurityOpen SourceGovernance CybersecurityComplianceOpen SourceSBOMCRA

Where we are in the timeline

The Cyber Resilience Act is Regulation (EU) 2024/2847, in force since December 2024. It does not all apply at once: the regulation phases in obligations over roughly three years, and it helps to pin down the three key moments, because they are often conflated.

The first operational milestone is about to arrive. From 11 June 2026 Chapter IV applies, covering conformity assessment bodies and notifying authorities: by this date Member States designate national authorities and notified bodies. This is the first concrete milestone, now imminent, and it puts in place the institutional scaffolding on which everything else rests.

The second milestone lands in September, the third at the end of 2027. Keeping the two apart is the central point of this article.

Reporting starts in September

From 11 September 2026 the reporting obligations under Art. 14 become applicable: manufacturers must report actively exploited vulnerabilities and severe incidents. The obligation also covers products already placed on the market, not only new ones.

The deadlines are tight. For an exploited vulnerability: early warning within 24 hours, notification within 72 hours, final report within 14 days of a corrective measure becoming available. For severe incidents the final report is due within one month.

Notifications will go through the CRA Single Reporting Platform operated by ENISA, which will be operational by September 2026. The platform is not active yet: manufacturers mapping their products today should prepare for a channel that will come online alongside the obligation itself. Teams that already set up their NIS2 flows start ahead — it is the same theme we discussed around NIS2 and SMEs.

SBOM: the full obligation is end-2027

The bulk of the regulation — essential requirements, manufacturer obligations and technical documentation — applies from 11 December 2027. This is where the SBOM enters the picture.

Annex I, Part II, point 1 requires documenting the product’s components in a software bill of materials in a commonly used, machine-readable format, covering at least the top-level dependencies. The CRA does not mandate a specific format, and as of today there are no final harmonised EN standards nor delegated acts on the format: in practice teams adopt CycloneDX or SPDX. For detailed specifications, BSI TR-03183-2 provides technical guidance for CRA-compliant SBOMs.

A frequently misread point: the SBOM goes into the technical documentation and is provided to market surveillance authorities on a reasoned request, with no obligation to make it public. It is not a market disclosure, it is a compliance artefact.

The open source steward

The CRA introduces a new figure in Art. 24: the open source steward. These are legal persons that provide ongoing support to free/open-source software intended for commercial activities — entities distinct from the manufacturer. Individual volunteer developers remain out of scope.

The regime is light-touch: a documented cybersecurity policy, vulnerability handling and disclosure, cooperation with authorities. Stewards are not subject to administrative fines. It is an acknowledgement that the software supply chain rests on projects maintained by entities that do not sell the finished product, and that they should be made accountable without being treated as manufacturers. The theme is directly ours, consistent with our work on open source.

What this means in practice

For anyone placing products with digital components on the European market, the sequence is clear: reporting first, then SBOM. From September you need a process to recognise and notify exploited vulnerabilities and incidents within windows measured in hours; from end-2027 you need a machine-readable SBOM in the technical documentation, kept up to date.

The two fronts are operationally linked. An accurate inventory of dependencies — the SBOM — is also what makes it possible to respond within 24 hours when one of those dependencies is exploited. Building it during 2026, ahead of the deadline, means reaching 2027 with the work already done.

This is the axis our products work on: CyberScan for vulnerability management and SBOM generation, and DataGovern for the governance of compliance documentation. The deadline is regulatory; the preparation is a matter of timing.

Links: Regulation (EU) 2024/2847 — EUR-Lex · European Commission — CRA reporting obligations · European Commission — CRA and open source

Need support? Under attack? Service Status
Need support? Under attack? Service Status