EU regulations and EU directives are two forms of legal acts in EU legislation. While directives must be transposed into national law by the member states, regulations are generally directly and immediately applicable in all member states.
The regulation is entitled “Regulation (EU) 2024/2847 of the European Parliament and of the Council of October 23, 2024, on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No. 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (cyber-resilience regulation) and can be downloaded directly from the EUR-Lex portal.
The regulation is divided into three sections. It begins with the recitals, followed by the actual text of the regulation and, finally, the annexes.
The recitals explain the background, objectives and considerations underlying the individual provisions of the regulation. They serve as a guide for the interpretation and application of the articles and annexes, but have no direct legal effect. However, they must be taken into account.
Two main problems that need to be addressed because they result in high costs for users and society (recital 1):
For providing false or incomplete information, for example, a fine of up to €5 million or 1% of annual turnover (Art. 64 para. 4). See also „What documentation do I have to create?”
For violating the manufacturer's obligations, for example, a fine of up to €15 million or 2.5% of annual turnover (Art. 64 para. 1).
The European Union (EU) and states of the European Economic Area (EEA).
The regulation provides for a phased approach until it must be complied with for all new products from December 11, 2027 (Art. 71 para. 2).
It is important to note that actively exploited vulnerabilities and serious security incidents must be reported as early as September 11, 2026 (Art. 71 para. 2).
No, as long as no significant change is made to the products already on the market (Art. 69 para. 2).
The European Commission will define the term “significant change” in more detail in a guideline (Art. 26 para. 1, 2d).
Until then, the CRA will help us by including it in various places, e.g.
“... has an impact on the conformity of the product with the essential cybersecurity requirements set out in Annex I Part I...“ (Art. 3 para. 30).
“... if the substantial modification has an overall impact on the cybersecurity of the product with digital elements...” (Art. 22 para. 2)
It follows that the effects of a change must be investigated. This is usually done by means of a risk assessment.
No, unless it is a customized product for a commercial user for which something else has been agreed (Annex I Part II para. 8).
The CRA applies to software and hardware products and their (associated) remote data processing solutions (Art. 2 para. 1). This includes pure software products and components (e.g. applications, operating systems), pure hardware products and components (e.g. microcontrollers) and combinations thereof (e.g. measuring devices, coffee machines).
“... the intended purpose or reasonably foreseeable use of which includes a direct or indirect logical or physical data link to a device or network.”
This affects all devices that can be connected directly or indirectly to other devices.
Yes. See above.
Yes. See above.
The entire product life cycle from development to operation to decommissioning (Art. 13 para. 2).
Cybersecurity must be guaranteed for the expected lifespan of the product, but for at least 5 years.
The CRA does not apply to (Art. 2 para. 2 – 8, Recital 12):
It depends on whether the cloud functions offered are device functions, e.g. remote control or remote configuration of devices. In this case, the cloud software is affected by the CRA (Considerations 11, 12).
The cloud platforms themselves are not covered by the CRA, as they are regulated by EU Directive 2022/2555 (NIS2).
In individual cases, the distinction between a service and a product with digital elements can be complex in the case of cloud services.
The CRA uses the definition in Article 2 (1) of Regulation (EU) 2019/881 (Art. 3 para. 3):
„‘cybersecurity’ means the activities necessary to protect network and information systems, the users of such systems, and other persons affected by cyber threats”
Art. 3 para. 1 - 51 defines the terms used in the CRA and how they are to be understood, e.g. software, hardware, components, placing on the market, etc.
The requirements depend on what type of economic operator I am. The CRA differentiates between manufacturers (Art. 13), importers (Art. 19), distributors (Art. 20) and open-source software stewards (Art. 24).
Importers and distributors automatically become manufacturers when they place products on the market under their own name or trademark or substantially modify them (Art. 21, 22).
The CRA distinguishes between four levels:
All assurance levels must comply with Annex I, i.e. all activities must always be carried out.
The difference between the assurance levels lies in the design of the product, which must guarantee a level of cybersecurity appropriate to the assurance level (Annex I Part I para. 1), and in the conformity assessment procedure (Annex VIII).
At present, there are no harmonized standards for the regulation. Harmonized standards are technical standards that are recognized by the EU Commission and enable a legally simplified conformity assessment.
Until such harmonized standards are published, manufacturers can fall back on established standards such as the IEC 62443 series of standards.
This is possible for products at the „Standard/Basic” security level (Art. 32 para. 1, Endnote 91). The associated procedure (Module A) is described in Annex VIII Part I and requires:
The manufacturer must ensure and declare on his own responsibility that the CRA is complied with. See also „Do I need processes for this? Why? Which ones?” and „What are the penalties for non-compliance with the CRA?”.
The proof of conformity depends on the safety level of the product.
All higher safety levels require the involvement of a notified body.
or
The central element of the CRA is the assessment of cybersecurity risks. This document is created at the beginning of product development and then regularly updated (Art. 13 para. 2, 3).
The product development (planning, design, development phase) must take into account the results of the risk analysis in order to minimize the cybersecurity risks, prevent security incidents and minimize the impact of security incidents.
The product must be designed, developed and manufactured in such a way as to ensure an appropriate level of cybersecurity in view of the risks.
The cybersecurity requirements (Annex I Part I) must be met. Among other things, the following are required:
The Technical Guideline TR-03183-1 of the BSI describes the state of the art in detail.
A software bill of materials (SBOM) is mandatory and must be provided in a machine-readable format (Annex I Part II para. 1). Possible formats are CycloneDX or SPDX.
Technical Guideline TR-03183-2 of the BSI describes the requirements for an SBOM in detail.
Annex I sets out the requirements for the manufacturers of a product that must be fulfilled throughout the entire lifespan of the product.
The cybersecurity risk assessment must be constantly updated during this phase (manufacturing, delivery and maintenance phase) (Part I Section 2).
No products with known exploitable vulnerabilities may be made available on the market. This is to be ensured by active measures (Part II, para. 3). A software BOM helps here (Part II, para. 1).
Once a vulnerability has been identified, it must be reported and closed immediately. A process must be in place and followed to ensure this (Part II, para. 5).
Security updates must be provided free of charge in a timely and secure manner, preferably separate from functional updates (Part II, sections 2, 7). The aim should be to update the software automatically and securely (Part II, section 7).
Third parties must be able to easily point out vulnerabilities in the product (Part II, Section 6). The security.txt quasi-standard, which is also recommended by the Federal Office for Cyber Security (BACS), is suitable for this purpose.
A detected vulnerability must be reported and closed immediately.
The report must include a description of the vulnerability with information that allows the user to identify the affected product, the impact of the vulnerability, and its severity.
A machine-readable report is desirable because manual evaluation is time-consuming. The Common Security Advisory Framework (CSAF) is a standardized and open-source framework for communicating and automatically distributing machine-processable vulnerability and mitigation information.
The technical guideline TR-03183-3 of the BSI and the associated guideline provide information on how to deal with vulnerability reports.
The documentation is divided into two parts:
The technical documentation must contain all relevant data or details of how the manufacturer ensures that the product complies with the CRA (Art. 31 para. 1).
The technical documentation must be complete and written in easily understandable language and made available to the market surveillance authorities upon request (Articles 53, 58). It must enable the market surveillance authorities to understand the design, development, manufacture and handling of vulnerabilities (Article 31 (2)).
The technical documentation shall include at least (Annex VII):
The documentation must be prepared before the product is placed on the market and updated throughout the entire life of the product (Art. 31 para. 2).
Chapter 6 of the Technical Guideline TR-03183-1 of the BSI goes into the documentation requirements in detail.
Projects? Ideas? Questions? Let's do a free initial workshop!
No Comments