Cyber Resilience Act (CRA)

What is the Cyber Resilience Act?

The Cyber Resilience Act puts cybersecurity rules on products instead of on companies. Regulation (EU) 2024/2847 entered into force on 10 December 2024, and from 11 December 2027 a product with digital elements can be sold in the EU only if it meets a list of security requirements and carries a CE marking that says so. It runs on the conformity assessment and CE marking machinery Europe already uses for physical products, and that the AI Act borrows too: build against essential requirements, write the technical documentation, run a conformity assessment, sign a declaration of conformity, affix the mark. What is new is that the mark now stands for security too, and for the promise that somebody keeps fixing vulnerabilities long after the invoice was paid.

The sentence that decides whether this is your problem is the definition in Article 3. A product with digital elements is "a software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately". A pump controller is one. The app that drives it is one. A library you sell on its own is one.

What it covers, and what it leaves out

Article 2(1) covers products made available on the EU market whose intended or reasonably foreseeable use includes a direct or indirect data connection to a device or network. That is close to everything, and software counts when it is sold on its own. Article 3(22) defines making available on the market as supply in the course of a commercial activity "whether in return for payment or free of charge", so a free download from a company website is inside. The exclusions are narrow and sit where another EU law already handles the same risk: medical devices, motor vehicles, certified aviation products, marine equipment, spare parts replacing an identical component, and anything built exclusively for national security or defence.

The line most people get wrong is cloud. Software delivered purely as a service is not a product with digital elements, and the Commission scope guidance approved in July 2026 says a web application used only through a browser is generally outside. Cloud comes back through the side door as a remote data processing solution: processing at a distance, built by or under the responsibility of the same manufacturer, without which the product cannot perform one of its functions. Your device's backend is part of the product. Your accounting SaaS is not a product at all.

Who counts as the manufacturer

The manufacturer carries almost everything: the essential requirements, the risk assessment, due diligence on third-party components, the documentation, the conformity assessment, the CE marking, the support period and the reporting. Importers and distributors get checking duties instead, and both pass vulnerabilities they hear about back to the manufacturer.

Then comes the trap. Article 21 says an importer or distributor "shall be considered to be a manufacturer" and falls under Articles 13 and 14 once it places a product on the market under its own name or trademark, or substantially modifies a product already on the market. Rebadging somebody else's controller makes you the manufacturer of it. The AI Act has the same rule for AI systems, and it catches the same companies for the same reason: the customer sees your name, so the law hands you the file.

Where open-source software sits

This part is misreported constantly. The regulation does not exempt open source by name. Everything hangs on commercial activity, because the CRA reaches only products made available on the market, meaning supplied in the course of a commercial activity, so software that is published rather than supplied commercially falls outside. Recital 18 adds that how a project was developed or financed does not settle the question by itself. Article 3(14) then creates a middle category, the open-source software steward: a legal person, other than a manufacturer, that systematically supports the development of specific open-source products intended for commercial activities. Article 24 gives stewards a short list, so a documented cybersecurity policy, cooperation with market surveillance authorities on request, and reporting of actively exploited vulnerabilities. No conformity assessment, no CE marking, and Article 64(10) keeps them outside the fines. A company that packages open-source software and sells it is the manufacturer of that product, whatever the licence says.

What the product has to have

Annex I Part I opens with the requirement that has the sharpest edge: the product is placed on the market "without known exploitable vulnerabilities". The rest of Part I is a secure by default configuration, updates that can install automatically, access control, encryption of relevant data, data minimisation and a limited attack surface.

Part II runs for years after the sale. It asks for a software bill of materials in a commonly used, machine-readable format covering at least the top-level dependencies, remediation without delay through security updates that go out separately from feature updates where that is feasible, a coordinated vulnerability disclosure policy with a contact address where a researcher gets an answer, and updates distributed securely and free of charge, unless a business customer agreed otherwise for a tailor-made product. The SBOM here is the classic-software counterpart of the AI bill of materials, and it is the one written into law.

Around all of that sits the support period. Article 13(8) says it reflects how long the product is expected to be in use and "shall be at least five years", unless the product genuinely lives shorter, and Article 13(19) says the end date is stated clearly at the time of purchase.

Reporting: the deadlines that arrived first

Article 14 has applied since 11 September 2026, fifteen months ahead of the rest, and it bites on products already in the field rather than only on what ships from December 2027. That timing is what catches companies out.

Two things trigger it. An actively exploited vulnerability, which Article 3(42) defines as one "for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner". And a severe incident, which under Article 14(5) harms or could harm the ability of the product to protect sensitive or important data or functions, or could lead to malicious code running in the product or in a user's systems. Both run on the same three stages, counted from the moment the manufacturer becomes aware.

1. 24 hours: an early warning.

2. 72 hours: a fuller notification, with what is known and any corrective measure taken.

3. The final report: within 14 days of a corrective measure becoming available for a vulnerability, and within one month for a severe incident.

One submission covers both recipients. It goes to the CSIRT designated as coordinator in the country of your main establishment and reaches ENISA at the same time, through the single reporting platform ENISA runs under Article 16. Affected users have to be told, and when the flaw sits in somebody else's component, so does whoever maintains it.

The rest of the calendar

In force since 10 December 2024, Chapter IV on notified bodies since 11 June 2026, Article 14 since 11 September 2026, everything else from 11 December 2027. Products placed on the market before that last date come under the full regime only if they are substantially modified afterwards. The standards are not finished either: standardisation request M/606 was accepted by CEN, CENELEC and ETSI in April 2025, and as of September 2026 no harmonised standard under it has been cited in the Official Journal. Until one is, there is no presumption of conformity to lean on and manufacturers document against the Annex I text itself.

The CRA versus NIS2: a product or an organisation

NIS2 attaches to your organisation. Directive (EU) 2022/2555, transposed in Belgium by the law of 26 April 2024 that took effect on 18 October 2024, asks whether your company sits in a listed sector and above a size threshold. If it does, you register with the Centre for Cybersecurity Belgium, put risk management measures in place, and report significant incidents in your own services through Safeonweb@work on a 24 hour, 72 hour and one month rhythm.

The CRA attaches to a thing you sell. Sector and headcount appear nowhere in the test. Two people selling one connected sensor are a manufacturer with the full list. A three hundred person accountancy firm that sells no software has no CRA manufacturer obligations at all. A company can be both, and the duties then sit side by side rather than merging: the same clock shapes, a different trigger, a different channel.

NIS2 asks how you defend your own network. The CRA asks what you shipped, and it keeps asking for at least five years after the invoice.

What this means for a Belgian SME

Take a company of twenty-eight people near Kortrijk that builds a connected controller for cold stores: a box with firmware, a phone app, and a hosted dashboard the box needs to run its defrost cycles. The three pieces are one product with digital elements, because the dashboard is a remote data processing solution without which a function of the box does not work.

Since 11 September 2026 the reporting duty already covers the units in the field. If a researcher reports a firmware flaw and there is reliable evidence somebody is exploiting it, the 24 hour clock starts once the company has reasonable certainty about it, and registration on the ENISA platform has to exist before that day rather than on it.

For units placed on the market from 11 December 2027 the rest applies: no known exploitable vulnerabilities at release, an SBOM, a published disclosure policy with a contact address, a protected update mechanism, a support period of at least five years with its end date visible at the point of sale, the Annex VII technical documentation, an EU declaration of conformity and the CE marking. A controller like this is not in the Annex III list of important products, so the internal control route stays open and no notified body is involved.

A company that only buys gets a different version of the same list: supplier questions today, a mark on the box later. What is the end date of the support period, is there a coordinated vulnerability disclosure policy and where does a report go, will we get an SBOM, who is the manufacturer if the product is rebadged, and are security updates free and separate from feature releases. A supplier that cannot answer the support period question in September 2026 has not started.

Two things on the Belgian side are still open. The CCB is the national CSIRT under the NIS2 law and publishes CRA information, which makes it the natural route for a Belgian manufacturer's notification, and which Belgian authority carries out CRA market surveillance has not been settled publicly. The ceiling on penalties is in Article 64: for breaching Annex I or Articles 13 and 14, up to 15 million euros or 2.5 percent of worldwide annual turnover, whichever is higher, with the authority told to weigh the size of the company.