Updates, verbundene Dienste und die Kontrolle des Herstellers: Haftung in der Nachmarktphase

Problem in der Praxis

Moderne Produkte sind nach dem Verkauf nicht fertig: Cloud-Backends, Companion-Apps und Update-Kanäle begleiten sie über Jahre. Damit ist die Kontrollzone des Herstellers groß, oft ohne dass sie jemand bewusst gezogen hätte. End-of-Life-Entscheidungen laufen als Vertriebs- oder Supportthema, nicht als Haftungsentscheidung; verbundene Dienste betreibt ein Dienstleister, ohne dass die Verantwortung geklärt ist; der Update-Kanal besteht fort, obwohl der Vertrieb längst eingestellt wurde. Nach Art. 4 Nr. 5 Buchst. b reicht genau diese fortbestehende Fähigkeit, um in der Kontrolle zu bleiben.

Hinzu kommt die Verwechslung von Pflicht und Haftung: Teams suchen in der Produkthaftungsrichtlinie nach Supportzeiträumen und Updatepflichten und finden nichts, weil dort nichts steht; die Richtlinie sieht ausdrücklich keine Verpflichtung zur Bereitstellung von Updates oder Upgrades vor (Erwägungsgrund 51). Supportzeitraum, Schwachstellenmanagement und Meldepflichten regelt für Produkte mit digitalen Elementen der CRA (cra-Track). Die Produkthaftungsrichtlinie beantwortet die andere Frage: was es zivilrechtlich kostet, wenn in der eigenen Kontrollzone ein sicherheitserhaltendes Update fehlt und daraus ein Schaden entsteht.

CISO-Einordnung

Die Kontrolle des Herstellers (Art. 4 Nr. 5) hat zwei Arme. Erstens Handlungen: die Integration, Verbindung oder Bereitstellung einer Komponente einschließlich Software-Updates oder -Upgrades sowie Änderungen des Produkts, vom Hersteller selbst vorgenommen oder bei Dritten genehmigt. Zweitens, operativ entscheidend, die bloße Fähigkeit: Der Hersteller ist in der Lage, Software-Updates oder -Upgrades selbst bereitzustellen oder durch einen Dritten bereitstellen zu lassen (Buchst. b). Wer einen funktionierenden Update-Kanal hat, ist in der Kontrollzone, auch ohne ihn zu nutzen.

Innerhalb dieser Zone wirken drei Mechanismen zusammen. Erstens der Beurteilungszeitpunkt: Statt des Inverkehrbringens zählt der Zeitpunkt, zu dem das Produkt die Kontrolle des Herstellers verlassen hat (Art. 7 Abs. 2 Buchst. e); die Fehlerfrage (pld-002) wird also gegen einen späteren Stand beantwortet. Zweitens die Grenze des Später-entstanden-Einwands: Nach Art. 11 Abs. 1 Buchst. c kann sich ein Wirtschaftsakteur entlasten, wenn wahrscheinlich ist, dass die Fehlerhaftigkeit beim Inverkehrbringen noch nicht bestand oder erst danach entstanden ist. Art. 11 Abs. 2 nimmt diesem Einwand die Wirkung, wenn die Fehlerhaftigkeit zurückgeht auf a) einen verbundenen Dienst, b) Software einschließlich Software-Updates oder -Upgrades, c) "ein Fehlen von Software-Updates oder -Upgrades, die zur Aufrechterhaltung der Sicherheit erforderlich sind", oder d) eine wesentliche Änderung des Produkts, jeweils sofern sie der Kontrolle des Herstellers unterliegt. Erwägungsgrund 51 begründet das mit der Verantwortung für Schwachstellen bei sich wandelnden Cybersicherheitsrisiken und zieht zugleich die Grenze: Liegt die Bereitstellung oder Installation außerhalb der Kontrolle des Herstellers, etwa weil der Eigentümer des Produkts bereitgestellte Updates oder Upgrades nicht installiert, greift die Haftungsverlängerung nicht.

Drittens die wesentliche Änderung: Wer ein Produkt außerhalb der Kontrolle des Herstellers wesentlich verändert und es anschließend auf dem Markt bereitstellt oder in Betrieb nimmt, gilt selbst als Hersteller (Art. 8 Abs. 2). Was wesentlich ist, bestimmt Art. 4 Nr. 18 primär nach den Maßstäben des Produktsicherheitsrechts; enthält es keinen Maßstab, zählen Änderungen, die die ursprüngliche Leistung, den Zweck oder die Art des Produkts außerhalb der ursprünglichen Risikobewertung verändern, sowie Änderungen, die die Gefahrenart verändern, eine neue Gefahr schaffen oder das Risikoniveau erhöhen. Die produktrechtliche Parallelfigur für Maschinen erklärt mvo-005; hier zählt die Haftungsfolge. Zeitlich gilt: Erfolgt die wesentliche Änderung durch ein Software-Update oder -Upgrade oder durch kontinuierliches Lernen eines KI-Systems, gilt das veränderte Produkt als zum Zeitpunkt der tatsächlichen Änderung bereitgestellt oder in Betrieb genommen (Erwägungsgrund 40), und die zehnjährige Ausschlussfrist beginnt mit der erneuten Bereitstellung neu (Art. 17 Abs. 1 Buchst. b). In Verbindung mit dem Anwendungsstichtag heißt das: Auch ein vor dem 09.12.2026 in Verkehr gebrachtes Produkt kann durch eine spätere wesentliche Änderung in das neue Haftungsregime hineinwachsen (Art. 2 Abs. 1 in der Fassung der Berichtigung ABl. L, 2026/90364 vom 07.05.2026, in Verbindung mit Erwägungsgrund 40; Zeitplan in pld-001).

Entlastung bleibt möglich: Wer nach Art. 8 Abs. 2 als verändernder Hersteller gilt, haftet nicht für Produktteile, die von der Änderung nicht betroffen sind (Art. 11 Abs. 1 Buchst. g). Und der Entwicklungsrisiko-Einwand (Art. 11 Abs. 1 Buchst. e) erstreckt sich ausdrücklich auf den Zeitraum, in dem sich das Produkt unter der Kontrolle des Herstellers befand: Maßstab ist der objektive Stand von Wissenschaft und Technik, auch für die Erkennbarkeit von Schwachstellen in der Nachmarktphase.

Umsetzungsperspektive

Die Nachmarkthaftung ist ein Inventar- und Nachweisthema:

• Kontrollzonen-Inventar: je Produkt erfassen, ob und wie Update-Fähigkeit besteht (eigener Kanal, delegiert an Dritte), welche verbundenen Dienste zum Produkt gehören und welche Dritt-Änderungen genehmigt sind. Jede Genehmigung ist ein Kontrolltatbestand (Art. 4 Nr. 5 Buchst. a).
• End-of-Life als dokumentierte Entscheidung: festhalten, wann die Update-Fähigkeit tatsächlich endet, nicht nur der Vertrieb oder der beworbene Support. Solange der Kanal besteht, besteht die Kontrollzone nach Art. 4 Nr. 5 Buchst. b fort.
• Update-Nachweise führen: was wurde wann bereitgestellt, wie kommuniziert, wie installiert (automatisch oder durch den Nutzer). Die Grenze des Erwägungsgrunds 51 lässt sich im Streitfall nur mit diesen Nachweisen ziehen.
• Change-Klassifizierung: eigene Major-Updates, Upgrades und KI-Weiterlernen auf wesentliche Änderung prüfen und das Ergebnis dokumentieren, einschließlich der Fristfolge des Art. 17 Abs. 1 Buchst. b; für zugekaufte und veränderte Produkte die Herstellerrolle nach Art. 8 Abs. 2 im Blick behalten.
• Fristenbuchhaltung je Produkt und Version: Inverkehrbringen, Kontrollende, wesentliche Änderungen; ohne diese Daten ist weder das anwendbare Regime (pld-001) noch der Fristlauf (pld-004) belegbar.
• Verzahnung mit CRA-Prozessen: Dieselben PSIRT- und Update-Prozesse liefern dort die Pflichten-Compliance (Supportzeitraum, Meldepflichten; cra-Track) und hier die Haftungs- und Beweisfestigkeit. Ein Programm, zwei getrennte Nachweisziele.

Typische Fehler

1. Support eingestellt, Update-Kanal behalten und angenommen, damit ende die Verantwortung; die Kontrolle nach Art. 4 Nr. 5 Buchst. b endet erst mit der Fähigkeit zur Bereitstellung.
2. In der Produkthaftungsrichtlinie Updatepflichten und Supportzeiträume suchen; die stehen im CRA (cra-Track). Die Richtlinie verlängert die Haftung, sie begründet keine Bereitstellungspflicht.
3. Verbundene Dienste nicht als Haftungsgegenstand führen, obwohl ihr Fehler den Später-entstanden-Einwand entfallen lässt (Art. 11 Abs. 2 Buchst. a) und sie Komponenten des Produkts sind (pld-001).
4. Keine Nachweise, wann ein Produkt die Kontrolle verlassen hat; der verschobene Beurteilungszeitpunkt (Art. 7 Abs. 2 Buchst. e) ist dann im Prozess nicht belegbar.
5. Major-Updates und KI-Weiterlernen ohne Wesentlichkeitsprüfung ausrollen und Neustart der Ausschlussfrist und Regimewechsel übersehen (Art. 17 Abs. 1 Buchst. b, Erwägungsgrund 40).
6. Dritt-Updates und Modifikationen pauschal genehmigen, ohne die Genehmigung als Kontrolltatbestand zu steuern und zu dokumentieren (Art. 4 Nr. 5 Buchst. a).

Risiken und Trade-offs

Die Kontrollzone ist gestaltbar, aber jede Gestaltung kostet. Wer die Update-Fähigkeit hart beendet, verkürzt die haftungsrelevante Kontrolle, kollidiert aber mit Kundenerwartungen und unter Umständen mit produktrechtlichen Supportpflichten (cra-Track); wer lange Update-Zusagen gibt, stärkt das Marktvertrauen, verlängert aber den Zeitraum, in dem fehlende sicherheitserhaltende Updates zum Haftungsfall werden können (Art. 11 Abs. 2 Buchst. c).

Ein zweiter Trade-off liegt im Installationsweg: Wo der Hersteller Updates bereitgestellt hat und die Installation außerhalb seiner Kontrolle liegt, endet dort die Haftungsverlängerung (Erwägungsgrund 51); ungepatchte Flotten bleiben aber ein reales Sicherheits- und Reputationsrisiko, und die Abgrenzung trägt im Streitfall nur mit sauberen Bereitstellungsnachweisen. Drittens das Änderungsmanagement: Eine strenge Wesentlichkeitsprüfung vor großen Updates schützt vor unbemerktem Fristneustart und Regimewechsel, verlangsamt aber Release-Zyklen; eine zu lockere Praxis verlagert das Risiko in den Schadensfall, in dem Rolle und Fristen rückwirkend bestimmt werden.

Entscheidungspunkte

• Für welche Produkte besteht Update-Fähigkeit im Sinne des Art. 4 Nr. 5 Buchst. b, und wann und wie soll sie kontrolliert enden?
• Welche verbundenen Dienste gehören zu welchen Produkten, wer betreibt sie, und wie sind Verantwortung und Nachweise geregelt?
• Wie werden Bereitstellung, Kommunikation und Installationswege von Sicherheitsupdates nachweisbar dokumentiert?
• Welche Änderungen durchlaufen eine Prüfung auf wesentliche Änderung, wer entscheidet, und wo werden Ergebnis und Fristfolgen festgehalten?
• Wie stellen wir die Trennung sicher: CRA-Pflichten dort, Haftungs- und Beweisfestigkeit hier, ohne doppelte oder widersprüchliche Prozesse?

Praktische Empfehlungen

1. Inventarisieren Sie die Kontrollzone je Produkt: Update-Kanäle (eigene und delegierte), verbundene Dienste, genehmigte Dritt-Änderungen.
2. Behandeln Sie End-of-Life- und Supportzeitraum-Entscheidungen als dokumentierte Haftungsentscheidungen; halten Sie fest, wann die Update-Fähigkeit endet, nicht nur den Vertriebsstopp.
3. Führen Sie Update-Nachweise über Bereitstellung, Kommunikation und Installationsweg; die Grenze des Erwägungsgrunds 51 trägt nur mit Belegen.
4. Prüfen Sie Major-Updates, Upgrades und KI-Weiterlernen vor dem Rollout auf wesentliche Änderung und dokumentieren Sie Ergebnis und Fristfolgen (Art. 17 Abs. 1 Buchst. b).
5. Regeln Sie mit Dienstleistern und Zulieferern, wer verbundene Dienste betreibt und wer Updates bereitstellen darf; behandeln Sie jede Genehmigung als Kontrolltatbestand mit Governance.
6. Verzahnen Sie CRA-Schwachstellenprozesse und Haftungs-Nachweisführung in einem Programm mit getrennten Zielen; die Beweisseite (Offenlegung nach Art. 9) vertieft pld-004.

Relevante Normreferenzen

• Richtlinie (EU) 2024/2853 (neue Produkthaftungsrichtlinie): Art. 4 Nr. 5 (Kontrolle des Herstellers), Art. 4 Nr. 18 (wesentliche Änderung), Art. 7 Abs. 2 Buchst. e, Art. 8 Abs. 2, Art. 11 Abs. 1 Buchst. c, e und g, Art. 11 Abs. 2, Art. 17 Abs. 1 Buchst. b; Erwägungsgründe 40 und 51; ABl. L, 2024/2853, 18.11.2024, in der Fassung der Berichtigung ABl. L, 2026/90364 vom 07.05.2026 (betrifft Art. 2 Abs. 1).
• Cyber Resilience Act (VO (EU) 2024/2847): Pflichtenseite für Produkte mit digitalen Elementen (Supportzeitraum, Schwachstellenmanagement, Meldepflichten); in der Richtlinie (EU) 2024/2853 nicht genannt (cra-Track).
• Maschinenverordnung (VO (EU) 2023/1230): produktrechtliche Figur der wesentlichen Veränderung bei Maschinen (mvo-005); in der Richtlinie (EU) 2024/2853 nicht genannt (mvo-Track).