Last updated: 7 October 2026
Short answer: if you sell hardware or software with a network or data connection in the EU, the Cyber Resilience Act (CRA) applies to you. Since 11 September 2026 you must report actively exploited vulnerabilities and severe security incidents in your products to the authorities within 24 hours, including for products already on sale. By 11 December 2027, every new product must meet the Act's security requirements, carry a CE mark for cybersecurity, come with a software bill of materials and receive security updates for at least five years. Small firms get some help and some relief, but no exemption.
This article summarises the regulation for engineers and business owners. It is not legal advice; for a specific product, check the official text and guidance or ask a specialist.
What is the Cyber Resilience Act?
It is Regulation (EU) 2024/2847, published in November 2024 and in force since 10 December 2024. It does for cybersecurity what CE marking already does for electrical safety: a product cannot be sold in the EU unless the manufacturer has built in security, documented it and taken responsibility for it over the product's life. The European Commission's overview page has the official summary.
Which dates matter?
| Date | What applies |
|---|---|
| 10 December 2024 | The regulation entered into force |
| 11 June 2026 | Rules for the bodies that certify products (notified bodies) |
| 11 September 2026 | Reporting of actively exploited vulnerabilities and severe incidents, including for products already on the market |
| 11 December 2027 | Everything else: security requirements, conformity assessment, CE marking |
Products already on sale before December 2027 only have to meet the full requirements if they are substantially modified afterwards, but the reporting duty covers them now.
Is your product in scope?
The CRA covers "products with digital elements": hardware or software whose intended use includes a data connection to a device or network. That includes connected devices, industrial controllers, routers, apps, desktop software and firmware, plus the manufacturer's cloud back end where the product cannot work without it, such as the service that lets you control a smart device from your phone.
Out of scope:
- Products already covered by their own EU rules: medical and in-vitro diagnostic devices, motor vehicles, certified aviation products and marine equipment.
- Pure software-as-a-service, which falls under the separate NIS2 cybersecurity directive instead.
- Open-source software not supplied as part of a commercial activity. Simply publishing code on a public repository does not count as placing it on the market.
- Spare parts identical to the originals, and products developed only for national security or defence.
Which category is your product in?
The category decides how you prove conformity:
| Category | Examples (from Annexes III and IV) | How conformity is shown |
|---|---|---|
| Default (most products) | Most apps, connected appliances, printers, industrial sensors, games | Self-assessment by the manufacturer |
| Important, Class I | Password managers, VPNs, browsers, operating systems, routers and modems, smart locks and security cameras, smart-home assistants, connected toys | Self-assessment only if you fully apply harmonised standards or an EU certification scheme; otherwise a notified body |
| Important, Class II | Firewalls, intrusion detection systems, hypervisors and container runtimes, tamper-resistant microcontrollers | A notified body or EU certification |
| Critical | Smartcards and secure elements, smart meter gateways, hardware security boxes | EU cybersecurity certification where required |
The Commission clarified the technical descriptions of these categories in Implementing Regulation (EU) 2025/2392 in late 2025, and published practical guidance for businesses in July 2026.
What must manufacturers do?
Build security in (Annex I, Part I)
- Ship with no known exploitable vulnerabilities.
- Secure by default: no universal default passwords, a way to reset to a secure state.
- Provide security updates, installed automatically by default where appropriate, with an option to opt out.
- Protect data with access control and encryption, collect only what is needed, and let users delete their data securely.
- Minimise the attack surface and log security-relevant events.
Handle vulnerabilities for the product's life (Annex I, Part II)
- Keep a software bill of materials (SBOM) in a machine-readable format, covering at least the top-level dependencies. Common formats are SPDX and CycloneDX. You do not have to publish it, but authorities can ask for it.
- Fix vulnerabilities without delay, and where feasible release security fixes separately from feature updates.
- Publish a coordinated vulnerability disclosure policy and a contact address for security reports.
- Provide security updates free of charge, with advisories explaining them.
Support and document it
- Set a support period of at least five years, or shorter only if the product is expected to be used for less time. Tell buyers the end date, at least month and year, at the point of sale.
- Keep each security update available for at least 10 years or the rest of the support period.
- Carry out and document a cybersecurity risk assessment, including due diligence on third-party and open-source components.
- Prepare technical documentation, an EU declaration of conformity and the CE marking, and keep the documents for 10 years.
How does the reporting obligation work?
Since 11 September 2026, manufacturers must report through ENISA's Single Reporting Platform, which went live that day:
| Event | Early warning | Notification | Final report |
|---|---|---|---|
| Actively exploited vulnerability in your product | Within 24 hours | Within 72 hours | Within 14 days after a fix or mitigation is available |
| Severe incident affecting your product's security | Within 24 hours | Within 72 hours | Within one month |
"Actively exploited" means there is evidence that attackers are using the vulnerability, not just that it exists. A severe incident is one that affects the confidentiality, integrity or availability of sensitive data or functions, or leads to malicious code being introduced. The Commission's reporting page explains the process.
What are the penalties, and is there relief for small firms?
Fines can reach €15 million or 2.5% of worldwide annual turnover, whichever is higher, for breaching the essential requirements or the manufacturer and reporting obligations, with lower tiers for other breaches. Authorities must take company size into account.
For small companies:
- The Act states that micro and small enterprises should not be fined for missing the 24-hour early-warning deadline. How this interacts with the other penalty provisions is not entirely clear in the text, so do not rely on it as a reason to report late.
- EU countries must provide help desks, training and support for small firms, and may set up regulatory sandboxes.
- Micro and small enterprises will be able to use a simplified technical documentation form, to be set out by the Commission.
- Open-source "stewards", foundations that support open-source projects used commercially, have lighter obligations and are not subject to fines.
Are the technical standards ready?
Not yet. The Commission has asked the European standards bodies for 41 harmonised standards, both general and product-specific, and lists the first deliverables for the third quarter of 2026, with reports that deadlines may slip by a few months. Until standards are published, many Class I products cannot use self-assessment and will need a notified body, so check your category early.
A practical plan for a small company
- List your products and decide, for each, whether it is in scope and which category it falls into.
- Set up reporting now. Register on the ENISA platform, decide who in the company judges whether a vulnerability is actively exploited, and make sure someone can file a report within 24 hours, including at weekends.
- Publish a vulnerability disclosure policy and a security contact address, for example a security.txt file on your website.
- Generate SBOMs as part of your build process. Many build tools can export SPDX or CycloneDX files automatically.
- Decide support periods and how you will deliver updates for at least five years.
- Document your risk assessment, including the open-source components you depend on.
- Plan the conformity route: self-assessment, standards or a notified body, depending on category.
- Use national support: contact your country's CRA help desk and follow the Commission's implementation FAQ.
- Aim to have CE marking and declarations ready well before 11 December 2027.
Much of this overlaps with good security practice you may already follow; the controls in my article on what cyber insurers require from small businesses are a good starting point for your own systems. The CRA sits alongside other EU rules: see what engineers should know about data privacy laws in 2026 and, if your product includes AI features, the state of AI regulation in 2026.
FAQ
Does the Cyber Resilience Act apply to companies outside the EU?
Yes, if they sell products with digital elements in the EU. Importers and distributors also have obligations, including checking that products carry the CE marking and documentation.
Does it apply to software, or only hardware?
Both. Standalone software such as apps and desktop programs is in scope, as is firmware. Pure software-as-a-service is generally covered by the NIS2 directive instead.
Do I need to report every vulnerability?
No. The mandatory reporting covers vulnerabilities that are actively exploited and severe incidents. Other vulnerabilities must still be fixed and handled through your disclosure process.
What if my product is already on sale?
The reporting obligation already applies to it. The full security requirements apply to products placed on the market from 11 December 2027, or to existing products that are substantially modified after that date.
