Die neue EU-Produkthaftungsrichtlinie (EU 2024/2853) ändert die Spielregeln grundlegend: Software gilt künftig als Produkt. Datenverlust wird zum Haftungsgrund. Die bisherige Höchstgrenze für Schadenersatz ist entfallen. Für Unternehmen, die Software herstellen oder Open-Source-Komponenten in ihre Produkte integrieren, entsteht ein neues Haftungsrisiko, das sich direkt auf die Sorgfalt bei der Komponentenauswahl auswirkt.
Jedes Unternehmen, das Software entwickelt und auf dem EU-Markt bereitstellt, fällt unter die neue Produkthaftung - unabhängig davon, ob die Software eigenständig vertrieben oder als Bestandteil eines größeren Produkts geliefert wird.
Wenn Sie Open-Source-Software in Ihr Produkt integrieren, haften Sie als Hersteller für das Gesamtprodukt. Das gilt auch für transitive Abhängigkeiten: Eine Schwachstelle in einer Bibliothek, die Ihre Bibliothek nutzt, kann Ihre Haftung auslösen.
Wer Software in die EU einführt oder vertreibt, kann unter bestimmten Umständen ebenfalls haftbar gemacht werden -insbesondere wenn der Hersteller außerhalb der EU sitzt und nicht erreichbar ist.
Open-Source-Entwickler, die ihre Software nicht im Rahmen einer geschäftlichen Tätigkeit auf den Markt bringen, fallen nicht unter die Produkthaftung. Die Abgrenzung folgt der CRA-Logik: Reine Bereitstellung in öffentlichen Repositories ist keine Marktbereitstellung.
Die bisherige Produkthaftungsrichtlinie von 1985 war auf körperliche Gegenstände ausgelegt. Die neue Richtlinie stellt klar: Software -ob eigenständig oder eingebettet -ist ein Produkt im Sinne des Haftungsrechts. Das umfasst Betriebssysteme, Anwendungen, Bibliotheken, Firmware und SaaS-Komponenten.
Bisher beschränkte sich die Produkthaftung auf Personen- und Sachschäden. Die neue Richtlinie erweitert den Schadensbegriff: Datenverlust und Datenvernichtung sind jetzt eigenständige Haftungsgründe. Wenn eine Schwachstelle in einer Open-Source-Komponente zum Verlust von Kundendaten führt, haften Sie als Hersteller.
Die alte Richtlinie begrenzte die Haftung auf einen Höchstbetrag. Diese Obergrenze ist entfallen. Bei einem großflächigen Sicherheitsvorfall, der Tausende oder Millionen Nutzer betrifft, gibt es keine gesetzliche Haftungsobergrenze mehr.
Geschädigte können künftig die Offenlegung von Beweismitteln verlangen. Wenn Sie keine Dokumentation über Ihre Open-Source-Governance vorlegen können, kann das Gericht eine Beweislastumkehr anordnen: Sie müssen dann beweisen, dass Ihr Produkt nicht fehlerhaft war -statt der Geschädigte den Fehler beweisen muss.
Art. 7 der Richtlinie legt fest, wann ein Produkt als fehlerhaft gilt. Die Kriterienliste in Art. 7 Abs. 2 nennt unter Buchstabe f ausdrücklich die "sicherheitsrelevanten Cybersicherheitsanforderungen". Damit ist Cybersicherheit nicht mehr nur eine regulatorische Pflicht aus dem CRA, sondern ein haftungsrechtliches Merkmal: Verfehlt Ihr Produkt einschlägige Cybersicherheitsanforderungen, wird es im Sinne der Produkthaftung als fehlerhaft bewertet - unabhängig davon, ob die eigentliche Funktion noch gegeben ist. Ungepatchte Schwachstellen, fehlende Sicherheitsupdates oder eine ungepflegte Open-Source-Lieferkette sind damit direkte Fehlerindizien.
Bei technisch komplexen Produkten -und Software ist per Definition technisch komplex -wird die Beweislast zugunsten des Geschädigten erleichtert. Das bedeutet: Es wird einfacher, Sie als Hersteller erfolgreich zu verklagen.
Die Entfernung der maximalen Schadenshöhe macht großflächige Sicherheitsvorfälle zu einem existenziellen Risiko. Wenn eine Schwachstelle in einer Open-Source-Bibliothek Millionen Nutzer betrifft, kann der Gesamtschaden die Existenz Ihres Unternehmens bedrohen.
Wer keine nachweisbare Sorgfalt bei der Komponentenauswahl und -pflege dokumentieren kann, riskiert die Umkehr der Beweislast. Das bedeutet: Nicht der Kläger muss den Fehler beweisen, sondern Sie müssen beweisen, dass Ihr Produkt fehlerfrei war.
Die wichtigsten Artikel der neuen Produkthaftungsrichtlinie:
Die Produkthaftungsrichtlinie und der Cyber Resilience Act ergänzen sich: Der CRA definiert, welche Sicherheitsanforderungen Produkte erfüllen müssen. Die Produkthaftungsrichtlinie definiert, was passiert, wenn sie es nicht tun. Ein Verstoß gegen CRA-Anforderungen kann als Beleg für die Fehlerhaftigkeit des Produkts herangezogen werden. Umgekehrt schützt die Einhaltung des CRA nicht automatisch vor Produkthaftungsansprüchen -sie ist aber ein starkes Indiz für die Erfüllung der Sorgfaltspflicht.
Sie haften für Ihr Gesamtprodukt, einschließlich aller integrierten Komponenten. Eine Schwachstelle in einer transitiven Abhängigkeit kann Ihre Haftung auslösen, auch wenn Sie die Komponente nie bewusst ausgewählt haben. Die Sorgfaltspflicht erstreckt sich auf Ihre gesamte Software-Lieferkette.
| Haftungsrisiko | OTTRIA-Leistung |
|---|---|
| Fehlende Sorgfalt bei Komponentenauswahl | Dokumentierte Bewertung aller OSS-Abhängigkeiten: Projekt-Gesundheit, Maintainer-Reife, bekannte Schwachstellen |
| Ungepatchte Schwachstellen | Laufende Überwachung, Upstream-Fixes, Patches auch für verwaiste Projekte |
| Fehlende Dokumentation | Prüffähige Maßnahmenhistorie: Was wurde wann gemacht, von wem, mit welchem Ergebnis |
| Unbekannte Abhängigkeiten | SBOM-Auswertung und -Überwachung einschließlich transitiver Abhängigkeiten |
| Keine Nachweise für Beweislast | Systematische OSS-Governance-Dokumentation als Nachweis der Sorgfalt |
| Verwaiste Projekte in der Lieferkette | Wartung übernehmen oder Patches bereitstellen |
Im Haftungsfall entscheidet die Dokumentation.
Das reduziert Ihr Haftungsrisiko durch dokumentierte Sorgfalt: Wenn Sie nachweisen können, dass Sie bei der Auswahl und Pflege Ihrer Open-Source-Komponenten systematisch und nach dem Stand der Technik vorgegangen sind, ist eine Beweislastumkehr deutlich unwahrscheinlicher.
Die neue EU-Produkthaftungsrichtlinie ist eine Richtlinie, keine Verordnung. Sie muss national umgesetzt werden. In Deutschland wird sie das bestehende Produkthaftungsgesetz (ProdHaftG) ändern oder ersetzen. Die Umsetzungsfrist für die Mitgliedstaaten läuft.
Das deutsche Produkthaftungsgesetz basiert auf der alten EU-Richtlinie von 1985. Es kennt bisher keine Softwarehaftung im eigentlichen Sinne und keine Haftung für Datenverlust. Die nationale Umsetzung wird diese Lücken schließen. Bis dahin gilt: Die Richtlinie ist zwar nicht direkt anwendbar, aber Gerichte können das nationale Recht bereits richtlinienkonform auslegen.
Da es sich um eine Richtlinie handelt, können nationale Umsetzungen voneinander abweichen. Unternehmen, die in mehreren EU-Ländern Produkte vertreiben, sollten die jeweilige nationale Umsetzung beobachten.
Dokumentierte Sorgfalt ist Ihr bester Schutz gegen Produkthaftungsansprüche. Lassen Sie uns gemeinsam prüfen, wie Ihre Open-Source-Governance aufgestellt ist.
Produkthaftungs-Factsheet herunterladen (PDF)
Weiterlesen