EU Cyber Resilience Act (CRA)

Why does it matter?

The CRA moves security into product design. Before, a connected product could be sold with known flaws and no update plan. The Regulation sets a legal baseline for security by design, vulnerability handling and transparency, and makes each economic operator in the supply chain responsible for checking it.

Key benefits include:

• A legal baseline for products

Annex I Part I requires products to be made available without known exploitable vulnerabilities, secure by default, protected against unauthorized access and with security updates (Annex I, Part I (2)).

• Vulnerability handling as a duty

Annex I Part II requires manufacturers to document vulnerabilities and components, including a software bill of materials, test regularly, and run a coordinated vulnerability disclosure policy.

• A support period

Manufacturers set a support period reflecting the expected use time, and it must be at least five years unless the product will be used for less time (Article 13(8)).

• Reporting to authorities

Actively exploited vulnerabilities and severe incidents are reported on a 24-hour, 72-hour and final-report timetable (Article 14).

• Fines scaled to turnover

Breaches of the essential requirements and Articles 13 and 14 can bring fines up to EUR 15 million or 2.5 percent of worldwide turnover (Article 64(2)).

How does it work?

The Regulation applies to products with digital elements made available on the EU market whose intended or reasonably foreseeable use includes a direct or indirect data connection (Article 2(1)). Important products with digital elements in Annex III, split into class I and class II, face stricter conformity assessment (Articles 7 and 32), and critical products in Annex IV may need a European cybersecurity certification scheme.

For most products the manufacturer may use internal control (Annex VIII module A). Class I important products need a third-party route unless harmonized standards are applied, class II products need EU-type examination (module B plus C) or full quality assurance (module H), and critical products follow Article 32(4). The manufacturer then draws up the declaration of conformity (Article 28) and affixes the CE marking (Article 30).

After placing a product on the market the manufacturer keeps handling vulnerabilities throughout the support period, provides security updates free of charge, publicly discloses fixed vulnerabilities and reports under Article 14. Distributors and importers check the CE marking, documentation and manufacturer contact details.

Key Elements

• Essential requirements (Annex I, Part I)

Thirteen requirements covering known exploitable vulnerabilities, secure-by-default configuration, security updates, access control, encryption and integrity, data minimization, availability, attack surface, incident impact, logging and secure data removal.

• Vulnerability handling (Annex I, Part II)

Identify and document vulnerabilities and components with a software bill of materials, fix without delay, test regularly, disclose fixed vulnerabilities, keep a coordinated disclosure policy, and distribute updates securely.

• Manufacturer obligations (Article 13)

Risk assessment in the technical documentation, due diligence on third-party and open-source components, documentation kept at least 10 years or the support period, and a single point of contact.

• Reporting obligations (Article 14)

An early warning within 24 hours, a notification within 72 hours and a final report within 14 days of a fix for actively exploited vulnerabilities, or within one month of the notification for severe incidents.

• Conformity assessment (Article 32 and Annexes III, IV and VIII)

The route depends on whether the product is default, important class I or II, or critical.

• Penalties (Article 64)

Up to EUR 15 million or 2.5 percent for essential requirement and Article 13 and 14 breaches, EUR 10 million or 2 percent for other obligations and EUR 5 million or 1 percent for misleading information.

What does it cover?

The CRA applies to manufacturers, importers and distributors of products with digital elements placed on the EU market, whether made inside or outside the Union. It does not apply to products covered by the medical device, in vitro diagnostic and motor vehicle regulations, to products certified under the EU aviation safety regulation, to spare parts or to products made only for national security or defense (Article 2). Open-source software is covered when it is made available in the course of commercial activity.

What are its objectives?

The CRA sets security requirements for products from design to the end of support.

Make products with digital elements secure by design and by default.

Require vulnerability handling and security updates throughout a support period.

Make manufacturers report actively exploited vulnerabilities and severe incidents.

Give buyers clear security information and a contact point.

Let market surveillance authorities check conformity and fine non-compliance.

Framework in Context

The CRA protects products, while the NIS2 Directive protects the operators that use networks and information systems. Reports under Article 14 go to the CSIRT coordinator and ENISA, and for products that must also meet sector rules the CRA can be limited or excluded where those rules give equal or higher protection (Article 2(5)). Harmonized standards, Commission implementing acts and European cybersecurity certification schemes will supply technical detail.

Common Framework Mappings

Organizations commonly map CRA obligations to complementary European and international standards to harmonize product security, legal compliance, operational resilience, and data protection across development and incident response processes.

Mapped frameworks include:

Common Criteria (ISO/IEC 15408)

Digital Operational Resilience Act (DORA)

ETSI EN 303 645

General Data Protection Regulation (GDPR)

IEC 62443

ISO/IEC 27001

NIS2 Directive

NIST Secure Software Development Framework (SSDF)