Praxisorientierte Einordnung zu CRA, NIS2 und Produkthaftung: Pflichten sauber voneinander abgrenzen: Anforderungen verstehen, Risiken priorisieren und eine belastbare Umsetzung für Cyber Resilience Act aufbauen.
Cyber Resilience Act, NIS2 und die neue EU-Produkthaftungsrichtlinie betrachten digitale Sicherheit aus drei verschiedenen Richtungen. Der CRA regelt Cybersicherheitsanforderungen und Marktbereitstellung von Produkten mit digitalen Elementen. NIS2 verpflichtet betroffene Einrichtungen zu organisatorischem, technischem und operativem Risikomanagement. Die Produkthaftungsrichtlinie regelt den Schadensersatz für fehlerhafte Produkte und bezieht Software sowie sicherheitsrelevante Updates ausdrücklich ein.
Für Hersteller, Betreiber und digitale Dienstleister entstehen dadurch Überschneidungen, aber keine Austauschbarkeit. Ein Produkt kann CRA-konformitätsrelevant sein, während sein Hersteller zugleich als NIS2-Einrichtung betroffen ist. Kommt es durch eine ausnutzbare Schwachstelle zu einem Schaden, kann zusätzlich Produkthaftung relevant werden. Dieser Beitrag trennt die Rechtslogiken und zeigt, wie Unternehmen gemeinsame Prozesse aufbauen, ohne Pflichten zu vermischen.
Drei Rechtsakte, drei Steuerungsfragen
CRA: Darf und unter welchen Cybersecurity-Voraussetzungen ein Produkt mit digitalen Elementen auf dem EU-Markt bereitgestellt werden? Der Fokus liegt auf Produktdesign, Entwicklung, Produktion, Vulnerability Handling, Konformitätsbewertung, CE-Kennzeichnung und Marktüberwachung.
NIS2: Wie muss eine betroffene Organisation ihre Cyberrisiken steuern und erhebliche Sicherheitsvorfälle melden? Der Fokus liegt auf der Einrichtung und ihren Diensten, der Verantwortung der Leitungsorgane, Geschäftskontinuität, Lieferkette und Wirksamkeit der Maßnahmen.
Produkthaftung: Wer haftet verschuldensunabhängig für Schäden, die durch ein fehlerhaftes Produkt verursacht werden, und unter welchen Voraussetzungen? Die Richtlinie modernisiert den Produktbegriff für Software, verbundene Dienste, Updates und digitale Komponenten.
Diese drei Fragen führen zu unterschiedlichen Nachweisen. Eine CRA-Produktakte beantwortet nicht automatisch, ob das unternehmensweite NIS2-Risikomanagement angemessen ist. Ein NIS2-ISMS ersetzt keine Konformitätsbewertung. Und weder Zertifikat noch CE-Zeichen schließen eine spätere haftungsrechtliche Bewertung des konkreten Produkts aus.
Cyber Resilience Act: Pflichten entlang des Produktlebenszyklus
Der CRA gilt grundsätzlich für Produkte mit digitalen Elementen, die eine direkte oder indirekte Verbindung zu einem Gerät oder Netz einschließen und auf dem EU-Markt bereitgestellt werden. Hersteller müssen eine Cybersecurity-Risikobewertung durchführen, wesentliche Anforderungen in Design, Entwicklung und Produktion umsetzen und Schwachstellen während des festgelegten Unterstützungszeitraums behandeln.
Vor der Marktbereitstellung ist der passende Konformitätsweg zu durchlaufen. Abhängig von Produktkategorie und eingesetzten Standards kann interne Kontrolle möglich oder eine externe Bewertung erforderlich sein. Technische Dokumentation, EU-Konformitätserklärung und CE-Kennzeichnung machen die Verantwortungszuordnung sichtbar.
Der CRA enthält zudem eigenständige Meldepflichten: Ab 11. September 2026 sind aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle mit Produktauswirkung über die Single Reporting Platform zu melden. Diese Meldelogik ist produktbezogen und darf nicht mit NIS2-Vorfallmeldungen gleichgesetzt werden.
NIS2: Pflichten der betroffenen Einrichtung
NIS2 erfasst wesentliche und wichtige Einrichtungen in den in den Anhängen genannten Sektoren, abhängig von Tätigkeitsart, Größe und nationaler Umsetzung. Die Richtlinie verlangt angemessene und verhältnismäßige technische, operative und organisatorische Maßnahmen. Dazu zählen Risikoanalyse, Incident Handling, Business Continuity, Krisenmanagement, Lieferkettensicherheit, sichere Beschaffung und Entwicklung, Wirksamkeitsbewertung, Cyberhygiene, Kryptografie, Personal- und Zugriffssicherheit sowie starke Authentisierung.
Die Leitung muss Maßnahmen genehmigen und ihre Umsetzung überwachen. Schulung und nachvollziehbare Risikoentscheidungen sind deshalb nicht nur Aufgabe der IT. Erhebliche Vorfälle unterliegen einer gestuften Meldepflicht, deren Kriterien und zuständige Stellen sich aus der nationalen Umsetzung ergeben.
Ein Hersteller digitaler Produkte kann NIS2-betroffen sein, beispielsweise aufgrund seiner Tätigkeit oder eines angebotenen Dienstes. Das ändert nichts daran, dass CRA-Anforderungen pro Produkt zu erfüllen sind. Umgekehrt kann ein kleiner Hersteller CRA-Pflichten haben, obwohl er nicht in den NIS2-Unternehmensscope fällt.
Neue Produkthaftung: Software und Cybersecurity werden haftungsrelevant
Die Richtlinie (EU) 2024/2853 modernisiert die verschuldensunabhängige Haftung für fehlerhafte Produkte. Software wird ausdrücklich als Produkt erfasst, unabhängig davon, ob sie auf einem Gerät gespeichert, über ein Netz oder über Cloud-Technologien bereitgestellt wird. Auch verbundene Dienste und digitale Komponenten können für die Produktsicherheit relevant sein.
Bei der Beurteilung der Fehlerhaftigkeit können sicherheitsrelevante Cybersecurity-Anforderungen und behördliche Maßnahmen berücksichtigt werden. Ein Produkt kann aufgrund einer Cybersecurity-Schwachstelle fehlerhaft sein, wenn es nicht die Sicherheit bietet, die berechtigterweise erwartet werden darf. Die Richtlinie berücksichtigt außerdem, dass Hersteller durch Softwareupdates oder verbundene Dienste nach Markteinführung Kontrolle behalten können.
Besonders relevant ist der Umgang mit Sicherheitsupdates. Die Erwägungsgründe stellen klar, dass ein Hersteller sich nicht ohne Weiteres entlasten kann, wenn die Fehlerhaftigkeit daraus resultiert, dass notwendige Softwareupdates zur Behandlung von Cybersecurity-Schwachstellen nicht bereitgestellt wurden. Die Produkthaftungsrichtlinie selbst schafft damit nicht dieselbe Updatepflicht wie der CRA; sie kann jedoch haftungsrechtliche Folgen an fehlende notwendige Sicherheitsupdates knüpfen.
Scope-Vergleich an einem Beispiel
Ein europäischer Hersteller verkauft ein vernetztes Gebäudesteuerungssystem mit lokaler Hardware, Firmware, mobiler App und Cloud-Portal. Das System wird in Krankenhäusern und Gewerbeimmobilien eingesetzt. Ein externer Softwareanbieter liefert eine Bibliothek für die Updatefunktion.
CRA-Perspektive: Der Hersteller prüft Hardware, Firmware, App und relevante Fernverarbeitung im Produkt-Scope. Er bewertet Produktrisiken, klassifiziert das System, implementiert sichere Updates, führt eine Komponentenübersicht und behandelt Schwachstellen. Er ist für die Konformität des Gesamtprodukts verantwortlich, auch wenn eine Fremdbibliothek integriert ist.
NIS2-Perspektive: Der Hersteller prüft unabhängig davon seine eigene Betroffenheit. Der Krankenhausbetreiber kann ebenfalls NIS2-pflichtig sein und muss bei der Beschaffung die Sicherheit des Produkts und Lieferanten berücksichtigen. Die Beschaffungspflicht des Kunden ersetzt die Produktpflicht des Herstellers nicht.
Haftungsperspektive: Führt eine ausnutzbare Update-Schwachstelle zu einem erfassten Schaden, kann geprüft werden, ob das Produkt fehlerhaft war. Relevant können das Sicherheitsniveau, notwendige Updates, Herstellerkontrolle und die Rolle der integrierten Software sein. Vertragsbeziehungen zwischen Hersteller und Komponentenlieferant dürfen den Schutz der geschädigten Person nicht einfach beseitigen.
Meldepflichten: ein Ereignis, möglicherweise mehrere Wege
Ein Sicherheitsereignis kann gleichzeitig unterschiedliche Meldungen auslösen. Wird eine Schwachstelle in einem Produkt aktiv ausgenutzt, kann der Hersteller nach CRA melden müssen. Führt derselbe Angriff zu einem erheblichen Vorfall bei einer NIS2-betroffenen Einrichtung, kann zusätzlich deren NIS2-Meldepflicht entstehen. Datenschutzverletzungen können wiederum eine DSGVO-Prüfung erfordern.
Unternehmen sollten deshalb ein gemeinsames Incident Intake betreiben, aber jede Meldelogik separat bewerten. Das Intake sammelt Zeitpunkt, Produkt oder Dienst, betroffene Versionen, Ausnutzungsindikatoren, Auswirkungen, personenbezogene Daten und betroffene Gesellschaften. Eine Entscheidungsmatrix ordnet anschließend Rechtsgrundlage, Frist, Behörde, Verantwortlichen und erforderliche Folgeinformationen zu.
Eine einzige Meldung erfüllt nicht automatisch alle Pflichten. Zuständige Behörden, Begriffe und Fristen können unterschiedlich sein. Gleichzeitig müssen Aussagen konsistent bleiben. Widersprüchliche Angaben zu Beginn, Umfang oder Auswirkungen erzeugen unnötige Rechts- und Vertrauensrisiken.
Lieferkette: Verantwortung lässt sich nicht vollständig weiterreichen
NIS2 fordert von betroffenen Einrichtungen, die Sicherheit ihrer unmittelbaren Lieferanten und Dienstleister sowie deren sichere Entwicklungspraktiken zu berücksichtigen. Der CRA verpflichtet Hersteller, Komponentenrisiken im Produkt zu beherrschen. Die Produkthaftungsrichtlinie regelt mögliche Haftung mehrerer Wirtschaftsakteure und den Umgang mit fehlerhaften Komponenten.
Verträge bleiben wichtig, lösen aber nicht die Außenverantwortung. Der Produkthersteller benötigt Informationen über Komponenten, Sicherheitsmeldungen, Fixes und Supportdauer. Der NIS2-betroffene Kunde benötigt Nachweise über sichere Entwicklung, Vorfallkommunikation und Kontinuität. Beide Seiten sollten Eskalation und Verantwortungen vor einem Vorfall testen.
Bei Open-Source-Software ist zu unterscheiden, ob sie außerhalb einer kommerziellen Tätigkeit entwickelt oder bereitgestellt wird und wie sie in ein kommerzielles Produkt integriert wird. Dass eine Komponente frei verfügbar ist, nimmt dem integrierenden Hersteller nicht automatisch die Verantwortung für sein Gesamtprodukt. Er benötigt Auswahl-, Update- und gegebenenfalls Ersatzprozesse.
Secure Development als gemeinsame operative Klammer
Alle drei Rechtsbereiche erhöhen den Wert eines nachvollziehbaren Secure Development Lifecycle. Der CRA fordert produktbezogene Risikobewertung, Security-Anforderungen und Vulnerability Handling. NIS2 nennt Sicherheit bei Erwerb, Entwicklung und Wartung von Netz- und Informationssystemen. Haftungsrechtlich kann die Frage relevant werden, ob ein Produkt angesichts seiner Cybersecurity-Eigenschaften fehlerhaft war.
Ein gemeinsamer Prozess sollte deshalb folgende Ergebnisse erzeugen: dokumentierter Verwendungskontext, Threat Model, sichere Architektur, Komponentenübersicht, risikobasierte Tests, kontrollierte Releasefreigabe, Updatefähigkeit und Supportprozess. Diese Ergebnisse werden je Produktversion archiviert. So kann das Unternehmen später nicht nur behaupten, sorgfältig gearbeitet zu haben, sondern konkrete Entscheidungen und Prüfungen nachweisen.
Wichtig ist die zeitliche Perspektive. Sicherheit wird nach Markteinführung weiterbeobachtet. Neue Schwachstellen, veränderte Bedrohungen, Cloud-Änderungen und Supportende können zusätzliche Maßnahmen erfordern. Ein einmaliger Testbericht bildet diesen Lebenszyklus nicht ab.
Was gemeinsam gesteuert werden kann – und was getrennt bleiben muss
Gemeinsam steuerbar
- Produkt- und Komponentenregister als verlässliche Datenbasis.
- Secure-Development- und Vulnerability-Handling-Prozesse.
- Lieferantenanforderungen und Security-Klauseln.
- Zentrales Incident Intake und abgestimmte Krisenkommunikation.
- Management-Reporting zu Produkt- und Unternehmensrisiken.
- Nachweisführung über Entscheidungen, Tests, Updates und Kundeninformation.
Getrennt zu bewerten
- CRA-Scope und Klassifizierung je Produktfamilie.
- NIS2-Betroffenheit je Rechtsträger, Tätigkeit und Dienst.
- Konformitätsbewertungsweg und CE-Unterlagen.
- Konkrete Meldepflicht, Frist und zuständige Stelle je Ereignis.
- Haftungsrechtliche Beurteilung eines Schadensfalls.
Diese Trennung verhindert zwei Extreme: drei voneinander isolierte Compliance-Projekte mit Doppelarbeit oder ein einziges Mapping, das wichtige rechtliche Unterschiede verwischt.
Praktische Nachweismatrix
Eine schlanke Matrix kann Anforderungen aus den drei Bereichen mit operativen Artefakten verbinden. Der Eintrag „Sicherheitsupdate“ verweist beispielsweise auf Produktrisiko, Updatearchitektur, Signaturverfahren, Regressionstest, Releasefreigabe, Kundenhinweis und Verteilungsnachweis. Daneben stehen CRA-Anforderung, möglicher NIS2-Bezug und Aufbewahrung für haftungsrelevante Nachvollziehbarkeit.
Die Matrix darf jedoch nicht zur bloßen Kontrollsammlung werden. Jeder Nachweis braucht eine konkrete Produktversion, einen Eigentümer und eine Qualitätsprüfung. Ein konzernweiter Updateprozess beweist wenig, wenn eine bestimmte Altversion technisch keine authentisierten Updates unterstützt.
Bei Änderungen wird geprüft, welche Perspektiven neu zu bewerten sind. Eine neue Cloud-Funktion kann den CRA-Produktscope, NIS2-Dienstabhängigkeiten und die Herstellerkontrolle im haftungsrechtlichen Sinn beeinflussen. Diese Prüfung gehört in das normale Product Change Board.
Acht Fragen für Geschäftsleitung und Produktverantwortliche
- Welche Gesellschaft ist für welche Produktfamilie Hersteller im rechtlichen Sinn?
- Welche Unternehmensteile und Dienste fallen unter die nationale NIS2-Umsetzung?
- Können wir Produktversionen innerhalb weniger Stunden auf eine kritische Komponente abbilden?
- Wer entscheidet über CRA-, NIS2- und Datenschutzmeldungen und hält Aussagen konsistent?
- Welche Produkte können Sicherheitsupdates nicht über den erwarteten Nutzungszeitraum erhalten?
- Welche Lieferantenverträge sichern Schwachstelleninformation, Fixes und Support tatsächlich ab?
- Welche Produktakte zeigt die Risikobewertung und Security-Tests einer ausgelieferten Version?
- Wie werden wesentliche Produktänderungen und neue verbundene Dienste rechtlich-technisch bewertet?
Fazit: Eine operative Basis, drei saubere Bewertungen
CRA, NIS2 und Produkthaftung verfolgen unterschiedliche Ziele. Ihre Schnittmenge liegt in wirksamer Cybersecurity, transparenter Lieferkette, sicherer Entwicklung und nachvollziehbarer Reaktion. Unternehmen sollten diese operative Basis gemeinsam aufbauen, Scope, Meldung, Konformität und Haftung jedoch getrennt beurteilen. So werden Nachweise mehrfach nutzbar, ohne rechtliche Unterschiede zu übersehen.
BlackMount unterstützt Unternehmen bei der integrierten Umsetzung von Produktsecurity, NIS2-Risikomanagement und belastbarer Nachweisführung. Weitere Informationen finden Sie unter Cyber Resilience Act Beratung.
