What is the Cyber Resilience Act?

The Cyber Resilience Act in plain English

With electrical appliances, it goes without saying: a toaster has to be electrically safe, or it cannot be sold. For a long time, there was no comparable, overarching obligation for digital security. The Cyber Resilience Act, or CRA for short, closes this gap. It makes cybersecurity a prerequisite for placing a product on the EU market – recognizable by the familiar CE marking (the EU’s conformity mark).

The law’s official name is Regulation (EU) 2024/2847. As a regulation, it applies directly in all EU member states. It covers “products with digital elements”: hardware and software that can connect, directly or indirectly, to a device or network. These include routers, surveillance cameras, smart home devices, and industrial controllers, but also apps, operating systems, and other software made available on the market.

What the Cyber Resilience Act requires

The obligations apply primarily to manufacturers and, to a lesser extent, to importers and distributors. The key building blocks:

1. Security from the outset: Manufacturers assess the cyber risks of their product and design it accordingly (“security by design”). It must not contain any known exploitable vulnerabilities and must ship with secure default settings.
2. Handling vulnerabilities: During the support period, manufacturers must fix vulnerabilities and provide security updates. This period must be at least five years – shorter only if the product is expected to be in use for less time.
3. Documenting components: Manufacturers must record which components their software is made of, including in an SBOM, a machine-readable software bill of materials.
4. Regular testing: The security of the product must be tested and reviewed effectively and regularly.
5. Reporting: Manufacturers report actively exploited vulnerabilities and severe security incidents via a central EU platform to the competent national computer security incident response team (CSIRT) and to ENISA, the EU Agency for Cybersecurity. An early warning is due within 24 hours, a notification within 72 hours, and a final report later on. Affected users must also be informed.
6. Demonstrating conformity: Manufacturers must prove that their product meets the requirements. For most products, a self-assessment is sufficient. Stricter procedures, some involving independent conformity assessment bodies, apply to “important” products such as password managers, routers, or firewalls, and to “critical” products.

The obligations apply in stages. The CRA entered into force on December 10, 2024. The reporting obligations have applied since September 11, 2026 – including for products that were placed on the market before that date. Most of the remaining requirements apply from December 11, 2027. Areas with their own rules, such as medical devices and vehicles, are excluded. Pure cloud services (software as a service) generally fall outside the scope of the CRA; NIS2 may apply to them instead.

A practical example

Here’s a typical scenario: A mid-sized manufacturer develops a connected controller for heating systems. Customers operate it via an app, and updates are delivered through the cloud. Until now, the firmware – the software built into the device – had mainly been tested for functionality.

With the CRA in mind, the team creates an SBOM. In the process, they notice that an embedded open-source library – a freely available software component – is outdated and has a known vulnerability. A security test also uncovers a hard-coded maintenance password. Both issues are fixed before the next release. The manufacturer also sets up a contact address for vulnerability reports and defines who will submit the 24-hour early warning if an incident occurs.

Why does this matter for businesses?

For manufacturers, the CRA is mandatory: from December 11, 2027, only products that meet the requirements may be newly placed on the market. Violations of the essential requirements and the manufacturer obligations can result in fines of up to €15 million or 2.5 percent of worldwide annual turnover, whichever is higher. The reporting obligations are already in effect.

Even companies that don’t develop anything themselves can be affected. Anyone who sells products under their own name or substantially modifies them may legally be considered a manufacturer. And companies that buy connected devices or software can expect more secure products and reliable security updates going forward.

What businesses should do now

• Determine whether you’re affected: Check which of your products contain digital elements and which category they fall into.
• Set up a reporting process: Define who detects, assesses, and reports actively exploited vulnerabilities on time.
• Introduce an SBOM: Record all components and dependencies, and keep the list up to date.
• Develop securely: Build security requirements, code reviews (systematic reviews of the source code), and testing into your development process.
• Get independent testing: Have firmware, apps, interfaces, and cloud connectivity tested before market launch.
• Plan for updates: Define the support period and ensure a secure update mechanism.
• Make reporting possible: Set up a point of contact and a policy for handling reported vulnerabilities.

Note: This article provides a general overview and does not constitute legal advice.

How Rootsektor can help

With Code Review & Reverse Engineering, we examine the source code, firmware, and dependencies of your products for vulnerabilities and support you in creating and reviewing an SBOM. We test connected devices, including their apps and cloud connectivity, as part of our OT, ICS/SCADA & IoT service. Our report and test certificate support your technical documentation. For your penetration test, you’ll receive a fixed-price quote within 24 hours of scoping (on business days) – request it via our Pentest Quote page.