Cyber Resilience Act: Anforderungen & wer betroffen ist

Was fordert der Cyber Resilience Act konkret? Ein Überblick

Der Cyber Resilience Act (CRA) verpflichtet Hersteller, Cybersicherheit von der Produktentwicklung bis zum Support-Ende einzuplanen. Die EU-Verordnung trat am 10.12.2024 in Kraft und gilt in vollem Umfang ab dem 11.12.2027. Betroffen sind alle Produkte mit digitalen Elementen – also Hardware und Software, die eine Datenverbindung zu einem Gerät oder Netzwerk aufbauen können.

Der CRA verfolgt drei zentrale Ziele. Erstens: Produkte sollen von Anfang an sicher entwickelt werden ("Security by Design"). Zweitens: Schwachstellen müssen während des gesamten Produktlebenszyklus verwaltet werden. Drittens: Nutzer sollen transparente Informationen zur Sicherheit eines Produkts erhalten, bevor sie es kaufen.

Der CRA ist die erste EU-weite Verordnung, die verbindliche Cybersicherheitsanforderungen generell für Produkte mit digitalen Elementen festlegt. Vorher gab es für die meisten vernetzten Produkte keine einheitlichen gesetzlichen Mindeststandards. Das ändert sich nun grundlegend für Hersteller, Importeure und Händler in der gesamten EU.

Die Sicherheitsanforderungen aus Annex I – was Hersteller umsetzen müssen

Annex I des CRA legt die grundlegenden Sicherheitsanforderungen fest, die jedes betroffene Produkt erfüllen muss. Der Anhang gliedert sich in zwei Teile: Anforderungen an die Produkteigenschaften selbst und Anforderungen an das Schwachstellenmanagement.

Annex I Part I definiert folgende Kernanforderungen (Verordnung (EU) 2024/2847, Annex I):

Keine bekannten ausnutzbaren Schwachstellen

Produkte müssen ohne bekannte Sicherheitslücken ausgeliefert werden.

Sichere Standardkonfiguration (Secure by Default)

Ab Werk muss die sicherste Konfiguration aktiv sein – ohne manuelle Einrichtung durch den Nutzer.

Schutz vor unautorisiertem Zugriff

Geeignete Authentifizierungs- und Zugriffskontrollmechanismen sind Pflicht.

Vertraulichkeit der Daten

Gespeicherte, übertragene und verarbeitete Daten müssen durch aktuelle Verschlüsselung geschützt werden.

Integrität von Daten und Konfigurationen

Unautorisierte Manipulationen an Daten, Befehlen und Einstellungen müssen erkannt und verhindert werden.

Datensparsamkeit

Es dürfen nur die Daten verarbeitet werden, die für den vorgesehenen Zweck notwendig sind.

Verfügbarkeit wesentlicher Funktionen

Auch nach einem Sicherheitsvorfall müssen Kernfunktionen erhalten bleiben – Resilienz gegen Denial-of-Service-Angriffe ist einzuplanen.

Minimierung der Angriffsfläche

Nicht benötigte Schnittstellen, Dienste und Funktionen sind zu deaktivieren.

Sicherheitsupdates getrennt von Funktionsupdates

Updates müssen separat installierbar sein, damit Sicherheitspatches nicht von Funktionsupdates abhängig sind.

Transparenz über Komponenten

Hersteller müssen die im Produkt enthaltenen Softwarekomponenten dokumentieren und bekannte Schwachstellen darin offenlegen.

Der CRA sieht dabei vor, diese Anforderungen bereits von Beginn der Entwicklung an einzuplanen (Security by Design). Nachträgliche Anpassungen z.B. der Produktarchitektur sind zudem in der Praxis deutlich aufwendiger und teurer.

Vulnerability Handling und SBOM: Was der CRA zur Schwachstellenverwaltung verlangt

Der zweite Teil von Annex I regelt das Schwachstellenmanagement über den gesamten Produktlebenszyklus. Hersteller müssen ein Verfahren zur Identifikation und Dokumentation von Schwachstellen etablieren – auch für Komponenten von Drittanbietern.

Ein zentrales Element ist die SBOM (Software Bill of Materials). Das ist ein maschinenlesbares Verzeichnis aller Softwarekomponenten, aus denen sich ein Produkt zusammensetzt. Die SBOM soll mindestens die oberste Komponentenebene und ihre direkten Abhängigkeiten abbilden.

Zusätzlich verlangt der CRA einen koordinierten Umgang mit gemeldeten Schwachstellen. Hersteller müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle innerhalb von 24 Stunden an die zuständige Behörde melden. Diese Meldepflicht gilt ab dem 11.09.2026, also noch vor der vollständigen Geltung des CRA.

Sicherheitsupdates müssen kostenlos bereitgestellt werden, solange der Support-Zeitraum des Produkts läuft. Dieser Zeitraum muss mindestens fünf Jahre betragen, sofern die erwartete Nutzungsdauer des Produkts nicht kürzer ist.

Für wen gilt der Cyber Resilience Act? Anwendungsbereich im Detail

Der CRA gilt für alle Produkte mit digitalen Elementen, die in der EU auf den Markt gebracht werden – unabhängig vom Sitz des Herstellers. Ausgenommen ist nicht-kommerzielle Open-Source Software oder Produkte, für die strengere Gesetze und Regularien gelten, wie zum Beispiel die Bereiche Luftfahrt oder Medizin. Damit ist der räumliche Anwendungsbereich deutlich weiter gefasst als bei vielen anderen EU-Regulierungen. Entscheidend ist nicht der Firmensitz, sondern der EU-Markt als Zielmarkt.

Der CRA regelt zwei Dinge klar: welche Produkte unter den CRA fallen und welche Rolle mit welchen Pflichten einhergeht. Diese Trennung ist wichtig, weil Unternehmen oft mehrere Rollen gleichzeitig einnehmen. Ein Unternehmen kann etwa gleichzeitig Hersteller eigener Produkte und Importeur fremder Komponenten sein.

Produkte mit digitalen Elementen: Was fällt unter den CRA?

Produkte mit digitalen Elementen sind laut CRA Hardware- oder Softwareprodukte, deren bestimmungsgemäße Verwendung eine direkte oder indirekte logische oder physische Datenverbindung zu einem Gerät oder Netzwerk einschließt. Diese Definition ist bewusst breit gefasst.

Darunter fallen zum Beispiel Router, Smart-Home-Geräte, Betriebssysteme, Firewalls, Passwortmanager und industrielle Steuerungssysteme. Auch reine Softwareprodukte wie Antivirenprogramme oder VPN-Clients zählen dazu, sofern sie eigenständig vertrieben werden.

Entscheidend ist allein die technische Möglichkeit einer Datenverbindung. ENISA definiert diese Verbindung als jede Form des Datenaustauschs, die über eine reine physische Stromversorgung hinausgeht.

Hersteller, Importeure, Händler: Wer trägt welche Pflichten?

Der CRA verteilt Pflichten entlang der gesamten Lieferkette. Hersteller tragen die umfangreichsten Verpflichtungen, weil sie über Produktdesign und -entwicklung entscheiden. Importeure und Händler haben abgeleitete, aber eigenständige Prüfpflichten.

Rolle	Kernpflichten
Hersteller	Sicherheitsanforderungen nach Annex I umsetzen, Konformitätsbewertung durchführen, technische Dokumentation erstellen, CE-Kennzeichnung anbringen, Schwachstellen melden, Sicherheitsupdates bereitstellen
Importeur	Prüfen, ob Hersteller Konformitätsbewertung und CE-Kennzeichnung korrekt durchgeführt hat, eigenen Namen und Kontaktdaten am Produkt angeben, bei Zweifeln Markteinführung stoppen
Händler	Prüfen, ob CE-Kennzeichnung und Begleitdokumente vorhanden sind, Produkte bei bekannten Konformitätsmängeln nicht weiter vertreiben, Behörden bei Verdachtsfällen informieren

Wichtig für die Praxis:

Ein Importeur oder Händler kann unter bestimmten Bedingungen selbst zum Hersteller werden. Das passiert etwa, wenn er ein Produkt unter eigenem Namen vermarktet oder wesentliche Änderungen daran vornimmt. In diesem Fall gelten für ihn die vollen Herstellerpflichten.

Was ist ausdrücklich ausgenommen? (Open Source, SaaS, Medical Devices, Automotive)

Der CRA nimmt bestimmte Produktkategorien ausdrücklich aus seinem Anwendungsbereich aus, weil diese bereits durch andere Regelwerke abgedeckt sind. Diese Ausnahmen verhindern doppelte Regulierung für dieselben Risiken.

Nicht-kommerzielle Open-Source-Software ist weitgehend ausgenommen, sofern sie außerhalb einer geschäftlichen Tätigkeit entwickelt wird. Reine Cloud-Dienste ohne eigenständige Softwarekomponente fallen grundsätzlich nicht unter den CRA. Medizinprodukte unterliegen primär der MDR beziehungsweise IVDR. Kraftfahrzeuge sind durch die UN-R155-Regelung und die EU-Typgenehmigungsverordnung weitgehend abgedeckt.

Diese Ausnahmen bedeuten nicht automatisch vollständige Regulierungsfreiheit. In vielen Fällen bestehen Überschneidungen, die im Einzelfall geprüft werden müssen. Die folgenden Abschnitte gehen auf Software, IoT, Automotive und Medizinprodukte im Detail ein.

Kritische und wichtige Produkte: Die Risikoklassen des CRA

Der CRA teilt Produkte in vier Risikoklassen ein: Default-Kategorie, Important Class I, Important Class II und Critical. Die Einstufung bestimmt, welches Konformitätsbewertungsverfahren ein Hersteller durchlaufen muss. Je höher das Risiko, desto strenger die Prüfanforderungen.

Grundlage für die Einstufung ist die Funktion eines Produkts und das potenzielle Schadensausmaß bei einer Sicherheitslücke. Ein Passwortmanager etwa birgt ein höheres Risiko als ein einfaches Smart-Home-Thermostat, weil er sensible Zugangsdaten verwaltet.

Default-Kategorie: Die meisten Produkte

Die Default-Kategorie umfasst laut EUR-Lex (2024) rund 90 Prozent aller vom CRA erfassten Produkte. Hersteller dieser Produkte dürfen die Konformität grundsätzlich selbst bewerten – ohne externe Prüfstelle.

Typische Beispiele sind einfache Smart-Home-Geräte, Spielzeug mit digitalen Funktionen oder Standard-Bürosoftware. Für diese Produkte gelten die Anforderungen aus Annex I in vollem Umfang. Der Prüfaufwand bleibt jedoch überschaubar, solange keine Anzeichen erhöhten Risikos vorliegen.

Important Products (Class I & II): Erhöhte Anforderungen

Important Products sind Produkte, deren Ausfall oder Kompromittierung größere Auswirkungen haben kann als bei Default-Produkten. Der CRA unterteilt diese Kategorie in zwei Stufen mit unterschiedlicher Prüftiefe.

Class I umfasst Produkte wie Browser, Firewalls, Passwortmanager und VPN-Software. Für sie reicht meist weiterhin die Selbstbewertung, sofern harmonisierte Normen angewendet werden. Ohne solche Normen ist eine Drittprüfung erforderlich.

Class II geht einen Schritt weiter und betrifft etwa Betriebssysteme sowie Industrieautomation für kritische Infrastrukturen. Hier ist grundsätzlich eine Prüfung durch eine benannte Stelle notwendig, unabhängig davon, ob harmonisierte Normen vorliegen.

Critical Products: Strengste Auflagen

Critical Products unterliegen den strengsten Anforderungen des gesamten CRA. Dazu zählen Smart Meter Gateways und Chipkarten mit sicherheitsrelevanten Funktionen. Für diese Produkte ist eine Zertifizierung nach einem europäischen Schema zur Cybersicherheit vorgesehen.

Die folgende Tabelle fasst die vier Risikoklassen zusammen:

Risikoklasse	Anteil / Beispiele	Konformitätsbewertung
Default	ca. 90 % aller Produkte; einfache Smart-Home-Geräte, Standardsoftware	Selbstbewertung durch Hersteller
Important Class I	Browser, Firewalls, Passwortmanager	Selbstbewertung bei Anwendung harmonisierter Normen, sonst Drittprüfung
Important Class II	Betriebssysteme, Industrieautomation für kritische Infrastruktur	Prüfung durch benannte Stelle verpflichtend
Critical	Smart Meter Gateways, Chipkarten	Zertifizierung nach europäischem Cybersicherheitsschema

CRA und Software: Gilt der Act auch für SaaS und Open-Source-Produkte?

Der CRA erfasst Software grundsätzlich dann, wenn sie eigenständig auf den Markt gebracht wird und eine Datenverbindung ermöglicht. Reine Cloud-Dienste ohne eigenständige Softwarekomponente sind davon meist ausgenommen. Die Abgrenzung im Einzelfall ist jedoch nicht immer eindeutig.

Wann ist Software vom CRA betroffen – und wann nicht?

Software fällt unter den CRA, wenn sie als eigenständiges Produkt vertrieben wird – etwa als Download, Lizenz oder vorinstallierte Anwendung. Entscheidend ist, dass ein Hersteller die Software eigenständig in Verkehr bringt und damit die Verantwortung für ihre Sicherheit trägt.

Software, die lediglich als Teil eines internen Betriebs verwendet wird und nicht auf den Markt gebracht wird, fällt nicht unter den CRA. Auch Software, die ausschließlich als Bestandteil eines bereits regulierten Produkts existiert, wird in der Regel über das Hauptprodukt abgedeckt statt separat bewertet.

Open-Source-Software unter dem CRA: Ausnahmen und Pflichten

Nicht-kommerzielle Open-Source-Software ist vom CRA weitgehend ausgenommen. Das gilt, solange sie außerhalb einer geschäftlichen Tätigkeit entwickelt und bereitgestellt wird. Sobald ein Unternehmen Open-Source-Komponenten kommerziell in ein Produkt integriert, greifen die CRA-Pflichten für dieses Produkt.

Der CRA führt zudem eine eigene Kategorie für Open-Source-Steward ein. Das sind Organisationen, die die Entwicklung bestimmter Open-Source-Software unterstützen, ohne selbst kommerzielle Hersteller zu sein. Für sie gilt ein eigenes, leichteres Pflichtenregime.

Laut Art. 64 Abs. 10 CRA sind Open-Source-Stewards ausdrücklich von Bußgeldern befreit. Sie müssen dennoch angemessene Cybersicherheitspraktiken einhalten und bei Schwachstellen kooperieren. Diese Regelung soll die Innovationskraft der Open-Source-Community erhalten, ohne Sicherheitsstandards komplett aufzugeben.

SaaS und Cloud-Dienste: Wo die Grenze liegt

Reine SaaS-Angebote ohne eigenständige, herunterladbare Softwarekomponente fallen grundsätzlich nicht unter den CRA. Der Grund: Der Anbieter behält die volle Kontrolle über die Infrastruktur und kann Sicherheitsupdates zentral einspielen, ohne dass Nutzer aktiv werden müssen.

Anders sieht es aus, wenn ein SaaS-Anbieter zusätzlich eine eigenständige Client-Software oder ein IoT-Gerät bereitstellt, das mit dem Cloud-Dienst verbunden ist. In diesem Fall unterliegt die Client-Komponente dem CRA, während der reine Cloud-Backend-Teil außen vor bleibt.

Diese Grenzziehung muss in der Praxis oft im Einzelfall geprüft werden. Unternehmen mit hybriden Angeboten aus Software und Cloud-Diensten sollten ihre Produktarchitektur genau analysieren, bevor sie den Anwendungsbereich des CRA für sich ausschließen.

Branchenspezifische Anwendung: IoT, Automotive und Medizinprodukte

Der CRA trifft je nach Branche auf unterschiedliche Ausgangslagen. In manchen Sektoren gilt er uneingeschränkt, in anderen überschneidet er sich mit bestehenden Regelwerken. Diese Überschneidungen bestimmen, wie viel zusätzlicher Aufwand tatsächlich entsteht.

CRA und IoT: Anforderungen für vernetzte Geräte

Vernetzte IoT-Geräte gehören zum Kernbereich des CRA, weil sie per Definition eine Datenverbindung besitzen. Smart-Home-Geräte, vernetzte Kameras und industrielle Sensoren müssen die vollständigen Anforderungen aus Annex I erfüllen.

Für die meisten IoT-Konsumgeräte gilt die Default-Kategorie mit Selbstbewertung. Geräte mit sicherheitskritischen Funktionen, etwa vernetzte Zugangskontrollsysteme, können jedoch in eine höhere Risikoklasse fallen. Hersteller sollten die Einstufung ihres Produkts frühzeitig prüfen.

Automotive: Wie verhält sich der CRA zu UN-R155 und TISAX?

Kraftfahrzeuge sind durch die UN-R155-Regelung zur Cybersicherheit von Fahrzeugen und die EU-Typgenehmigungsverordnung weitgehend vom CRA ausgenommen. Diese bestehenden Regelwerke decken bereits die zentralen Cybersicherheitsanforderungen für Fahrzeugtypen ab.

Die Ausnahme gilt jedoch nicht pauschal für alle Komponenten im Fahrzeugumfeld. Nachrüstprodukte, Zubehör oder eigenständige Softwareanwendungen für Fahrzeuge können weiterhin unter den CRA fallen, wenn sie nicht Teil der Fahrzeugtypgenehmigung sind. TISAX bleibt als branchenspezifischer Informationssicherheitsstandard davon unberührt und wirkt ergänzend.

Praxisbeispiel: Ein Hersteller von Fahrzeug-Diagnosegeräten, die per OBD-II-Schnittstelle mit dem Fahrzeug kommunizieren und per Smartphone-App steuerbar sind, fällt unter den CRA. Das Gerät ist kein Bestandteil der Fahrzeugtypgenehmigung – es wird eigenständig auf den Markt gebracht und besitzt eine Netzwerkverbindung. Die UN-R155-Ausnahme greift hier nicht.

Medizinprodukte: Zusammenspiel von CRA und MDR

Medizinprodukte fallen primär unter die Medical Device Regulation (MDR) beziehungsweise die In-vitro-Diagnostika-Verordnung (IVDR). Diese Verordnungen enthalten bereits eigene Anforderungen an Cybersicherheit, die auf den medizinischen Kontext zugeschnitten sind.

Überschneidungen mit dem CRA sind dennoch möglich, etwa bei digitalen Zubehörprodukten, die nicht selbst als Medizinprodukt zertifiziert sind. Hersteller sollten im Einzelfall prüfen, welches Regelwerk für welche Produktkomponente greift, um Doppelregulierung oder Regelungslücken zu vermeiden.

Praxisbeispiel: Eine Smartphone-App zur Auswertung von Blutzuckermesswerten, die Daten von einem MDR-regulierten Messgerät empfängt, selbst aber nicht als Medizinprodukt zertifiziert ist, kann unter den CRA fallen. Die App kommuniziert über eine Netzwerkverbindung mit dem Gerät und wird eigenständig im App Store vertrieben – damit erfüllt sie die Kriterien eines Produkts mit digitalen Elementen.

CE-Kennzeichnung und Zertifizierung nach dem Cyber Resilience Act

Produkte mit digitalen Elementen benötigen ab vollständiger Geltung des CRA eine CE-Kennzeichnung, die die Konformität mit den CRA-Anforderungen bestätigt. Diese Kennzeichnung ist bereits aus anderen EU-Produktverordnungen bekannt, erhält im CRA-Kontext aber eine erweiterte Bedeutung für Cybersicherheit.

Wann ist eine CE-Kennzeichnung nach CRA Pflicht?

Die CE-Kennzeichnung ist Pflicht für alle Produkte mit digitalen Elementen, die unter den Anwendungsbereich des CRA fallen und in der EU in Verkehr gebracht werden. Sie muss sichtbar, lesbar und dauerhaft am Produkt oder seiner Verpackung angebracht werden. Mit der Kennzeichnung erklärt der Hersteller, dass sein Produkt die Sicherheitsanforderungen aus Annex I erfüllt. Fehlt die CE-Kennzeichnung oder wird sie zu Unrecht angebracht, drohen Marktrücknahmen und Bußgelder. Die vollständige Pflicht greift ab dem 11.12.2027.

Harmonisierte Standards: Welche Normen gelten für die Konformitätsbewertung?

Harmonisierte Normen sind europäische technische Standards, deren Einhaltung eine Vermutungswirkung für die Erfüllung gesetzlicher Anforderungen erzeugt. Wendet ein Hersteller eine harmonisierte Norm korrekt an, gilt die entsprechende CRA-Anforderung als erfüllt. Die europäischen Normungsorganisationen CEN, CENELEC und ETSI erarbeiten diese Normen derzeit im Auftrag der EU-Kommission. Bis zur vollständigen Verfügbarkeit harmonisierter Normen müssen Hersteller alternative Nachweise erbringen, etwa durch Orientierung an bestehenden internationalen Standards wie der IEC 62443-Reihe.

Selbstbewertung vs. Drittprüfung: Welches Verfahren gilt für welches Produkt?

Welches Konformitätsbewertungsverfahren anzuwenden ist, hängt direkt von der Risikoklasse eines Produkts ab. Default-Produkte und die meisten Important-Class-I-Produkte können über eine interne Konformitätsbewertung durch den Hersteller selbst nachgewiesen werden. Important-Class-II-Produkte benötigen zwingend die Beteiligung einer benannten Stelle, unabhängig von harmonisierten Normen. Critical Products durchlaufen ein europäisches Zertifizierungsschema mit externer Prüfung. Hersteller sollten diese Einstufung frühzeitig klären, weil eine Drittprüfung deutlich mehr Vorlaufzeit benötigt als eine Selbstbewertung.

SBOM im Cyber Resilience Act: Warum die Software Bill of Materials Pflicht wird

Die SBOM (Software Bill of Materials) wird durch den CRA für viele Hersteller erstmals zur verbindlichen Pflicht. Sie schafft Transparenz darüber, aus welchen Komponenten eine Software besteht – einschließlich Bibliotheken von Drittanbietern. Diese Transparenz ist Voraussetzung dafür, Schwachstellen in der Lieferkette schnell zu identifizieren.

Ohne eine aktuelle SBOM können Hersteller kaum nachvollziehen, ob eine neu bekanntgewordene Schwachstelle in einer weitverbreiteten Bibliothek auch ihr eigenes Produkt betrifft. Genau das hat der Log4Shell-Vorfall 2021 vielen Unternehmen deutlich vor Augen geführt. Der CRA macht die SBOM-Pflege deshalb zu einem festen Bestandteil des Schwachstellenmanagements.

Häufige Fragen zum Anwendungsbereich des Cyber Resilience Act

Gilt der CRA auch für Unternehmen außerhalb der EU?

Ja. Der CRA gilt für jedes Produkt mit digitalen Elementen, das auf dem EU-Markt angeboten wird, unabhängig vom Sitz des Herstellers. Ein Unternehmen mit Sitz außerhalb der EU muss einen bevollmächtigten Vertreter in der EU benennen, wenn es Produkte dort in Verkehr bringt.

Was passiert, wenn ein Produkt mehreren EU-Verordnungen unterliegt?

Der CRA sieht in solchen Fällen vor, dass sektorspezifische Regelwerke mit gleichwertigem Cybersicherheitsniveau Vorrang haben können, etwa bei Medizinprodukten oder Fahrzeugen. Wo keine gleichwertige Regelung besteht, gilt der CRA zusätzlich. Eine Abgrenzung zu NIS2 und DORA behandeln wir separat im [interner Link: /cyber-resilience-act/cra-vs-nis2-dora/].

Ab wann müssen Produkte die CRA-Anforderungen erfüllen?

Der CRA trat am 10.12.2024 in Kraft. Meldepflichten für Sicherheitsvorfälle gelten bereits ab dem 11.09.2026. Die vollständige Geltung aller Anforderungen, einschließlich CE-Kennzeichnung, beginnt am 11.12.2027.

Was droht bei Nichteinhaltung des Cyber Resilience Act?

Bei Verstößen gegen die Sicherheitsanforderungen drohen laut Art. 64 CRA Bußgelder von bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist. Zusätzlich können Behörden Produkte vom Markt nehmen oder deren Vertrieb untersagen.

Was ist Annex I des Cyber Resilience Act?

Annex I ist der zentrale Anforderungskatalog des CRA (Verordnung (EU) 2024/2847). Er besteht aus zwei Teilen: Part I regelt die Sicherheitseigenschaften des Produkts selbst, Part II das Schwachstellenmanagement über den gesamten Produktlebenszyklus. Alle Hersteller von Produkten mit digitalen Elementen müssen beide Teile erfüllen.

Gilt der CRA auch für Open-Source-Software?

Nicht-kommerzielle Open-Source-Software ist weitgehend ausgenommen, solange sie außerhalb einer geschäftlichen Tätigkeit entwickelt wird. Sobald Open-Source-Komponenten kommerziell in ein Produkt integriert werden, gelten die CRA-Pflichten für dieses Produkt. Open-Source-Steward haben ein eigenes Pflichtenregime und sind laut Art. 64 Abs. 10 CRA von Bußgeldern befreit.

Brauche ich eine CE-Kennzeichnung nach dem CRA?

Ja, wenn Ihr Produkt unter den CRA fällt und in der EU in Verkehr gebracht wird. Die CE-Kennzeichnung bestätigt die Konformität mit den Anforderungen aus Annex I. Die Pflicht gilt ab dem 11.12.2027 für alle neu in Verkehr gebrachten Produkte.

Wie unterscheidet sich der CRA von NIS2?

Der CRA reguliert Produkte mit digitalen Elementen – also was Hersteller auf den Markt bringen. NIS2 reguliert Organisationen und deren Betrieb kritischer Infrastrukturen. Beide Verordnungen können gleichzeitig gelten, etwa wenn ein Unternehmen vernetzte Produkte herstellt und gleichzeitig als kritische Einrichtung eingestuft ist.

Nächste Schritte: So prüfen Sie, ob Ihr Unternehmen vom CRA betroffen ist

Ob und in welchem Umfang der CRA für ein Unternehmen gilt, hängt von der genauen Produktkategorie, der Risikoklasse und der Rolle in der Lieferkette ab. Diese Einordnung erfordert eine strukturierte Analyse des eigenen Produktportfolios. Axians begleitet Unternehmen im DACH-Raum bei genau dieser Analyse – von der ersten Produktklassifizierung bis zur vollständigen CRA-Konformität. Einen Überblick über die praktische Umsetzung der CRA-Anforderungen finden Sie im Artikel "CRA Compliance: Schritt für Schritt zur Umsetzung des Cyber Resilience Act".

Welche Anforderungen stellt der Cyber Resilience Act? Wer ist betroffen – und was gilt für IoT, SaaS, Open Source & Co.? Jetzt kompakt erklärt.

CRA

Weiterlesen →

< Zurück zur Übersicht

CRA