Haftung für Updates und Cybersecurity unter der neuen Produkthaftung

Kurz beantwortet: Nach der neuen EU-Produkthaftung endet Ihre Verantwortung als Hersteller nicht mit dem Inverkehrbringen, denn die Kontrolle des Herstellers umfasst auch die Bereitstellung von Software-Updates. Ein unterlassenes verfügbares Sicherheitsupdate kann deshalb zum Haftungsfall werden, sodass ein funktionierendes Schwachstellen- und Update-Management zur produkthaftungsrelevanten Daueraufgabe wird. Maßgeblich wird das für Produkte, die ab dem 9. Dezember 2026 in Verkehr gebracht oder in Betrieb genommen werden.

Software wird nach dem Verkauf nicht fertig, sie wird gepatcht, aktualisiert, weiterentwickelt. Genau hier setzt die neue EU-Produkthaftung an: Die Verantwortung endet nicht mit dem Inverkehrbringen. Wer Updates liefern kann, trägt das Haftungsrisiko weiter, ein unterlassenes Sicherheitsupdate kann zum Haftungsfall werden. Maßgeblich ist das für Produkte, die ab dem 9. Dezember 2026 in Verkehr gebracht oder in Betrieb genommen werden.

Warum reicht die Kontrolle des Herstellers in die Zukunft?

Die Richtlinie (EU) 2024/2853 knüpft die Haftung an den Begriff der „Kontrolle des Herstellers“. Nach ihrem Art. 4 Nr. 5 RL 2024/2853 umfasst diese Kontrolle ausdrücklich auch die Bereitstellung von Software-Updates und -Upgrades, und zwar sowohl, wenn der Hersteller sie selbst vornimmt, als auch, wenn er dazu in der Lage ist. Zusammen mit Art. 7 Abs. 2 lit. e RL 2024/2853 und Art. 11 Abs. 2 RL 2024/2853 folgt daraus: Ein Produkt kann auch dann als fehlerhaft gelten, wenn der Fehler erst nach dem Inverkehrbringen entsteht und der Hersteller ihn durch ein zur Sicherheit erforderliches Update hätte beheben können, es aber unterlässt. Eine eigene Pflicht zu Updates schafft die Richtlinie dabei nicht (Erwägungsgrund 51). Diese fortwirkende Kontrolle setzt voraus, dass Software überhaupt als Produkt gilt, dazu der Beitrag zur neuen Einordnung von Software als Produkt.

Wieso wird Cybersicherheit zur Haftungsfrage?

Damit verschmelzen zwei Welten, die bisher getrennt gedacht wurden: Produktsicherheit und Cybersicherheit. Wenn die berechtigte Sicherheitserwartung an ein Softwareprodukt auch den Schutz vor bekannten Schwachstellen umfasst, wird das Ausbleiben eines verfügbaren Sicherheitspatches haftungsrelevant. Für Anbieter heißt das: Ein funktionierendes Schwachstellen- und Update-Management ist nicht mehr nur eine Frage der Kundenzufriedenheit oder der NIS-2- und Cyber-Resilience-Pflichten, sondern auch der Produkthaftung. Dieselbe Pflicht zur Produktbeobachtung trägt die deliktische Produzentenhaftung, dazu der Beitrag zur Produzentenhaftung nach § 823 BGB.

Bleibt der Entwicklungsrisiko-Einwand bestehen?

Bisher konnte sich ein Hersteller nach § 1 Abs. 2 Nr. 5 ProdHaftG darauf berufen, dass ein Fehler nach dem Stand von Wissenschaft und Technik beim Inverkehrbringen nicht erkennbar war. Die Richtlinie behält diesen Einwand in Art. 11 RL 2024/2853 im Grundsatz bei, erlaubt den Mitgliedstaaten in Art. 18 RL 2024/2853 aber, bestehende Ausnahmen beizubehalten oder unter engen Voraussetzungen für bestimmte Produktkategorien neu einzuführen. Das vom Bundestag beschlossene deutsche Gesetz sieht den Entwicklungsrisiko-Ausschluss weiterhin vor. Bei Software, die Sie weiter kontrollieren, kommt es für den Einwand allerdings auf den Stand von Wissenschaft und Technik während des gesamten Kontrollzeitraums an. Welche Einreden bei Software nicht tragen, vertieft der zugehörige Beitrag.

Was sollten Sie jetzt vorbereiten?

• Update-Prozess dokumentieren: Wer wann welche Sicherheitslücke wie schnell schließt, sollte nachvollziehbar geregelt sein.
• Supportzeiträume klar kommunizieren: Wie lange ein Produkt Updates erhält, gehört transparent in Produktbeschreibung und Vertrag.
• Lieferkette einbeziehen: Auch Komponenten und verbundene Dienste Dritter fallen in den Blick; klären Sie vertraglich, wer für deren Updates einsteht.
• Beweisvorsorge treffen: Angesichts der Beweiserleichterungen für Geschädigte (Art. 10 RL 2024/2853) wird die eigene, saubere Dokumentation zum zentralen Mittel, um diese Vermutungen zu entkräften; an der verschuldensunabhängigen Haftung selbst ändert sie nichts. Welche Vermutungsregeln und Offenlegungsansprüche konkret greifen, ordnet der Beitrag zu Beweislast und Offenlegung nach der PLD ein.

Die neue Produkthaftung macht aus dem Update-Management eine rechtliche Daueraufgabe. Wer sie früh organisiert, senkt das Risiko eines Produktfehlers und kann im Streitfall belegen, wann welche Lücke geschlossen wurde. Die Haftung bleibt verschuldensunabhängig; die Dokumentation hilft vor allem gegen die Vermutungen nach Art. 10 RL 2024/2853. Bringen Sie ein Produkt mit digitalen Elementen in Verkehr, überschneidet sich diese Update-Verantwortung mit dem Cyber Resilience Act: Er verlangt einen Unterstützungszeitraum von grundsätzlich mindestens fünf Jahren, in dem Schwachstellen wirksam zu behandeln sind (Art. 13 Abs. 8 CRA), und verpflichtet Sie seit dem 11. September 2026, aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle zu melden (Art. 14 CRA). Vertiefend dazu der Beitrag zur CRA-Meldepflicht und, bei KI-Komponenten, der Beitrag zum CRA für KI-Software. Die Gesamtübersicht über alle Stationen der Reform bündelt der Leitfaden zur Produkthaftung für Software & KI.

Wie das in der Praxis aussieht

Ein Beispiel, wie es in dieser Form häufig vorkommt: Ein Hersteller vernetzter Kaffeevollautomaten für Büros und Gastronomie mit rund 130 Mitarbeitenden spielt Updates über eine Cloud auf. Sicherheitskorrekturen werden bisher mit neuen Funktionen gebündelt und deshalb oft um Wochen verschoben; wer das entscheidet, ist nirgends festgelegt. Die Kontrolle des Herstellers umfasst die Bereitstellung von Updates, und ein unterlassenes, verfügbares Sicherheitsupdate kann zum Haftungsfall werden. Eine eigene Pflicht zu Updates schafft die Richtlinie nicht. Der Cyber Resilience Act verlangt aber einen Unterstützungszeitraum von grundsätzlich mindestens fünf Jahren, in dem Schwachstellen wirksam zu behandeln sind.

Danach trennen sich die Wege. Sicherheitsrelevante Korrekturen werden von Funktionsupdates getrennt und nach einer festen Bewertung zeitnah ausgeliefert; wer die Bewertung trifft, steht in einer Zuständigkeitsregel. Weil Geschädigte Beweiserleichterungen haben, wird jede Update-Entscheidung mit Datum und Begründung festgehalten. Der Unterstützungszeitraum je Modell kommt in Produktbeschreibung und Vertrag, und für zugekaufte Komponenten und verbundene Dienste wird vertraglich geregelt, wer für deren Updates einsteht. Am Ende stehen ein dokumentierter Update-Prozess und Belege dafür, wann welche Lücke geschlossen wurde. Wie Zuständigkeiten und Checklisten dafür aussehen, zeigt das Rechtssystem.

Häufige Fragen

Endet die Herstellerhaftung mit dem Inverkehrbringen?

Nein. Nach Art. 4 Nr. 5 der Richtlinie (EU) 2024/2853 umfasst die Kontrolle des Herstellers auch die Bereitstellung von Software-Updates. In Verbindung mit Art. 7 Abs. 2 lit. e und Art. 11 Abs. 2 kann ein Produkt deshalb auch dann als fehlerhaft gelten, wenn der Fehler erst später entsteht und der Hersteller ihn durch ein zur Sicherheit erforderliches Update hätte beheben können.

Warum wird Cybersicherheit zur Haftungsfrage?

Umfasst die berechtigte Sicherheitserwartung an ein Softwareprodukt auch den Schutz vor bekannten Schwachstellen, wird das Ausbleiben eines verfügbaren Sicherheitspatches haftungsrelevant, sodass ein funktionierendes Update-Management nicht mehr allein eine Frage der Kundenzufriedenheit ist.

Bleibt der Entwicklungsrisiko-Einwand bestehen?

Die Richtlinie behält den Einwand im Grundsatz bei, erlaubt den Mitgliedstaaten aber, bestehende Ausnahmen beizubehalten oder unter engen Voraussetzungen für bestimmte Produktkategorien neu einzuführen (Art. 18). Das vom Bundestag beschlossene deutsche Gesetz sieht den Entwicklungsrisiko-Ausschluss weiterhin vor.

Was sollten Anbieter jetzt vorbereiten?

Anbieter sollten ihren Update-Prozess dokumentieren, Supportzeiträume transparent kommunizieren, die Lieferkette vertraglich einbeziehen und angesichts der Beweiserleichterungen für Geschädigte für eine saubere eigene Dokumentation sorgen.

Wer entscheidet, ob ein Sicherheitsupdate ausgeliefert wird, und wie das dokumentiert ist, ist oft nicht festgelegt. Im Rechtssystem entstehen Zuständigkeiten, Dokumentation und Checklisten, mit denen Ihr Team Update-Entscheidungen nachvollziehbar trifft. Rechtssystem: Zuständigkeiten für Updates und Sicherheit

Sie wollen Ihr Update- und Sicherheitsmanagement so aufstellen, dass es Produkthaftung und CRA berücksichtigt? In einem 60-minütigen Strategiegespräch klären wir, worauf es bei Ihrem Produkt ankommt. Für die vertragliche Umsetzung begleitet Sie die Rechtsberatung im IT-Recht.