The Cyber Resilience Act (“CRA”) is an EU regulation ((EU) 2847/2024) that defines minimum cybersecurity requirements for software and hardware products. This horizontal regulation is directly applicable in EU countries and concerns many digital products sold in the EU market. Products within the scope of the regulation, including hardware and software, must in the future be accompanied by a CE marking.
The Cyber Resilience Act (“CRA”) is an EU regulation ((EU) 2847/2024) that defines minimum cybersecurity requirements for software and hardware products. This horizontal regulation is directly applicable in EU countries and concerns many digital products sold in the EU market. Products within the scope of the regulation, including hardware and software, must in the future be accompanied by a CE marking.
The CRA could be characterized as a product regulation that focuses on the cybersecurity of products rather than physical safety. Like many EU regulations, breach of the CRA can result in administrative fines calculated based on turnover. Other potential consequences include obligations typical of product safety regulations, such as product withdrawal and recall arrangements. Neglecting the CRA requirements can thus be costly in many ways, and compliance with the regulation governing development processes cannot be achieved by merely compiling mandatory documentation at the last minute. Products to be placed on the EU market in 2027 are being designed now!
In this blog, we examine the CRA particularly from the perspective of product manufacturers and explain where to start preparing to achieve compliance.
What products does the Cyber Resilience Act apply to?
The CRA applies to a wide range of digital products, from household robotic vacuum cleaners to large industrial equipment and their software. The key requirement for the application of the regulation is that, taking into consideration the intended purpose or reasonably foreseeable use of the digital product, there is a data connection to another device or network..
Data connection in this context is to be understood broadly. Connection includes not only physical connection through hardware but also logical connection via network sockets, pipes, files, application programming interfaces or any other types of software interface. In addition to direct connection, indirect data connection must be considered, which may occur when the product itself does not have a data connection, but it is integrated or linked to a broader system that implements the connection.
Certain product categories are specifically excluded from the CRA’s scope. Excluded are product categories already subject to certain other EU regulations concerning product safety, such as medical devices, certain vehicles, marine equipment, and aircraft. The regulation does not apply to products designed for national security or defense purposes. Additionally, cloud services (e.g., Software as a Service, SaaS) are generally excluded from the scope unless they are remote data processing solutions for the product, in the meaning of the CRA.
When must products comply with the Cyber Resilience Act?
The full application of the CRA begins on December 11, 2027. From this date, products within the scope of the regulation sold in the EU market must meet the requirements set by the regulation and bear the CE marking. Additionally, any significant modification to a product already placed on the market will result in the application of CRA to the product.
The requirements for reporting vulnerabilities and incidents will apply already from September 11, 2026.
How is compliance assessed and demonstrated?
Products within the CRA’s scope, including both hardware and software, must bear the CE marking as demonstration of compliance. Achieving the CE marking and compliance requires extensive groundwork in the product's design and development process, as well as carrying out the conformity assessment required by the CRA.
The conformity assessment procedure varies depending on the class to which the product belongs, as defined in the CRA. The classes, listed from the most stringent to the least stringent, are: critical, important class 1, important class 2, and so called “default class” for products outside the first mentioned CRA specific categories. For products in the default class, compliance can be assessed through self-assessment, whereas other classes have more stringent requirements also with third parties involved.
It is to be also noted that mere compliance with the requirements is not enough. The manufacturer must also ensure that the product and its development process generate the documentation required by the regulation, such as cybersecurity risk assessment, technical documentation, and information and instructions to the user.
What does compliance with the Cyber Resilience Act require?
In summary, the CRA sets requirements for three areas:
1. The development process of products and lifecycle procedures from design to decommissioning
2. Cybersecurity features of products
3. Vulnerability management
Requirements for design, development, and production
The CRA sets requirements not only for the product but also for procedures at several stages of the product lifecycle, from design to decommissioning until the end of support period. Products must meet essential cybersecurity requirements, including the primary requirement that "products must be designed, developed, and produced in such a way that their level of cybersecurity is proportionate to the risks" (Annex I, Part I, point 1 of the CRA).
Requirements for product features
Essential cybersecurity requirements related to product properties are defined in Annex I, Part I, Section 2 of the CRA. To name only a few of the requirements, products must, i.e. have secure default configuration, must not have known exploitable vulnerabilities when placed on the market, and must ensure confidentiality, integrity, and minimization of data. Additionally, vulnerabilities must be addressable through security updates. The determination of the level of requirements is based on the mandatory cybersecurity risk assessment (Article 13). .
Requirements for vulnerability management
CRA sets out requirements for vulnerability management. According to CRA Annex I, Part II, manufacturers must:
1. Identify vulnerabilities and components (software bill of materials, SBOM description).
2. Remediate vulnerabilities promptly, for example, through security updates – and if technically possible, separately from functionality updates.
3. Conduct regular security testing and security assessments.
4. Share and disclose information about fixed vulnerabilities after making security updates available.
5. Implement principles for coordinated vulnerability disclosure.
6. Facilitate the sharing of information about vulnerabilities in their product and its third-party components, including providing a contact address for reporting vulnerabilities.
7. Ensure mechanisms for secure distribution of product updates.
8. Ensure that security updates are disseminated promptly.
Where to start the path to compliance with the CRA?
The requirements and obligations of CRA are at a high level, serving as guidelines for goals and principles. In respect of details, the regulation relies on harmonized standards to be published later, with work still ongoing and results likely to be seen in 2026. The Commission is also expected to give further guidance concerning certain concepts and requirements of the CRA.
The development of harmonized standards utilizes proven procedures, best practices, and existing standards in the field. ENISA and JRC have published a comprehensive analysis of the correspondence between the CRA and certain cybersecurity standards.
This analysis includes standards such as ISO 27001 and IEC 62443-4-1. The standardization work can be followed on the website.
The connection between the requirements of the CRA and the frameworks for Secure Development Lifecycle (SDL) is strong. While awaiting harmonized standards and the Commission's guidance, the path to meeting the requirements of the CRA by following qualified and recognized SDL framework, such as NIST SSDF, IEC 62443-4-1 or OWASP SAMM, is likely already at a good, if not excellent, level.
-------
Insta's services seamlessly combine expertise in cybersecurity, SDL, and cyber security compliance. Insta's approach to secure application development is aligned with standards such as ISO 27001 and IEC 62443.
Read our case study:
Case Sandvik: Strengthening Cybersecurity to Support Competitiveness
Contact Us
