Example article for the prototype. Draft, to be reviewed by Enrico before publication.
This article is available in English only.
Does the Cyber Resilience Act apply to your product? Five questions to find out.
Since September 2026, manufacturers have had to report actively exploited vulnerabilities. From 11 December 2027, every obligation of the CRA applies. Many mid-sized manufacturers still have not decided whether they are affected. Here is how to decide in an afternoon.
The Cyber Resilience Act, Regulation (EU) 2024/2847, is the first EU law that sets cybersecurity requirements for products rather than for companies. If you make a product that contains software and sell it in the EU, the chances are good that it applies to you. The questions below are the ones we go through with every manufacturer in our applicability check. They will not replace the check, but they will tell you whether you need one.
1. Does your product contain software, or does it connect to anything?
The CRA covers “products with digital elements”: hardware or software products whose intended or reasonably foreseeable use includes a direct or indirect data connection to a device or a network. That is a wide net. A control unit with firmware and a service port counts. A sensor that talks to a gateway counts. A machine with an HMI that gets updates from a USB stick counts, because the connection does not have to be permanent or wireless.
What does not count: purely mechanical products, and software that is never placed on the market as a product, such as the internal tooling you wrote for your own plant.
2. Do you place it on the EU market in the course of a commercial activity?
The CRA applies when a product is made available on the EU market in the course of a commercial activity, whether in return for payment or free of charge. Selling counts. Supplying a product as part of a service counts. A free firmware you provide to customers of your hardware counts, because it is part of the commercial product.
Free and open-source software that is developed and supplied outside a commercial activity is excluded, and there is a lighter regime for organisations that act as “open-source software stewards”. If your product includes open-source components, that does not take the product out of scope. It makes your SBOM more important.
3. Is the product already covered by a sector regulation with its own cybersecurity rules?
Some product groups are excluded because other EU rules already cover cybersecurity: medical devices and in-vitro diagnostics, motor vehicles under the type-approval framework, civil aviation, and marine equipment. Products developed exclusively for national security or defence are excluded too.
Two warnings here. First, the exclusion applies to the product that falls under those rules, not to everything a company in that sector makes. A test bench you sell to automotive customers is not a motor vehicle. Second, “we are a supplier to an excluded industry” is not an exclusion. If your component is placed on the market as a product with digital elements, the CRA applies to it.
4. Which class does it fall into?
Most products are in the default category: the manufacturer assesses conformity itself, draws up the technical documentation and affixes the CE marking. Annex III lists “important products” in two classes, and Annex IV lists “critical products”. Important products of class I can still use self-assessment if harmonised standards are applied in full; class II and critical products need a third party.
The lists are specific. Among them are operating systems, routers, modems and switches, microprocessors and microcontrollers with security-related functions, firewalls, VPN products, hypervisors and smart-home devices with security functions. Industrial products often contain such components without being one themselves. A machine with a built-in Linux system is not an operating system; the operating system in it is a component you have to manage, with its own update obligations. Read the annexes with your product list next to you, and decide per product family, not per company.
5. Who in your company owns it?
This is the question that decides whether you are ready in December 2027. The CRA asks for things that cut across departments: a software bill of materials in a machine-readable format for every product, a process to handle and disclose vulnerabilities, a single point of contact for reporting them, security updates for a defined support period (as a rule at least five years), reporting of actively exploited vulnerabilities to the authorities within 24 hours for an early warning and 72 hours for a notification, and technical documentation that proves all of it.
None of this is a purely legal task, and none of it is a purely engineering task. It needs a person who owns the product's security over its lifetime, and a pipeline that produces the evidence as a by-product of every release instead of as a project before every audit.
Our answer to question five. The CRA applicability check gives you a classification per product family with the reasoning written out, so you can hand it to your notified body. Fixed price, result in two weeks. If the answer is “yes, it applies”, the gap analysis follows, and release evidence from your pipeline is the service that keeps you compliant after that. Product Security & CRA
What to do this quarter
- List every product you sell that contains software or connects to something. Include the variants.
- Answer questions one to three per product family. Write the reasoning down; you will need it later.
- For the products that remain, check Annex III and IV line by line.
- Name the owner. Give them the mandate to change the release process, not just to write a policy.
- Produce a first SBOM for one product. It shows you more about your supply chain than any workshop.
This article is general information, not legal advice. The dates refer to Regulation (EU) 2024/2847 as adopted: reporting obligations since 11 September 2026, full application from 11 December 2027.