Quelltext der Seite Cyber Resilience Act (CRA)/en

<languages/>
{{Infobox Rechtsakt (EU)|Typ=Verordnung|Jahr=2024|Nummer=2847|Vertrag=EU|EWR=ja|Titel=Verordnung (EU) 2024/2847 des Europäischen Parlaments und des Rates vom 23. Oktober 2024 über horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen und zur Änderung der Verordnungen (EU) Nr. 168/2013 und (EU) 2019/1020 und der Richtlinie (EU) 2020/1828|Kurztitel=Cyber Resilience Act/Cyberresilienz-Verordnung|Bezeichnung=CRA|Rechtsmaterie=Binnenmarkt, Cybersicherheit|Grundlage=AEUV, insbesondere {{Art.|114|AEUV|dejure|}}
|Source=OJ L 2024/2847, 1|To apply=11 December 2027 (with exceptions)|In force=entry into force}}

<span id="Kurzübersicht"></span>
== Summary ==

```wiki
{| class="wikitable"
!Goals
!Scope
!Content<ref>https://www.nis.gv.at/nis-2-richtlinie.html</ref>
!Synergy
!Consequences
|-
|Contain vulnerabilities in products.
|Material: Products with digital elements (hardware or software products) whose use includes data connection with a device or network
|Appropriate security level of products, absence of known vulnerabilities
|
|Violation of Art 13 and 14 CRA; up to €15,000,000 or up to 2.5% of the worldwide annual turnover of the previous year.
|-
|Ensure security throughout the entire lifecycle of a product.
|Personal: Manufacturers, dealers, and importers
|Restoration to factory condition must (generally) be possible.
|Security of processing (Art 32 GDPR), data protection by design and by default (Art 25 GDPR)
|Violation of other obligations; up to €10,000,000 or 2% of the worldwide annual turnover of the previous year.
|-
|Create conditions enabling users to consider cybersecurity.
|
|Security assessments depending on security class
|Requirements of the AI Regulation (Art 6 in conjunction with 15) for high-risk AI systems
|Incomplete information; up to €5,000,000 or 1% of the previous year's turnover
|-
|
|
|
|
|
|}
```

<span id="Einführung"></span>
== Introduction ==

The Cyber Resilience Act (CRA) aims to increase cybersecurity by establishing uniform cybersecurity requirements for products with digital elements, especially hardware and software. The CRA mandates that in the future, '''all connected products''' must bear the '''CE marking'''. The CE marking externally signals that the connected product provides adequate protection against cyber threats.<ref>[https://www.bmi.bund.de/SharedDocs/pressemitteilungen/DE/2024/10/cyber-resilience-act.html](https://www.bmi.bund.de/SharedDocs/pressemitteilungen/DE/2024/10/cyber-resilience-act.html)</ref> 

Manufacturers, dealers, and importers are required to transparently demonstrate to their customers how secure their products are, disclose vulnerabilities, and ensure that these are remedied. Furthermore, the aforementioned actors must guarantee that their products remain secure against cyberattacks throughout their entire lifecycle.

<span id="Anwendungsbereich"></span>
== Scope ==

<span id="Sachlicher_Anwendungsbereich"></span>
==== Material Scope ====

The regulation applies to products with digital elements (hardware or software products, and their remote data processing solutions, which are marketed separately) whose intended or reasonably foreseeable use includes a direct or indirect logical or physical data connection with a device or network. 

Physical data connections are those established between electronic information systems or components and are physically or visually tangible. 

Logical connections are virtual representations of a data connection established via a software interface.

<span id="Ausnahmen_(Art_1_CRA):"></span>
====== Exceptions (Art 1 CRA): ======

# Products subject to sector-specific regulations: medical devices | in vitro diagnostics | motor vehicles | civil aviation | ship equipment

# Basically, wherever sectoral rules require an equivalent or higher standard.

# Identical spare parts

# Products intended for national security or defense purposes, or products specifically designed for handling classified information.

'''Examples:''' Connected refrigerators or thermostats, laptops, smartphones, tablets, smartwatches

<span id="Spezialfall_Open_Source_Software"></span>
====== Special Case Open Source Software ======

Free and open-source software products ("Open Source") developed or provided outside of commercial activities are not subject to the regulation.<ref>Recital 18 CRA-E: Finally, for the purposes of this Regulation, the development of products with digital elements qualifying as '''free and open-source software by not-for-profit organisations should not be considered to be a commercial activity provided that the organisation is set up in such a way that ensures that all earnings after costs are used to achieve not-for-profit objectives'''. This Regulation does not apply to natural or legal persons who contribute source code to products with digital elements qualifying as free and open-source software that are not under their responsibility </ref> An explicit exemption was not included; the exemption is implicit in the definition of "commercial activity" and is further clarified in Recital 18 CRA.

Products containing open-source components that fall within the scope of the CRA are subject to the CRA as a whole — including the embedded open-source components.

<span id="Persönlicher_Anwendungsbereich"></span>
==== Personal Scope ====

The affected actors are primarily manufacturers, dealers, importers of products with digital elements, as well as open-source stewards.

'''Manufacturer''' means any person who develops, manufactures, or designs products with digital elements, commissions their manufacture and development, and markets those products under their own name or trademark, either free of charge or commercially (Art 3 No. 13 CRA).

'''Distributor''' means any person in the supply chain who makes a product with digital elements available on the Union market without modifying the product’s characteristics. Manufacturers and importers are excluded (Art 3 No. 17 CRA).

'''Importer''' means any person who places a product with digital elements on the Union market for the first time on behalf of a person, organization, or authority located outside the Union (Art 3 No. 16 CRA).

'''Open-source steward''' means a legal entity that is not a manufacturer, whose purpose or objective is to systematically and sustainably support the development of specific products with digital elements classified as free and open-source software intended for commercial activities, and that ensures the marketability of these products (Art 3 No. 14 CRA). 

The definition allows only limited classification based on objective criteria by external parties. Thus, qualification will likely depend on whether the legal entity internally adopts an open-source stewardship role for a product. According to Art 25, the Commission may issue security certifications for open-source software through delegated acts; as of October 2024, no details are known. Art 9 CRA provides that the "Open Source Community" must be consulted by the Commission as a stakeholder during the implementation of the regulation. Therefore, besides the economic benefits of stewardship, concrete opportunities for shaping the framework are also guaranteed.

Examples of this include:

* Foundations that support specific open-source projects
* Companies that develop open-source for their own use but make it publicly accessible
* Non-profit organizations that develop open-source software

<span id="Territorialer_Anwendungsbereich"></span>
==== Territorial Scope ====

The subject of the regulation is the placing of a product with digital elements on the Union market.

<span id="Wesentliche_Pflichten:"></span>
== Key Obligations: ==

<span id="Hersteller"></span>
==== Manufacturer ====

According to Art 13(1), manufacturers must ensure that the characteristics of their hardware and software products meet '''minimum security requirements''' during design, development, and manufacture. Annex I Part I is relevant here, aiming to establish an appropriate level of security.

According to Art 13(8), manufacturers must ensure, when placing a product with digital elements on the market and throughout the support period, that '''vulnerabilities''' of the product, including its components, are effectively addressed in accordance with the fundamental requirements set out in Annex I Part II.

According to Art 13(18), the '''information''' specified in Annex II must be provided.

Art 14 establishes various '''reporting obligations''' for manufacturers of hardware and software products. Actively exploited vulnerabilities must be reported to the European Union Agency for Cybersecurity (ENISA): 

* Early warning within 24 hours
* Notification within 72 hours
* Final report within 14 days after remediation of the vulnerability

Art 23 requires maintaining comprehensive '''technical documentation'''. This documentation must include not only a general description of the product and its intended use but also detailed information on product design, development, and manufacturing aspects. Additionally, a thorough assessment of cybersecurity risks throughout the product’s entire lifecycle is required. Another key part of the documentation is the description of procedures for '''vulnerability handling'''. This includes information on the product’s design and development, which may be supplemented by diagrams, schematics, or a description of the system architecture. Furthermore, a concept for coordinated vulnerability disclosure, as well as specifications for manufacturing and monitoring processes including validation, must be documented. 

<span id="Händler"></span>
==== Distributor ====

Before making a hardware or software product available on the EU market, distributors must ensure according to Art 19 CRA: 

* that the product is properly marked with the CE marking
* that the EU declaration of conformity is available
* that the minimum information from the manufacturer or importer is provided
* that comprehensive instructions for users are available

If a '''significant cybersecurity risk''' arises due to a vulnerability, distributors must immediately notify the market surveillance authorities of the Member States where they distribute the product.

If it becomes known that a manufacturer is '''ceasing operations''', distributors must inform the competent market surveillance authorities accordingly.

<span id="Importeur"></span>
==== Importer ====

Importers must actively ensure before placing a product on the market that:

* The manufacturer has conducted a conformity assessment
* The required technical documentation is available
* The product bears the CE marking
* An instruction manual and relevant information are included

Importers must indicate their name, registered trade name or registered trademark, and contact address on the product or its packaging.

If a significant cybersecurity risk arises due to a vulnerability, importers must immediately notify the market surveillance authorities of the Member States where they distribute the product.

<span id="Open-Source_Steward_(Verwalter_quelloffener_Software)"></span>
==== Open-Source Steward ====

Open source software stewards are intended to be subject to a tailored and lighter regulation than traditional commercial manufacturers (Recital 19 CRA). They are not allowed to independently affix the CE marking on products with digital elements whose development they support (Recital 20 CRA).

Art 24 CRA sets out the following obligations:

* Implement a documented cybersecurity policy that promotes the secure development of products, handling, documentation, management and remediation of security vulnerabilities, and the exchange of information about discovered vulnerabilities within the open-source community (Art. 24(1) CRA)
* Cooperate with market surveillance authorities upon request to mitigate cybersecurity risks and provide the cybersecurity policy upon justified request (Art. 24(2) CRA)

The reporting obligations under Art 14(1) CRA apply insofar as open-source stewards are involved in the development of products with digital elements. The reporting obligations under Art 14(3) and (8) CRA apply as far as network and information systems used for the development of such products are concerned.

<span id="Kategorisierung_von_Produkten_und_Pflichten"></span>
== Categorization of Products and Obligations ==

[[Datei:CRA Zertifizierungen ri.png|mini|Certification scheme of the Cyber Resilience Act - CC BY 4.0]]
The CRA distinguishes between the “standard category,” important products Class I and Class II, as well as critical products.

<span id="Standardkategorie_(Art._2_CRA)"></span>
==== Standard Category (Art. 2 CRA) ====

Certification scheme:

* For standard products, the manufacturer of hardware and software products can perform the conformity assessment themselves based on an internal control procedure according to Module A.
* Alternatively, the certification schemes of Modules B+C, or Module H can also be carried out voluntarily (Art 21 Para 1 CRA)

<span id="Wichtige_Produkte_Klasse_I_(Art_7_CRA_iVm_Annex_III_Class_I)"></span>
==== Important Products Class I (Art 7 CRA in conjunction with Annex III Class I) ====

Examples:
* Password managers
* Identity and access management systems
* Products with digital elements that have a VPN function
* Browsers
* Antivirus programs
* SIEM tools (Security Information and Event Management)
* Public key infrastructure and issuers of digital certificates
* Microprocessors with security-relevant functionalities (CPUs)
* Microcontrollers with security-relevant functionalities (MCUs)
Certification scheme:

* Harmonized EU certification standards can be applied to products of this class (Art 32 Para 3 lit c in conjunction with Art 27 Para 9 CRA). Although Art 27 Para 9 CRA eliminates the manufacturer's obligation to conduct a conformity assessment by a third party when applying the EU certification standard assurance level "substantial", this certification level provides for third-party review (cf. Art 53 Cybersecurity Act).
* If these are not available, independent certification according to Module B+C or Module H must be carried out (Art 32 Para 2 lit a and b in conjunction with Art 27 Para 9 CRA).

<span id="Wichtige_Produkte_Klasse_II_(Art_7_CRA_iVm_Annex_III_Class_II)"></span>
==== Important Products Class II (Art 7 CRA in conjunction with Annex III Class II) ====

Examples:
* Firewalls
* Hypervisor / container virtualization systems
* Tamper-resistant microprocessors (CPUs)
* Tamper-resistant microcontrollers (MCUs)
Certification scheme:

* Harmonized EU certification standards can be applied to products of this class (Art 32 Para 3 lit c in conjunction with Art 27 Para 9 CRA). Following Recital 92 CRA, a third party should always be involved in the conformity assessment of important products of Class II. Although Art 27 Para 9 CRA eliminates the manufacturer's obligation to conduct a conformity assessment by a third party when applying the EU certification standard assurance level "substantial", this certification level provides for third-party review (cf. Art 53 Cybersecurity Act).
* In any case, independent certification according to Module B+C or Module H must be carried out (Art 32 Para 3 lit a and b in conjunction with Art 27 Para 9 CRA).

<span id="Kritische_Produkte_(Art_8_CRA_iVm_Annex_III_iVm_Annex_IV)"></span>
==== Critical Products (Art 8 CRA in conjunction with Annex III in conjunction with Annex IV) ====

Examples:

# Hardware Security Modules (HSMs)
# Smart Meters
# Smart cards

<div lang="de" dir="ltr" class="mw-content-ltr">
Zertifizierungsschema:
</div>

* Where specified by the EU Commission in accordance with Art 8 Para 1 CRA, harmonized EU certification standards can be applied to products of this class (Art 32 Para 4 lit a in conjunction with Art 8 Para 1 CRA)
* If these are not available, independent certification according to harmonized EU certification standards, Module B+C or Module H, must take place (Art 32 Para 4 lit b in conjunction with Art 32 Para 3 CRA)

<span id="Synergien"></span>
== Synergies ==

<span id="Artificial_Intelligence_Act_(KI_Verordnung)"></span>
====== [[Special:MyLanguage/Artificial Intelligence Act (AIA)|Artificial Intelligence Act (AI Act)]] ======

* For high-risk AI systems that also fall under the CRA, there is a specific provision: The cybersecurity requirements of Article 15 AI Act are considered fulfilled if all CRA requirements are met and to the extent they are covered by the conformity assessment procedure. Conformity is only certified in accordance with Article 12(1)(c) CRA to the extent that the requirements of the conformity procedure cover those of Article 15 AI Act. Where this is the case, it must be assessed individually.

<span id="DSGVO"></span>
====== GDPR ======

* Both Article 32 GDPR and Article 13 CRA follow a risk-based approach. The measures to be taken should be appropriate to the risk and consider various factors. Annex I(1) CRA requires an adequate level of security. This also applies to Article 32 GDPR, which, unlike Annex I(1) CRA, explicitly mentions that implementation costs must also be considered.

<span id="Konsequenzen/Strafen"></span>
== Consequences/Penalties ==

According to Article 52(1) CRA, Member States must lay down rules on penalties applicable to economic operators for infringements of the Regulation and take all measures necessary to ensure their enforcement.

The level of '''fines''' is specified in Article 64(2)–(5) CRA. For non-compliance with the requirements in Annex I or breaches of the manufacturer's obligations under Articles 13 and 14 CRA, fines of up to €15,000,000 or up to 2.5% of the total worldwide annual turnover may be imposed.

For infringements of other obligations under the CRA, fines of up to €10,000,000 or up to 2% of the total worldwide annual turnover may be imposed.

Providing incorrect, incomplete or misleading information to notified bodies and market surveillance authorities in response to a request is punishable by fines of up to €5,000,000 or up to 1% of the total worldwide annual turnover.

Oversight of open-source stewards lies with the market surveillance authorities pursuant to Article 52(3) CRA; according to Article 64(10)(b) CRA, they cannot impose fines.

<span id="Weiterführende_Literatur"></span>
== Further Reading ==

<span id="Überblicksartikel"></span>
=== Overview Articles ===

<div lang="de" dir="ltr" class="mw-content-ltr">
*''Erdelt'', Meldepflichten des Cyber Resilience Acts, ZfPC 2024, 176.
* ''Piltz/Weiß/Zwerschke'', Der Vorschlag für einen Cyber Resilience Act aus Sicht der DSGVO, CR 2023, 289.
* ''Poncza'', Der Entwurf des Cyber Resilience Act, ZfPC 2023, 44.
* ''Ruttloff/Wagner/Stilz'', Der Entwurf des Cyber Resilience Act (CRA) und seine Auswirkungen auf das Gewährleistungs- und Produkthaftungsrecht, BB 2024, 1603.
* ''Schöttle'', Cyber Resilience Act, Produkthaftungsrichtlinie und andere Baustellen für die Open Source Communities, ZfPC 2023, 215.
* ''Siglmüller'', Cyber Resilience Act und Digital Operational Resilience Act. Lässt sich IT-Sicherheit rechtlich erzwingen? ZfPC 2023, 221.
* ''Voigt/Falk'', Der Cyber Resilience Act, MMR 2023, 88.
* ''Wiebe/Daelen'', Der Cyber Resilience Act aus produktsicherheitsrechtlicher Perspektive, EuZW 2023, 257.
* ''Zußner'', Das Inverkehrbringen von Produkten mit digitalen Elementen nach dem Vorschlag der EU-Kommission für eine Verordnung über horizontale Cybersicherheitsanforderungen, ALJ 2022, 180.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
=== Kommentare ===
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
* ''Heckmann/Paschke'', CRA. Cyber Resilience Act (2025, iE).
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
== Einzelnachweise ==
</div>