Time to Read 6 min
The entry into force of the Cyber Resilience Act (CRA) means that almost no electronic product can be developed without taking cybersecurity into account, without a dam to the internet.
What does this mean for you? We have compiled here general informationon various aspects of CRA . Please feel free to contact me if you have any further questions.
For information specific to developers, see CRA for Development.
Beide Abkürzungen bedeuten dasselbe. CRA steht für den englischen Begriff «Cyber Resilience Act» und CRV für den deutschen Begriff «Cyberresilienz-Verordnung».
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.
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 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 entire product life cycle from development to operation to decommissioning (Art. 13 para. 2).
No, unless it is a customized product for a commercial user for which something else has been agreed (Annex I Part II para. 8).
Cybersecurity must be guaranteed for the expected lifespan of the product, but for at least 5 years.
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).
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.

is Dipl. Elektroingenieur FH , co-founder, deputy managing director and software developer. He is a specialist for architectures and software in C, C++ and C#. He is committed to maintainable architecture, security and clean code. For this he likes to look beyond the "embedded" edge of his nose into other areas of software development. He is interested in overall systems of any kind and their interrelationships. Alois manages a 5'000 m2 biodiversity island and brings nature, horses and humans in harmony. He loves good (movie) stories and good food.
Projects? Ideas? Questions? Let's do a free initial workshop!
No Comments