After the adoption of the Cyber Resilience Act (CRA), more and more businesses are exploring what exactly they are facing and what requirements they have to comply with. The clock is ticking: By the end of 2027 all companies must meet the requirements of the CRA, while some requirements must be met as early as mid-2026.
The CRA introduces some completely new regulations and concepts. This is leading to some misunderstandings and several myths and rumours about the CRA are making the rounds. These rumors are often misleading or unnecessarily alarming. This is why we want to make you aware of, and refute some of the most prevalent myths. We hope this will reduce some uncertainties.
If you want to delve deeper into the individual articles of the CRA, you can download the “Requirements Analysis” (as .xlsx or as .odt) prepared by our CRA Task Force. Here you will find all articles and recitals of the CRA in German and English side by side. In addition, the spreadsheet gives you the possibility to filter the entire text of the CRA so you can focus on certain roles, actors or requirements.
Disclaimer: Our assessment of the different myths and our interpretation of the CRA is not legal advice.
Myth 1: Software developed in spare time also falls under the CRA.
No, the CRA introduces obligations for open source software stewards (Art. 24) and manufacturers of products with digital elements (Art. 13 & 14). These two categories come closest to legal or natural persons who develop software in their spare time and who must comply with the CRA. A spare time developer and therefore their software only fall under the CRA if the developer meets at least one of the definitions of one of these two categories.
Open Source Software Stewards
In order to qualify as an open source software steward, the following must be fulfilled (Art. 3(14)):
- It must be a legal person.
- It must not be a manufacturer.
- The legal person has the purpose or objective of developing open source software.
- The open source software developed is intended for commercial activities.
- The legal person pursues the sustained and systematic support of the open source software and ensures the viability of these products.
It is unclear whether a legal person must exclusively be a legal person or not. However, since the CRA repeatedly distinguishes between legal persons and natural persons (Art. 3 No.13, 15, 16, 17, 18), it can be assumed that this must be exclusively a legal person.
Manufacturer
In order to be considered a manufacturer in the sense of the CRA, the following must be fulfilled (Art. 3(13)):
- A natural or legal person who markets a product under their name or trademark.
- The product is distributed or used in the course of a commercial activity (Art. 3(22)).
Therefore, as long as hobby developers don’t publish their software within an association or a foundation with the aim of providing it for commercial purposes or within the scope of a business activity, their software is not affected by the CRA.
Myth 2: Small and medium-sized enterprises (SMEs) do not need to comply with the CRA.
The CRA is intended to ensure the long term safety of products with digital elements. As such, the CRA is generally applicable and therefore, small and medium-sized enterprises (SMEs) must comply with the CRA as well. However the CRA has some simplifying provisions for SMEs, including:
- Support from a helpdesk for reporting obligations (Art. 17(6)).
- A margin of discretion regarding fines and fees for SMEs (Art. 64(5)(c) and Art. 32(6)).
- Proportionality in the conformity assessments both with regard to the scope of the requirements (Art. 47(2)) and also with regard to fees for SMEs (Art. 39(12)).
- A simplified format for the required technical documentation specifically for small and microenterprises (Art. 33(5)).
- Potential financial support under existing Union programmes (Art. 33(4)).
- Guidance on the implementation of the Regulation (Art. 26(1) and Art. 33(3)).
- Depending on the Member States, training activities for the application of the CRA as a measure for small and microenterprises (Art. 33(1)(a)).
- Possible dedicated channels for communication with small and microenterprises and, as appropriate, local public authorities to provide advice and respond to queries about the implementation (Art. 33(1)(b)).
- Possible support for testing and conformity assessment activities (Art. 33(1)(c)).
- Possible access to controlled testing environments for innovative products with digital elements for small and microenterprises as well as start-ups (Art. 33(2)).
Some provisions are listed as “possible” or „potential“, the reason being that a number of implementation requirements are still being developed at the European level. This also applies to support programmes that the EU wants to offer. Hopefully, more information will be published in the coming years on the type of support that will be made available for SMEs.
Myth 3: Manufacturers can no longer use open source software.
The use of open source software continues to be allowed, but a certain amount of care is required from businesses: “Manufacturers shall exercise due diligence when integrating components from third parties”. It is up to the manufacturer to ensure that third-party components (including open source components) do not affect the cybersecurity of the product (Art. 13(5)). With regard to the security requirements on these components, voluntary security attestation programmes will be provided, which are intended to facilitate due diligence (Art. 25).
This requirement from the CRA therefore forces manufacturers to deal with their software supply chain. In the end, it is they who have to take responsibility for the product they bring to the market. This is also an opportunity as nowadays even large and high-revenue companies like to integrate open source components available free of charge, while not investing into the maintenance and security of these base components that they benefit so much from themselves. The CRA in effect causes more actors to take responsibility along the supply chain, including for the security of components they are using.
Myth 4: Vulnerabilities must be fixed within 7 days.
We were not able to find a 7-day deadline for fixing vulnerabilities in the CRA. However, the CRA requires that vulnerabilities be reported within a certain timeframe, and that the reaction shall be taken “without delay” once vulnerabilities have been found (Annex I Part II (2) and (8)). This „without delay“ reaction is required for adressing and remediating vulnerabilities (Annex I Part II (2)) as well as for disseminating security updates (Annex I Part II (8)). Taking all this into account when a new vulnerability is discovered, the following chain of activities has to start:
- A new vulnerability is discovered
- Working on a security update to address and remediate the vulnerability has to start without delay
- The security update for the new vulnerability is available
- The security update has to be disseminated without delay
In the context of German law, “without delay” means “without culpable delay”. The reporting deadlines vary depending on whether a vulnerability or a security incident at a manufacturer is concerned.
The reporting deadlines to the responsible market supervisory authority are:
- Without undue delay, but in any case within 24 hours of a manufacturer becoming aware of an actively exploited vulnerability or a severe security incident, the manufacturer has to submit an early warning notification to the CSIRT.
- Without undue delay, but in any case within 72 hours of becoming aware of an actively exploited vulnerability or a severe security incident, the manufacturer has to transmit relevant general information available.
- At the latest 14 days after a corrective or risk mitigation measure is available for an actively exploited vulnerability, the manufacturer must present a final report.
- For severe security incidents, the manufacturer must present a final report one month after the 72-hour notification.
Details regarding the type of information that must be transmitted at the respective times can be found in Article 14 of the CRA.
Myth 5: Technical documentation MUST be published.
Generally, the technical documentation remains with the manufacturer who also has to keep it up to date during the support period of the product, It does not have to be published. Only when a manufacturer of a “free and open source software” product classified as an important product with digital elements (Annex III) wants to demonstrate the conformity of their product with the standard conformity assessment instead of the usually required version for important products, they can do so by making their technical documentation publicly available (Art. 32(5)).
The technical documentation must be handed over at the request of a market surveillance authority (Art. 13 (13) and (22)), as well as in some conformity assessment procedures (Art. 53). Importers must make sure technical documentation has been drawn up for products they intend to place on the EU market (Art. 19(2)).
Myth 6: A Software Bill of Materials (SBOM) must be created and published.
An SBOM must be created in any case (Annex I Part II (1)) and this SBOM must be included in the technical documentation (Annex VII (2)(b) and (8)). However, there is no mention of a mandatory publication of the SBOM in the CRA. An SBOM can be published voluntarily (Annex II (9)), but there is no general requirement.
Since the SBOM is part of the technical documentation, on request, it must be handed over to market surveillance authorities (Art. 13 (22)), as well as in some conformity assessment procedures (Art. 53). Importers have to make sure it has been drawn up (Art. 19(2)). (See also Myth 5.)
Myth 7: Software Bills of Material (SBOMs) are insignificant.
SBOMs are mentioned as a necessary means of identifying and documenting vulnerabilities and components (Annex I Part II (1)). Regardless of the requirement to create one, the SBOM is a central tool to fulfill other requirements of the CRA using the data contained therein.
Myth 8: The CRA calls for “security by design.”
“Security by Design” does not occur as a term in the legal text of the CRA. However, the CRA demands that manufacturers ensure that the design, development, and production happens with essential cybersecurity requirements from Annex I Part 1 (1) in mind (Art. 13(1)). The CRA does however call for a “secure by default” configuration (Annex I Part 1 (2)(b)).
Although not all of the requirements commonly understood in connection with “security by design” are a requirement in the CRA, the CRA wants to ensure that IT security is taken into account already in the process of designing a product (Annex I Part I (1)).
Myth 9: The CRA has no exceptions.
The exceptions of the CRA are listed in Article 2. While not necessarily easy to read, they reference various existing EU Directives and Regulations.
Products that fall under the following Directives and Regulations do not have to follow the CRA, as they are already covered by other (possibly even stricter) sectoral regulation:
- Medical devices (Art. 2(2)(a)) according to EU Regulation 2017/745.
- In vitro diagnostics (Art. 2(2)(b)) according to EU Regulation 2017/746.
- Automotive industry (Art. 2(2)(c)) according to EU Regulation 2019/2144.
- Products certified according to the Civil Aviation Regulation 2018/1139 (Art. 2(3)).
- Shipping equipment according to Directive 2014/90/EU (Art. 2(4)).
Importantly, the exception only applies if a product falls within the scope of the corresponding Directive or Regulation. This must be examined carefully in case of doubt.
Please note that it has not yet been conclusively clarified whether the CRA might apply to products falling under one of the above-mentioned regulations that have the potential to also be used in a different context (dual-use).
