The reporting clock under the EU Cyber Resilience Act (Regulation (EU) 2024/2847) started on 11 September 2026. If you put software on the EU market you are already inside Article 14: an actively exploited vulnerability, or a severe incident, has to reach a national CSIRT and ENISA through a single reporting platform on a 24-hour / 72-hour / final-report cadence — no transition period, and whether or not the product predates the date. The rest — the essential requirements, the SBOM, the technical documentation, the EU Declaration of Conformity, CE marking — applies on 11 December 2027. Fourteen months is not long for a thing most teams have not started.
The part everyone reaches for first is the SBOM, and it is the part that is already solved. Annex I, Part II(1) wants a machine-readable bill of materials covering at least the top-level dependencies, in a commonly used format. npm sbom, cyclonedx-npm, syft each produce one in a single command, in CycloneDX or SPDX, and the regulation names no format to prefer. Generating the file is free and commoditised. It is the easy half, and it is the half the tooling market has saturated.
The CRA does not ask for a file. It asks you to use one — and that is the half nobody hands you.
Reading the same Annex, in order, the SBOM is an input to things that have no --output flag:
- A depth justification. "At least top-level" is a floor, not a decision. Going deeper is a risk-based choice you have to be able to state — why your boundary is where it is.
- No known exploitable vulnerabilities at release. Note the word. A scanner tells you "no known vulnerabilities"; the Annex wants "no known exploitable ones," and the gap between the two is a reachability judgement you make and record — a VEX statement — not a number a tool prints.
- A vulnerability-handling process with a coordinated-disclosure policy and a single point of contact (Annex I, Part II, incl. the CVD policy, and Annex II's point of contact). This is a document and a commitment, not a scan.
- A draft EU Declaration of Conformity. For a "default" product this is Module A — internal control, self-assessed — but it still has to exist and cite what it's conformant with.
- The Article 14 workflow itself, wired before you need it: who files the 24-hour early warning, who files at 72 hours, who writes the final report.
None of that comes out of an SBOM generator, because none of it is the SBOM. It is what the SBOM is for.
Two honest limits, because the moment someone sells you certainty here they are selling you something that doesn't exist yet. First: no harmonised standard for the CRA is cited in the Official Journal yet (the EN 40000 series is still in development). Until one is, there is no standards-based presumption of conformity — for anybody. What you can build toward is readiness, and anyone claiming more is ahead of the law. Second: the SBOM is not a public artifact — it lives in the technical documentation, retained and shown to market-surveillance authorities on request, not posted. And none of this is legal advice; the article and dates here are checked against secondary sources, and the text that governs you is Regulation (EU) 2024/2847 on EUR-Lex.
So I wrote the part that isn't the file. cra-kit is a zero-dependency Node CLI — one command, no install: npx @roshcompanylabs/cra-kit ./your-repo. From package.json + the lockfile it produces a CycloneDX 1.6 SBOM and the evidence the free tools don't: the depth justification, an OSV vulnerability match that fails closed (if the lookup is unreachable it tells you the result is incomplete rather than quietly reporting "nothing found"), a vulnerability-handling + CVD policy with the point-of-contact and the Article 14 step-list, a draft Declaration of Conformity, and an Annex I readiness checklist. It draws the line the compliance checklists blur — "no known vulnerabilities" is what a scanner can say; "no known exploitable vulnerabilities" is a judgement it marks as yours to make.
It is honest about what it is: the drafts have blanks you fill and own, it reads npm lockfiles only for now, and it confers no presumption of conformity — nothing can, yet. It maps documents to articles; it does not make you compliant.
I didn't write the vulnerability-handling template from the outside. I ran the process on my own library this month — found a real bypass, shipped the fix, published the advisory and requested the CVE — so the policy it drafts is a worked example of Annex I, Part II in practice, not a guess at one.
The reporting clock is already running. The SBOM was never the hard part; using it is. That's the half worth building.
— ROSH Company Labs
Top comments (0)