The CRA, or Cyber Resilience Act, is a European Union regulation that sets mandatory cybersecurity requirements for products with digital elements, meaning hardware and software that can connect to a device or network, across their design, production and support lifecycle. In cybersecurity law, it is the first horizontal EU product law for security: products must meet its essential requirements and carry CE marking before they can be sold on the EU market.
Adopted as Regulation (EU) 2024/2847, the CRA entered into force in December 2024 and applies in stages. Vulnerability and incident reporting duties apply from September 2026, and the full set of product obligations applies from December 2027.
What the Cyber Resilience Act covers
The CRA applies to products with digital elements made available on the EU market whose intended or foreseeable use includes a data connection. This covers connected consumer devices, industrial components, operating systems, desktop and mobile applications and firmware, as well as remote data processing solutions that are essential to a product’s functions.
Several categories fall outside the CRA because sector-specific law already regulates them, and pure online services are handled mainly by NIS2 rather than by product rules.
| Item | Covered | Reason |
|---|---|---|
| Smart home devices and routers | Yes | Connected hardware products |
| Commercial software applications | Yes | Software products with digital elements |
| Cloud backend of a connected device | Yes, as remote processing | Essential to product function |
| Stand-alone software as a service | No | Treated as a service under NIS2 |
| Medical devices and vehicles | No | Covered by sectoral product law |
| Non-commercial open-source software | No | Not supplied in a commercial activity |
Open-source software receives tailored treatment. Projects developed and shared without commercial activity are outside the scope, while foundations and other organizations that systematically support open-source products intended for commercial use act as open-source software stewards. Stewards carry a light regime: a cybersecurity policy, cooperation with authorities and participation in vulnerability reporting, but no CE marking and no fines.
Essential cybersecurity requirements
The CRA’s essential requirements fall into two groups: product security properties and vulnerability handling processes. Manufacturers demonstrate conformity mainly by applying harmonized standards being developed for the regulation.
| Requirement | What a manufacturer must do |
|---|---|
| No known exploitable vulnerabilities | Ship without known exploitable flaws |
| Secure by default configuration | Provide safe defaults and a reset option |
| Access control and data protection | Prevent unauthorized access and protect data |
| Minimal attack surface | Limit interfaces and exposed functions |
| Security updates | Deliver fixes free of charge, separately where possible |
| Software bill of materials | Document components and dependencies |
| Coordinated vulnerability disclosure | Publish a policy and a reporting contact |
Manufacturers must define a support period reflecting how long the product is expected to be used, which must normally be at least five years unless the product is expected to be used for a shorter time. During that period they must handle vulnerabilities and provide security updates.
Product categories and conformity assessment
The level of scrutiny depends on the product’s criticality. Most products are in the default category and allow self-assessment; products listed as important or critical require stricter procedures.
| Category | Example products | Conformity route |
|---|---|---|
| Default | Most apps, printers, toys, speakers | Internal control by the manufacturer |
| Important class I | Browsers, password managers, VPNs, routers | Harmonized standards or third-party assessment |
| Important class II | Firewalls, hypervisors, intrusion detection systems | Third-party assessment required |
| Critical | Smart meter gateways, smartcards, secure elements | Possible mandatory European certification |
Importers and distributors have their own duties. They must check that products bear CE marking and the required documentation, and they must stop supplying products they know or suspect to be non-compliant.
Manufacturers that need a third-party assessment should plan early. The rules for notified bodies apply from June 2026, but capacity is limited while bodies are being designated, and an assessment for an important or critical product can take several months to complete before the December 2027 deadline.
Reporting obligations and timelines
From September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents affecting product security through a single reporting platform operated by ENISA, which routes the reports to the competent national CSIRT. The duty applies to products already on the market, not only to new ones.
| Report | Deadline | Content |
|---|---|---|
| Early warning | Within 24 hours of awareness | Basic facts and affected member states |
| Notification | Within 72 hours | Details, severity and mitigations |
| Final report for a vulnerability | Within 14 days of a fix being available | Root cause and corrective measures |
| Final report for an incident | Within one month | Full description and impact |
Manufacturers must also inform affected users about exploited vulnerabilities and incidents, and about the measures they can take. These deadlines mirror the incident reporting pattern familiar from NIS2, which helps organizations reuse one incident response process for both laws.
CRA compared with related laws, penalties and pitfalls
The CRA regulates products, while NIS2 and DORA regulate organizations and their operations, and the EU Cybersecurity Act provides voluntary certification schemes. A software vendor can therefore face the CRA for what it sells and NIS2 for how it runs its own infrastructure.
Non-compliance with essential requirements can be fined up to 15 million euros or 2.5 percent of worldwide annual turnover, whichever is higher. Common mistakes include:
- Treating the CRA as a launch checklist, although duties last for the whole support period.
- Ignoring third-party components, even though the manufacturer answers for vulnerabilities in integrated open-source code.
- Underestimating 2026 reporting, which applies before the main obligations.
- Misjudging the category, which determines whether a third-party assessment is needed.
Understanding it simply
The CRA is a safety standard for connected products, similar to the rules that keep electrical appliances from overheating. It requires anything from a smart doorbell to a business application to be built with security in mind before it is sold in the EU.
It also says the job does not end at the sale. Makers must fix security flaws for years and warn authorities quickly when attackers start exploiting a weakness.
Applied in practice
A mid-sized manufacturer of connected security cameras sells across the EU. To prepare for the CRA, it maps its products as important class I, creates a software bill of materials for each firmware version, replaces a shared default password with unique credentials per device and commits to a support period of six years.
In autumn 2026, researchers discover that attackers are exploiting a flaw in an open-source library inside the camera firmware. The company sends an early warning within 24 hours, a notification within 72 hours and a final report after shipping the patch. Customers receive an automatic update and a notice. The outcome is a contained incident and documented evidence of compliance for market surveillance authorities.