What the CRA means if nobody's checked your SBOM.
The Cyber Resilience Act moves security from a document into the product. Software and connectable hardware sold on the EU market must be secure by design and by default, ship with a software bill of materials, and keep vulnerabilities handled — and, when actively exploited, reported to ENISA within 24 hours — across the product's lifecycle. Products bear the CE marking to show conformity, and national market-surveillance authorities enforce the rules.
For a manufacturer this is an operating problem, not a documentation problem. The evidence the CRA expects is produced continuously while the product lives — what is in the build, who reviewed the vulnerability feed, when ENISA was told. Paper assembled for an audit ages exactly as fast as the product it describes.
Who it applies to
The CRA covers products with digital elements sold on the EU market. The obligations sit on manufacturers, and they must be met at every stage of the value chain. Products of particular relevance for cybersecurity can additionally require third-party assessment by a notified body before they are sold. The Commission is explicit that the Act complements the NIS2 Directive — one estate now answers both.
The clock
The date that surprises teams is the middle one: vulnerability reporting applies from September 2026, more than a year before the main obligations do.
| When | What happens |
|---|---|
| 10 December 2024 | Regulation entered into force |
| 27 July 2026 | Commission published practical guidance for manufacturers |
| 11 September 2026 | Reporting obligations to ENISA apply |
| 11 December 2027 | Main obligations apply |
What it asks, in operating terms
Read as an operating requirement rather than a legal text, the CRA reduces to a handful of standing asks — each answerable with evidence on demand, not reconstructed when someone asks for it.
| What the CRA asks | Where it is answered |
|---|---|
| Security by design and by default, evidenced | Control library · product-security controls, continuously monitored |
| Maintain a software bill of materials | SBOM register · components tracked to evidence |
| Report actively exploited vulnerabilities to ENISA within 24 hours | Reporting workflow · clocked, named owner, sealed record |
| Handle vulnerabilities across the product lifecycle | Vulnerability handling · detection through verified closure |
What you'd actually look at
In the dashboard, every figure opens on click to the control, the evidence and the person behind it. This excerpt is what a readiness file is made of:
- SBOM coverage
- 31/31 components
- Vulns handled
- 14 · 2 reported to ENISA · all clocks met
- Support commitments
- documented · per product line
- Open exceptions
- 1 · closes Q4
- Evidence
- sealed · sha256:a3f2…9e41
Where teams usually start
With a demo walked through by TruSecure — the CRA control set, a sample reporting drill against the 24-hour clock, the export a notified body or market-surveillance contact will ask for. A Resilience Sprint then produces the first baseline; the subscription keeps it current. Packaging is scoped in the conversation, not a price list.
TruSecure helps operationalize requirements and prepare evidence. Legal interpretation should be validated by qualified counsel.
The short answer
The Cyber Resilience Act requires manufacturers of products with digital elements sold in the EU to build in security by design and by default, maintain a software bill of materials, and report actively exploited vulnerabilities to ENISA within 24 hours.