Der Cyber Resilience Act macht Cybersicherheit zur Produkteigenschaft. Die neue Produkthaftungsrichtlinie macht jeden CRA-Verstoß zum potenziellen Produktfehler.
Unter dem Motto „10 Jahre DSGVO – Und jetzt? Gemeinsam weiterdenken!“ haben mein Kollege Dominik Bleckmann und ich für die diesjährigen CAMPUSTAGE den Cyber Resilience Act (CRA) beleuchtet. Der vorliegende Beitrag greift die Aspekte des Vortrags auf, die in der Beratungspraxis die meisten Fragen aufwerfen.
Der CRA (Verordnung (EU) 2024/2847) ist seit Dezember 2024 in Kraft und gilt unmittelbar in allen Mitgliedstaaten. Er verpflichtet Hersteller von Hard- und Software mit Datenverbindung, ihre Produkte nach verbindlichen Sicherheitsanforderungen zu entwickeln, Schwachstellen über Jahre hinweg zu beheben, Sicherheitsvorfälle zu melden und all das zu dokumentieren. Sichtbares Zeichen ist künftig das CE-Kennzeichen, wie man es von Elektrogeräten oder Spielzeug kennt. Einen Überblick über die Grundlagen haben wir hier gegeben.
Vom Datum zum Ding
Die Digitalgesetzgebung der EU lässt sich grob in drei Wellen gliedern. Die DSGVO fragte „Wer darf was?“, NIS-2 (Cybersicherheitspflichten für Betreiber wichtiger Einrichtungen), DORA (digitale Resilienz im Finanzsektor) und der Data Act (Zugang zu Daten vernetzter Geräte) fragten „Wie funktioniert der digitale Markt?“. CRA, AI Act und die neue Produkthaftungsrichtlinie fragen nun: „Was muss ein digitales Produkt können?“
Damit ändert sich, wen das Gesetz in die Pflicht nimmt. Adressat ist nicht mehr der Datenverarbeiter oder der Betreiber einer Organisation, sondern der Hersteller; Gegenstand ist das Produkt. Anders als NIS-2 kennt der CRA weder Schwellenwerte noch einen Branchenfilter. Neu ist vor allem der Lebenszyklusgedanke: Der Hersteller verantwortet sein Produkt von der Entwicklung bis zum End-of-Support.
Nicht die Größe entscheidet
Herstellerpflichten treffen nicht nur denjenigen, der ein Produkt selbst entwickelt. Hersteller im Sinne des CRA wird man schneller, als mancher glaubt: Wer Produkte unter eigenem Label vertreibt, trägt die vollen Pflichten nach Art. 13 CRA, ebenso wer ein Produkt wesentlich verändert (Art. 21 CRA). Nach Erwägungsgrund 15 genügt bereits die konzerninterne Lieferung an eine rechtlich selbstständige Tochtergesellschaft. Das ist ein Punkt, der in Konzernstrukturen leicht übersehen werden kann.
Die Ausnahmen für spezialgesetzlich regulierte Bereiche sind dagegen eng. Bei Medizinprodukten erfassen sie nur das Kernprodukt, nicht Begleit-Apps, Cloud-Dienste oder Diagnostik. Im Automotive-Bereich bleiben Aftermarket-Produkte und Flottenmanagement erfasst. Und reine SaaS-Angebote sind nur ausgenommen, solange sie keine installierbaren Komponenten wie Clients, Agenten oder Downloads umfassen.
Aber auf die Technik kommt es an
Wie weit die Verantwortung reicht, zeigt zunächst Art. 13 Abs. 3 CRA: Die Risikoanalyse muss die „vernünftigerweise vorhersehbare Verwendung“ berücksichtigen, nicht nur die beabsichtigte. Zudem endet die Verantwortung nicht mit der Einrichtung beim Kunden. Nach Art. 13 Abs. 8 CRA sind während eines Unterstützungszeitraums von grundsätzlich mindestens fünf Jahren kostenlose Sicherheitsupdates bereitzustellen.
Besonders praxisrelevant ist die wesentliche Änderung (Art. 3 Nr. 30 CRA): Nach Erwägungsgrund 39 kann bereits ein Softwareupdate mit neuen Funktionen eine solche darstellen; ausgenommen sind lediglich Sicherheitsupdates und Anpassungen zur Barrierefreiheit. Das ist folgenreich, denn der CRA behandelt ein wesentlich geändertes Produkt wie ein neues: Die Konformität ist neu zu bewerten, und Altprodukte fallen dadurch erstmals unter den CRA. Konsequent zu Ende gedacht muss der Hersteller damit bei jedem Funktionsupdate prüfen und dokumentieren, ob sich die Risikolage ändert. Leitlinien der EU-Kommission hierzu stehen noch aus.
Wenn zu viel versprochen wurde?
Seine eigentliche Schärfe erhält der CRA erst im Zusammenspiel mit der neuen EU-Produkthaftungsrichtlinie, die bis zum 09.12.2026 umzusetzen ist. Die Produkthaftung ist verschuldensunabhängig: Wer durch ein fehlerhaftes Produkt an Körper, Gesundheit oder Eigentum geschädigt wird (künftig auch durch Verlust oder Beschädigung privater Daten), kann den Hersteller in Anspruch nehmen, ohne ihm ein Verschulden nachweisen zu müssen. Die unter der Richtlinie von 1985 umstrittene Frage, ob Software überhaupt ein Produkt ist, hat sich erledigt: Erfasst ist Software jeder Art, ob verkauft, kostenlos oder als SaaS bereitgestellt, einschließlich fehlerhafter Updates nach dem Inverkehrbringen.
Nach Art. 7 der Richtlinie erfüllt ein Verstoß gegen unionsrechtliche Sicherheitsanforderungen unmittelbar den Tatbestand eines Fehlers. Fehlende Sicherheitsupdates, ein unzureichendes Schwachstellenmanagement oder eine fehlende Secure-by-Default-Konfiguration werden damit zum zivilrechtlichen Haftungsrisiko.
Zwar muss der Kläger nach Art. 10 Abs. 1 grundsätzlich Fehler, Schaden und Kausalität beweisen. Bei einem Verstoß gegen Produktsicherheitsanforderungen wird die Fehlerhaftigkeit jedoch gesetzlich vermutet. Hinzu kommt Art. 9: Hersteller können zur Offenlegung interner Unterlagen verpflichtet werden, insbesondere der technischen Dokumentation, der Risikoanalysen und der Schwachstellenberichte. Verweigern sie dies, wird die Fehlerhaftigkeit angenommen. In der Praxis kommt das einer Beweislastumkehr nahezu gleich. Wer keine CRA-Dokumentation vorlegen kann, wird einen gerichtlichen Prozess absehbar verlieren, noch bevor die Beweisaufnahme eröffnet ist.
Grenzenlos, aber das Organ bleibt verschont
Auch der Haftungsumfang ändert sich grundlegend. Der Höchstbetrag von 85 Mio. € nach § 10 ProdHaftG a. F. entfällt ebenso wie der Selbstbehalt von 500 €. Neben Herstellern und Akteuren, die Produkte wesentlich verändern, haften subsidiär Importeure, EU-Bevollmächtigte und Fulfillment-Dienstleister, etwa wenn der Hersteller außerhalb der EU sitzt. Hinzu kommen auf behördlicher Ebene Bußgelder nach dem CRA von bis zu 15 Mio. € oder 2,5 % des weltweiten Konzernjahresumsatzes.
Bemerkenswert ist, was fehlt: Eine eigene persönliche Haftung der Geschäftsleitung kennt der CRA nicht. Bei NIS-2 verhält sich dies anders: Dort muss die Geschäftsleitung die Risikomanagementmaßnahmen billigen und überwachen und haftet bei Pflichtverletzungen persönlich (§ 38 BSIG). Ein Durchgriff kommt nur ausnahmsweise nach allgemeinen Grundsätzen in Betracht. Das Schwert dürfte dennoch scharf genug sein.
Zu früh kommt keiner
Schon seit dem 11.09.2026 gelten die Meldepflichten nach Art. 14 CRA auch für Produkte, die bereits auf dem Markt sind. Aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle sind binnen 24 Stunden als Frühwarnung an das zuständige IT-Notfallteam (CSIRT, in Deutschland das BSI) und die EU-Agentur für Cybersicherheit (ENISA) zu melden, binnen 72 Stunden folgt die nähere Meldung. Wer den Incident-Response-Prozess noch nicht an die ENISA-Meldeplattform angebunden hat, sollte dies vorrangig nachholen.
Die übrigen Anforderungen wie die Software-Stückliste (SBOM), technische Dokumentation, Konformitätsbewertung und CE-Kennzeichnung gelten ab dem 11.12.2027. Produkte, die vor diesem Datum in Verkehr gebracht werden, fallen erst bei einer wesentlichen Änderung darunter (Art. 69 CRA). Angesichts des weiten Änderungsbegriffs ist dieser Aufschub allerdings trügerisch: Das erste Funktionsupdate nach diesem Stichtag kann ihn beenden.
Fazit: Ausdauer zahlt sich aus
Der CRA verändert weniger das „Ob“ als das „Wie lange“ der Herstellerverantwortung. Im Zusammenspiel mit der Produkthaftungsrichtlinie wird die CRA-Dokumentation zum entscheidenden Verteidigungsmittel im Zivilprozess. Die Erfüllung der CRA-Anforderungen ist damit der stärkste verfügbare Schutz vor Haftung.
Gefragt ist daher kein einmaliges Konformitätsprojekt, sondern ein belastbarer Prozess, der Risikoanalyse, Schwachstellenmanagement und Dokumentation über den gesamten Unterstützungszeitraum aktuell hält – idealerweise eingebettet in ein Compliance-Management-System, das die Anforderungen aus DSGVO, NIS-2 und CRA zusammenführt.
Wenn Sie das Thema interessiert oder betrifft, laden wir Sie herzlich dazu ein, mit uns Kontakt für unsere Compliance-Dienstleistungen im Bereich CRA und Data Governance aufzunehmen. Wir nehmen uns Zeit für ein maßgeschneidertes Angebot für Sie.
Keine Kommentare