ComplianceCyber Resilience Act: what you must do if you make software.
Regulation (EU) 2024/2847 applies to anyone placing a product with digital elements on the European market. It is a regulation, not a directive: it applies directly, and the first obligation, reporting exploited vulnerabilities, has applied since 11 September 2026. This page sets out what it means in practice.
Who it applies to
The regulation says «products with digital elements», which is broader than it sounds. If you sell in Europe, it most likely covers you.
- Software sold as a product, licensed or subscribed, whether it runs in the cloud or on customer premises.
- Firmware and embedded software: if the product has a microcontroller and a connection, it is in scope.
- Software components sold to other manufacturers who integrate them.
- Importers and distributors carry their own obligations, not just the original manufacturer.
- Sectors already covered by their own regulations — medical devices, automotive, aviation — stay outside.
The dates that matter
Two distinct deadlines. The first has already passed: the obligation it brings applies from then on.
11 September 2026Reporting obligations
From this date actively exploited vulnerabilities and severe incidents must be reported: early warning within 24 hours, notification within 72 hours, final report within 14 days of the fix (one month for incidents). It also applies to products already on the market.
11 December 2027Full application
From here you cannot place on the market a product that fails the essential requirements or lacks technical documentation and a declaration of conformity.
What you must actually produce
The regulation does not ask for good intentions: it asks for documents and processes someone can come and read.
- Cybersecurity risk assessment
- Documented, product-specific, and maintained across the support period. It belongs in the technical documentation.
- Software bill of materials (SBOM)
- Your dependencies, at least top level, in machine-readable form. It is also how you know whether a new vulnerability concerns you.
- Vulnerability handling
- A process that finds, triages and fixes without undue delay, and a channel through which anyone can report to you.
- Security updates
- Free and timely for the whole declared support period, which must be declared and cannot be shorter than the product’s expected life.
- Technical documentation
- The file that demonstrates conformity with the essential requirements, kept current and retained for ten years.
- EU declaration of conformity and CE marking
- Yes, CE marking applies to software too. This is the step that surprises almost everyone.
- Reporting in three phases: 24 hours, 72 hours, final report
- For an actively exploited vulnerability or severe incident: early warning within 24 hours of becoming aware, notification within 72 hours, final report within 14 days of the fix (vulnerabilities) or one month of the notification (incidents). Sent to the designated CSIRT and ENISA through the single reporting platform. In force since 11 September 2026.
Four beliefs that cost money
We meet them regularly, and they all come from a partial reading of the regulation.
«It is about hardware, we do software»
The scope is «products with digital elements»: software sold on its own is explicitly included.
«The open source we use is not our problem»
Whoever places the product on the market answers for the whole product, dependencies included. That is why an SBOM is not paperwork.
«We will deal with it in 2027»
Reporting has applied since 11 September 2026 and presumes a working vulnerability process already in place. It is not improvised on the day of the incident.
«We will write the file at the end»
The file collects evidence produced during development. Reconstructing it afterwards costs far more, and sometimes is no longer possible.
Where to start
If you have done nothing yet, this order reduces risk fastest.
- Establish which of your products are in scope, and who the manufacturer is for each under the regulation.
- Generate the SBOM for those products. Without it, every later step is guesswork.
- Open a public vulnerability reporting channel and write the internal procedure behind it.
- Declare the support period per product and check you can honour it.
- Start collecting evidence in technical-documentation format from the next release onwards.
If you want to know where you stand against these deadlines, let us look at a real product together.
Book an assessmentPage updated 2 November 2026. Always verify regulation dates against the official source.