EU CRA incident reporting began 11 September 2026; compliance work starts beyond the SBOM

A reporting clock with no transition period

According to a dev.to post by ROSH Company Labs, the reporting duties in the EU Cyber Resilience Act (Regulation (EU) 2024/2847) came into force on 11 September 2026. Anyone putting software on the EU market is now subject to Article 14: an actively exploited vulnerability, or a severe incident, must reach a national CSIRT and ENISA through a single reporting platform. The schedule the post describes is an early warning within 24 hours, a fuller notification within 72 hours, and a final report afterwards. The author stresses that these duties carry no transition period and apply whether or not a product was released before the date.

The remainder of the regime — essential requirements, the SBOM, technical documentation, the EU Declaration of Conformity and CE marking — applies from 11 December 2027. Fourteen months sounds like room to move, the post argues, but it is tight for work most teams have not begun. Even so, the piece teams instinctively start with, the SBOM, is the one part that is already effectively solved.

Generating the SBOM is the commoditised step

Annex I, Part II(1) asks for a machine-readable bill of materials covering at least the top-level dependencies, in a commonly used format, and the regulation does not name a preferred one. As the post points out, npm sbom, cyclonedx-npm and syft each emit a CycloneDX or SPDX document in a single command. Producing the file costs nothing, and the market for generators is already crowded.

What the regulation actually wants from the file

The central claim of the post is that the CRA does not simply ask for a document — it asks you to put it to work, and that is where off-the-shelf tooling stops. Read in order, Annex I makes the SBOM an input to several obligations that no generator can discharge for you:

• A justification of depth. "At least top-level" is a floor; scanning deeper is a risk-based choice you have to be able to explain.
• A judgement that the release carries no known exploitable vulnerabilities. A scanner can report "no known vulnerabilities"; the exploitable versus not-exploitable distinction is a reachability call a human records, typically as a VEX statement.
• A vulnerability-handling process, including a coordinated-disclosure policy and a single point of contact (Annex I Part II, plus Annex II's contact requirement).
• A draft EU Declaration of Conformity. For a "default" product this is Module A internal self-assessment, but it still has to exist and cite the requirements met.
• A wired-up Article 14 workflow, decided before it is needed: who files the 24-hour early warning, who files at 72 hours, who writes the final report.

A CLI for the surrounding paperwork

Alongside the analysis, ROSH Company Labs released cra-kit, a zero-dependency Node CLI invoked as npx @roshcompanylabs/cra-kit against a repository. From package.json and the lockfile it produces a CycloneDX 1.6 SBOM plus evidence the free generators leave out: the depth justification, an OSV vulnerability match that fails closed — an unreachable lookup is reported as incomplete rather than silently returning "nothing found" — a CVD policy with a point of contact and an Article 14 step list, a draft Declaration of Conformity, and an Annex I readiness checklist. The tool currently reads npm lockfiles only, its drafts contain blanks the user must own, and the author is explicit that it maps documents to articles without making anyone compliant. The CVD template is not hypothetical: the post says the author ran the process on their own library this month, found a real bypass, shipped the fix, published the advisory and requested a CVE.

Limits worth knowing

Two caveats the author flags. First, no harmonised standard for the CRA has been cited in the Official Journal yet — the EN 40000 series is still in development — so nobody can currently claim a standards-based presumption of conformity. Second, the SBOM is not a public artefact: it sits in the technical documentation, retained and shown to market-surveillance authorities on request. The post also notes it is not legal advice, and that the governing text is the regulation as published on EUR-Lex.

Why it matters

Article 14 turns vulnerability disclosure for the EU market into a timed regulatory process rather than a community norm, and it reaches vendors wherever they are based. Teams that equate readiness with running an SBOM generator will meet the real obligations — reachability judgements, a disclosure policy, a named contact, an assigned reporting chain — at the worst moment: with an exploit in the wild and 24 hours already counting down. With the full regime arriving in December 2027, the preparation that matters is the half no tool prints.