What is the Cyber Resilience Act? An overview for you.
The Cyber Resilience Act (CRA) is an EU regulation that has been in force since 10 December 2024. It requires manufacturers of software and connected hardware to meet essential cybersecurity requirements — from product development and vulnerability management through to reporting obligations.
The essentials in 60 seconds
- Entry into force: 10 December 2024 (Art. 71(1) CRA — 20 days after publication in the Official Journal on 20 November 2024).
- Reporting obligations: from 11 September 2026 (Art. 71(2) CRA in conjunction with Art. 14).
- Full application: from 11 December 2027 (Art. 71(2) CRA). For products placed on the market before that date, the transitional provisions of Art. 69 CRA apply.
- Fines: under Art. 64(2) CRA, from 11 December 2027 — up to EUR 15 million or 2.5 % of worldwide annual turnover, whichever is higher. Microenterprises and small enterprises are exempt from fines for non-compliance with the 24-hour early warning under Art. 64(10)(a) CRA; the reporting obligation itself remains.
- Scope: in principle, products with digital elements that are made available on the EU market and whose intended or reasonably foreseeable use includes a direct or indirect data connection to a device or network.
Why does the CRA exist?
Many products with digital elements contain vulnerabilities, while security updates are not always provided in a timely and reliable manner. At the same time, there was previously no horizontal EU legal framework with uniform cybersecurity requirements for connected hardware and software. The CRA therefore establishes common rules for the development, making available on the market and vulnerability handling of products across their life cycle. Why the CRA was created and which products it covers (in German) ↗
Log4Shell showed at the end of 2021 how a vulnerability in a widely used software library can affect numerous products and organisations. For many companies, it was initially hard to determine which of their own or purchased systems contained the affected component. SBOM for software manufacturers: requirements and implementation (in German) ↗
The XZ Utils case in March 2024 was an attempt to plant a backdoor in a widely used open-source component. The manipulation was discovered before the affected versions reached broad stable distribution. The case nonetheless illustrates the risks that can arise from complex software supply chains and adopted components. Bundle & open source: components and responsibility (in German) ↗
Who is affected?
In short: many software and hardware manufacturers that make products with digital elements available on the EU market. What matters is not the type of company alone, but whether a specific product meets the conditions of the CRA.
Who typically falls under the CRA?
The CRA applies to products with digital elements that are made available on the EU market and whose intended purpose or reasonably foreseeable use includes a direct or indirect data connection to a device or network. Those affected include in particular the following product providers and economic operators:
Scope of the CRA at a glance (in German) ↗
Software manufacturers
These include in particular manufacturers of desktop and mobile applications, installable web applications, agents, plug-ins as well as APIs and SDKs that are made available on the EU market as a stand-alone product or as a software component.
Hardware with software
These include, for example, embedded and IoT devices, controllers, sensors, machines and other hardware products that run software and establish a direct or indirect data or network connection.
Embedded software and CE marking (in German) ↗
Authorised representatives, importers, distributors and open-source software stewards
It is not only manufacturers that may be affected by the CRA. Authorised representatives take on the manufacturer's tasks specified in the written mandate and must in particular keep documentation available, cooperate with authorities and respond to their requests (Art. 18 CRA).
Importers and distributors have their own verification, information and cooperation obligations under Art. 19 and 20 CRA. Anyone who markets a product under their own name or trademark, or substantially modifies it under the conditions of Art. 21, is considered the manufacturer of that product.
Open-source software stewards within the meaning of Art. 3(14) CRA are subject to the specific set of obligations under Art. 24 CRA if they systematically support, on a sustained basis, the development of certain open-source products intended for commercial activities.
Bundle & open source: components and responsibility (in German) ↗
Typical borderline cases
Borderline case 1 – SaaS with a desktop, agent or plug-in component
Pure cloud or browser-based SaaS without a local component made available as a product does not, in principle, fall directly under the CRA. However, if a desktop app, a mobile app, an agent or a browser plug-in is added, for example, the associated server-side processing may also be brought within the scope of the CRA as a remote data processing solution – RDPS for short. What matters is the specific product architecture and the significance of the server-side processing for the product's functions.
SaaS & CRA: the RDPS distinction (in German) ↗
Borderline case 2 – Rolling release and continuous deployment
Not every commit or every update triggers a new conformity assessment. What matters is whether a substantial modification within the meaning of Art. 3(30) CRA has occurred. Security updates that solely reduce the cybersecurity risk, do not change the intended purpose and do not introduce new risks are, in principle, not considered a substantial modification.
Rolling release & CRA: substantial modification (in German) ↗
Borderline case 3 – Software bundles and open source
Anyone who makes a software bundle available on the EU market under their own name or trademark bears the CRA responsibility for the product as a whole, including the integrated components. When integrating third-party components and open-source components that are not made available commercially, the risk-based due diligence obligation under Art. 13(5) CRA applies.
This must be distinguished from the open-source software steward under Art. 3(14) and Art. 24 CRA, which is subject to a separate, lighter set of obligations than manufacturers.
Bundle & open source: components and responsibility (in German) ↗
Not sure which case applies to your product? The free Quick Check helps you with an initial assessment – without obligation and without a login.
This does not constitute legal advice within the meaning of the German Legal Services Act (RDG). The final classification depends on the specific product, how it is made available and its technical architecture.
Legal basis: Regulation (EU) 2024/2847 – Cyber Resilience Act.
What exactly does the CRA require?
Key requirements with source references to the Annexes and Articles of Regulation (EU) 2024/2847.
Security requirements for the product
- Assessment of cybersecurity risks – Art. 13(2)–(4) CRA
- Appropriate level of cybersecurity based on the risks – Annex I Part I No. 1
- No known exploitable vulnerabilities when made available on the market – Annex I Part I No. 2 point (a)
- Secure by default configuration and the possibility to reset the product to its original state – Annex I Part I No. 2 point (b)
- Remediation of vulnerabilities through security updates; where applicable, automatic installation as the default setting with an opt-out – Annex I Part I No. 2 point (c)
- Protection from unauthorised access by appropriate control mechanisms – Annex I Part I No. 2 point (d)
- Protection of the confidentiality of stored, transmitted or otherwise processed data, for example by encrypting relevant data – Annex I Part I No. 2 point (e)
- Protection of the integrity of data, commands, programs and configuration – Annex I Part I No. 2 point (f)
- Processing only of data that is necessary for the intended purpose – Annex I Part I No. 2 point (g)
- Protection of the availability of essential functions, including resilience against and mitigation of denial-of-service attacks – Annex I Part I No. 2 point (h)
- Minimising negative impact on the availability of other devices, networks and services – Annex I Part I No. 2 point (i)
- Limiting attack surfaces, including external interfaces – Annex I Part I No. 2 point (j)
- Limiting the impact of security incidents – Annex I Part I No. 2 point (k)
- Recording and monitoring of security-relevant activity with an opt-out option for users – Annex I Part I No. 2 point (l)
- Secure and permanent deletion as well as secure transfer of data and settings – Annex I Part I No. 2 point (m)
Vulnerability handling and security updates
- Documentation of components and vulnerabilities, including by means of an SBOM in a commonly used machine-readable format covering at least the top-level dependencies – Annex I Part II No. 1
- Addressing and remediating vulnerabilities without delay; security updates should, where technically feasible, be delivered separately from functionality updates – Annex I Part II No. 2
- Regular and effective security testing and reviews – Annex I Part II No. 3
- Publication or sharing of information about fixed vulnerabilities once a security update is available; a delay is permitted only in justified cases – Annex I Part II No. 4
- Putting in place and enforcing a policy on coordinated vulnerability disclosure – Annex I Part II No. 5
- Facilitating the sharing of information about potential vulnerabilities, including a contact address for reports – Annex I Part II No. 6
- Secure distribution of updates to remediate or mitigate vulnerabilities without delay – Annex I Part II No. 7
- Provision of security updates without delay and, as a rule, free of charge; for tailor-made products for business users, other arrangements may be agreed – Annex I Part II No. 8
Documentation and conformity
- Technical documentation including the cybersecurity risk assessment – Art. 31 and Annex VII, in particular Annex VII No. 3
- Carrying out the applicable conformity assessment procedure – Art. 32 and Annex VIII
- EU declaration of conformity – Art. 28 and Annex V
- CE marking – Art. 30
- Provision of the required information and instructions to the user – Art. 13(18) and Annex II
Reporting obligations under Art. 14 CRA
- Actively exploited vulnerability: early warning within 24 hours of becoming aware; vulnerability notification within 72 hours; final report no later than 14 days after a corrective or mitigating measure is available.
- Severe incident having an impact on the security of the product: early warning within 24 hours; incident notification within 72 hours; final report, as a rule, within one month of the 72-hour notification.
- Notifications are submitted via the single reporting platform to the CSIRT designated as coordinator and are simultaneously accessible to ENISA – Art. 14(1), (3) and (7).
- Affected users must be informed about the vulnerability or the incident and about any corrective or mitigating measures required – Art. 14(8).
- Information about fixed vulnerabilities must be published or shared once a security update is available – Annex I Part II No. 4.
What should you do now?
Do not wait until 2027: this is what you should tackle now
Assess applicability
Clarify whether and how the CRA could affect your product. The free Quick Check gives you initial guidance – without obligation and without a login.
Prepare an SBOM
Record your software components and dependencies in a structured way. For products subject to the CRA, manufacturers must produce a machine-readable SBOM covering at least the top-level dependencies (Annex I Part II No. 1 CRA).
Define reporting channels
From 11 September 2026, the reporting obligations under Art. 14 CRA apply. You should therefore define responsibilities and procedures for actively exploited vulnerabilities and severe incidents at an early stage – the first notification may be required within 24 hours.