CRA: what you will be asked to show
You know how to produce a component inventory. What remains is knowing what an auditor will ask you to prove, and where that proof is produced in your chain. The checklist, obligation by obligation.
You know how to produce a component inventory. What you don’t know is what you will be asked to show on the day a vulnerability in your product is actively exploited. This page answers that question, obligation by obligation.
This is not a gap on your side. The European Commission’s guidelines run to eighty-four pages. They set out the deadlines, the moment those deadlines start running, and how third-party components are treated. And the word SBOM does not appear in them once: not software bill of materials, not any inventory format, not even the word inventory itself. The text says when, who and what. It says nothing about how.
➡️ Get a first read → Free, one hour. We run this checklist against your chain and you leave with the list of what is missing.
The checklist
References point to the paragraphs of the annex to the guidelines, Commission communication C(2026) 5252 of 27 July 2026. That text is an interpretation, not legally binding (§8).
| What you are asked | What you must show | Where it is produced |
|---|---|---|
| To have reported an actively exploited vulnerability: early warning within 24 h, notification within 72 h, final report no later than 14 days after a corrective or mitigating measure is available (§215) | When you became aware of it, and the record of the assessment that gave you a reasonable degree of certainty (§213) | An incident register connected to vulnerability monitoring, with versioned notification templates |
| To know whether the vulnerable component is actually reachable in your product (§218) | Your components, shipped version by shipped version, and evidence that the vulnerable code is or is not reached | The inventory produced by the build, never typed by hand, with a reachability analysis |
| To track published vulnerabilities (§233-235) | That you monitor the European vulnerability database, established by Article 12(2) of Directive (EU) 2022/2555, as well as the other public reference databases, and that you investigated whether they apply to your product | Monitoring wired into continuous integration, keeping a record of every decision |
| To report the vulnerability to the component’s maintainer (§223-227) | The report made for the version you integrate, and the fix shared in machine-readable form | A pipeline step that opens the advisory upstream and keeps the link |
| To test and review regularly (§238-240) | Not a fixed cadence, but that you review your test suite when the threat changes, then run it | A review log for the test suite, and execution in continuous integration, regression included |
| To classify a change as substantial or not (§103-109) | A risk assessment that anticipates your roadmap, and a recorded decision for each change | The risk assessment versioned with the code, reviewed whenever the scope changes |
Two counter-intuitive points
Products you have already shipped count. The reporting obligation has applied since 11 September 2026 to every product in scope, including those you placed on the market four years ago, and well before the December 2027 deadline (§210).
A security update is generally not a substantial modification. Even when it is technically heavy, as long as it adds no risk and does not change the product’s intended purpose (§108). The exception is explicit: it becomes one if it significantly changes the product’s boundaries or dependencies in a way your risk assessment did not foresee, for example by altering data flows or adding externally reachable interfaces (§109). So the line is not drawn by the technical size of the change, but by what it exposes and by what your risk assessment had anticipated.
What you are missing is not a tool
Syft and Trivy generate the inventory for free. What blocks teams is being able to state that this inventory matches what actually runs in the shipped product, and to prove it. An inventory typed by hand or rebuilt after the fact is hard to defend: nothing in the regulation forbids it, but nothing proves it describes the shipped product either.
What we put in place is compliance documentation produced by the build chain itself. An inventory attested by a reproducible build, runtime verification on a hardware test bench, and artefacts archived with every release. The inventory, the risk assessment and the scanners become components of that chain, not the deliverable. It is the same craft as software industrialisation, applied to evidence.
What it looks like on the day it happens
Take a case. A vulnerability is published in a cryptography library you embed. Here is what the chain has already done for you, and what is left for you to decide.
- The evidence exists before the alert. Your firmware 2.4.1 came out of build 1847, which produced the inventory of its components and signed it. Nothing to rebuild in a hurry.
- The match is automatic. Monitoring links the published vulnerability to that component, in that exact version, and tells you which of your shipped versions contain it.
- Reachability settles it. The analysis tells you whether the vulnerable code is actually called in your product. If it is not, you do not have to report, but you must be able to demonstrate it (§218).
- The decision is dated and justified. It establishes the moment you reached a reasonable degree of certainty, and therefore the starting point of your 24 hours (§213).
- The fix is validated on real hardware. The regression test runs on a bench, not only in simulation.
- The file closes itself. Inventory, match, analysis, decision, test result: the artefacts of build 1848 are your evidence, archived with no extra work.
Without that chain, each of these six steps is manual work, to be redone for every alert, inside the 24-hour window.
Getting started
Get a first read → One hour, free, no strings attached.
We go through this checklist against your chain, line by line: probable scope, probable class, next steps. You leave with the list of what is missing and the order in which to tackle it, whether or not you hand us what comes next.
Not sure yet whether your product is in scope? Three minutes are enough to find out, no sign-up and no email address.
For the overall framework, the tiers and the budget, see our CRA offer. If you manufacture in Switzerland, what the CRA means for a Swiss company.