Der EU Cyber Resilience Act (CRA, Verordnung (EU) 2024/2847) und die revidierte Produkthaftungsrichtlinie (PHRL, Richtlinie (EU) 2024/2853) wurden 2024 innerhalb weniger Monate Gesetz. Beide adressieren software-tragende Produkte. Beide bringen neue Herstellerpflichten. Aber sie wirken über völlig unterschiedliche Mechanismen — die eine regulatorisch, die andere zivilrechtlich-haftungsbasiert — und Softwarehersteller müssen beide erfüllen. Dieser Artikel kartiert Überschneidungen, Unterschiede und das praktische Zusammenspiel.
CRA und PHRL: Zwei Mechanismen, dieselben Produkte
Der CRA ist eine Verordnung: in jedem EU-Mitgliedstaat unmittelbar anwendbar, durch Marktüberwachung durchgesetzt, mit Bußgeldern bis zu 2,5 % des weltweiten Jahresumsatzes oder 15 Mio. € bei Verstößen. Der CRA sagt Herstellern, welches Cybersicherheits-Ergebnis ein Produkt mit digitalen Elementen erreichen muss, bevor es auf den EU-Markt darf.
Die revidierte PHRL ist eine Richtlinie: muss von jedem Mitgliedstaat in nationales Recht umgesetzt werden, durch Zivilklagen durchgesetzt, ohne Obergrenze für Schadensersatz. Die PHRL sagt Verbrauchern und Downstream-Nutzern, wofür sie klagen können, wenn ein fehlerhaftes Produkt einen Schaden verursacht — und die neue PHRL stellt explizit klar, dass Software ein Produkt ist und dass Cybersicherheits-Schwachstellen eine Art Fehler sind.
Ein einzelnes vernetztes Produkt — ein Smart-Thermostat, eine Industriesteuerung, ein tragbares Medizin-Zubehör — fällt gleichzeitig unter beide. CRA-Konformität schützt nicht vor PHRL-Klagen; PHRL-Sorgfalt erzeugt keine CRA-Konformität.
Was jedes Gesetz verlangt
| Dimension | CRA | PHRL (revidiert, 2024/2853) |
|---|---|---|
| Rechtsform | Verordnung (unmittelbar geltend) | Richtlinie (nationale Umsetzung) |
| Durchsetzung | Marktüberwachung, regulatorische Bußgelder | Zivilrechtliche Haftung, Gerichts-Schadensersatz |
| Produkt-Geltungsbereich | Produkte mit digitalen Elementen | Alle Produkte inkl. eigenständiger Software |
| Fehler-Konzept | Nicht-Erfüllung der Anhang-I-Anforderungen | Mangel an Sicherheit, die ein vernünftiger Nutzer erwarten würde |
| Hersteller-Pflicht | Konformitätsbewertung, SBOM, Schwachstellenbehandlung, Unterstützungszeitraum | Verschuldensunabhängige Haftung für Schäden durch fehlerhaftes Produkt |
| Strafmaß | Bis 15 Mio. € / 2,5% globaler Umsatz | Unbegrenzter Schadensersatz |
| Stichtag | Volle Compliance 11. Dezember 2027 | Nationale Umsetzung bis 9. Dezember 2026 |
Wo sie sich überschneiden: Cybersicherheits-Fehler
Der wichtigste Überschneidungspunkt ist die Behandlung von Cybersicherheits-Schwachstellen durch die PHRL. Unter der revidierten PHRL ist ein Produkt „fehlerhaft", wenn ihm die Sicherheit fehlt, die ein vernünftiger Nutzer erwarten würde — und die Richtlinie nennt explizit Cybersicherheits-Schwachstellen und fehlende Sicherheitsupdates als Faktoren dieser Bewertung.
Das erzeugt eine Rückkopplung mit dem CRA. Der CRA definiert in Anhang I, welche Cybersicherheits-Ergebnisse ein Produkt erreichen muss. Ein Produkt, das diese Ergebnisse verfehlt, ist CRA-nicht-konform — und sehr wahrscheinlich „fehlerhaft" im Sinne der PHRL. Die CRA-Konformitätsbewertung wird zum Beweis, der unmittelbar PHRL-Haftungsverteidigung beeinflusst.
Umgekehrt gilt das Gleiche. Wenn ein Gericht ein Produkt aufgrund einer Cybersicherheits-Schwachstelle als PHRL-fehlerhaft befindet, legt das nahe, dass der Hersteller CRA-Pflichten verfehlt hat: unzureichende Schwachstellenbehandlung, versäumte Updates im Unterstützungszeitraum oder unterlassene Kommunikation der Schwachstelle an betroffene Nutzer.
Wo sie sich unterscheiden: Schaden vs. Compliance
Der CRA ist ein Compliance-Regime. CRA-Verstöße führen zu regulatorischen Bußgeldern, Marktzugangsverlust und Produktrückrufen. CRA-Vollzug adressiert keinen Schadensersatz an geschädigte Nutzer.
Die PHRL ist ein Schadensregime. Sie ermöglicht Schadensersatzansprüche für materielle Schäden an Personen oder Sachen — und die revidierte PHRL ergänzt Schadensersatz für Datenverlust und für immaterielle Schäden, wo nationales Recht das zulässt. CRA-Konformität erfüllt diese Schadensersatzansprüche nicht; sie reduziert nur die Wahrscheinlichkeit, sie auszulösen.
Das bedeutet, ein Hersteller muss beides adressieren: CRA-Prozesse verhindern die regulatorische Strafe, PHRL-Prozesse (Gewährleistung, Versicherung, Schwachstellen-Offenlegung, Marktbeobachtung) bereiten auf den Zivilschaden-Fall vor.
Das 10-Jahres-Verjährungsfenster
Die PHRL verlängert die Herstellerhaftung auf zehn Jahre nach Inverkehrbringen — und bei Produkten mit digitalen Elementen, bei denen der Hersteller zu Sicherheitsupdates verpflichtet ist, beginnt die Frist mit jeder wesentlichen Änderung neu. Dieses 10-Jahres-Fenster ist bewusst an die CRA-Unterstützungszeitraum-Pflicht angeglichen. Hersteller können ihre CRA-Unterstützungspflicht nicht nach 5 Jahren beenden und annehmen, dass die PHRL-Haftung mit der Garantie endet: PHRL-Ansprüche können lange nach dem Verkauf entstehen.
Praktische Implikation: Die für CRA-Zwecke erstellten SBOMs, Schwachstellenbehandlungs-Logs und Konformitäts-Dokumentation dienen auch als PHRL-Verteidigungsbeweis über denselben Zehn-Jahres-Horizont. Alles zehn Jahre aufbewahren; die zwei Regime teilen die Aufbewahrungsanforderung.
Was Software-als-Produkt unter der PHRL bedeutet
Die revidierte PHRL beseitigt die historische Unklarheit, ob Software ein „Produkt" ist. Sie ist es explizit — inklusive:
- Eingebettete Software in physischen Produkten
- Eigenständige Anwendungssoftware
- Betriebssysteme
- KI-Systeme
Damit fallen reine SaaS-Anbieter und Software-Hersteller in den PHRL-Geltungsbereich — selbst dort, wo die CRA-Ausnahmen für Software-as-a-Service greifen könnten. Ein von der CRA-Konformitätsbewertung ausgenommener SaaS-Anbieter haftet trotzdem nach PHRL, wenn ein Software-Fehler einen Schaden verursacht. Open-Source-Software bleibt grundsätzlich ausgenommen, aber kommerzielle Nutzung von Open-Source-Komponenten überträgt die Haftung auf den kommerziellen Distributor.
Bei dual betroffenen Produkten (CRA und PHRL) leistet die CRA-SBOM-Pflicht Doppelarbeit: sie dokumentiert die Software-Komposition für CRA-Nachweise und sie dokumentiert die Lieferkette für PHRL-Regressansprüche, wenn eine fehlerhafte Komponente einen Schaden verursacht.
Praktische Implikationen für Hersteller
Drei Compliance-Praktiken erfüllen beide Regime:
CRA-Konformitäts-Dokumentation als PHRL-Verteidigungsbeweis behandeln. Die Technische Dokumentation, SBOM, Risikobewertung und Schwachstellenbehandlungs-Logs, die der CRA verlangt, sind exakt das, was ein Hersteller braucht, um Nicht-Fehlerhaftigkeit in einer PHRL-Klage zu zeigen. Einmal aufbauen, für beide Zwecke nutzen.
Den Unterstützungszeitraum über das marketinggetriebene Minimum hinaus ausdehnen. Der CRA verlangt einen deklarierten Unterstützungszeitraum. Einen kurzen Zeitraum zu wählen, um CRA-Aufwand zu reduzieren, erhöht das PHRL-Risiko — Produkte ohne Sicherheitsupdates jenseits des Unterstützungszeitraums sind leichter als fehlerhaft zu charakterisieren. Der wirtschaftlich optimale Unterstützungszeitraum bedenkt sowohl CRA-Kosten als auch PHRL-Haftung.
Schwachstellenbehandlung als gemeinsamen Compliance-Hebel begreifen. Ein robuster Schwachstellenbehandlungsprozess reduziert CRA-Verstoßrisiko (ENISA-Meldung, Kundenkommunikation, Sicherheitsupdate-Auslieferung) und PHRL-Schadensrisiko (frühe Mitigation reduziert realisierten Schaden) gleichzeitig. Es ist die Praxis mit dem höchsten Hebel über beide Regime hinweg.
Wie Kunnus die CRA-PHRL-Überschneidung handhabt
Kunnus ist um die strukturierte Datenschicht gebaut, die beide Regime verlangen. Produktkatalog, SBOM-Aggregation, Schwachstellen-Monitoring, Unterstützungszeitraum-Tracking und audit-fertige Dokumentation leisten Doppelarbeit: CRA-Konformitätsnachweise und PHRL-Verteidigungsnachweise am selben Ort, standardmäßig zehn Jahre aufbewahrt.
Für Hersteller, die beide Regime betreffen — das sind die meisten Hersteller vernetzter Produkte — konsolidiert Kunnus den Compliance- und Haftungs-Verteidigungs-Workflow.
Starten Sie mit unserer CRA-Reifegradanalyse oder erkunden Sie die Plattform, um zu sehen, wie das duale CRA-PHRL-Nachweismodell strukturiert ist.