Produkthaftung für Software ab 9. Dezember 2026: Was die Richtlinie (EU) 2024/2853 für IT-Delivery ändert

Der Stichtag: Was am 9. Dezember 2026 tatsächlich passiert

Die Richtlinie (EU) 2024/2853 über die Haftung für fehlerhafte Produkte datiert vom 23. Oktober 2024 (Beschluss des Rates: 10. Oktober 2024) und wurde am 18. November 2024 im Amtsblatt veröffentlicht (siehe https://eur-lex.europa.eu/eli/dir/2024/2853/oj). Sie hebt die Richtlinie 85/374/EWG mit Wirkung vom 9. Dezember 2026 auf (Art. 21), und die Mitgliedstaaten müssen ihre Umsetzungsvorschriften bis zu diesem Tag in Kraft setzen (Art. 22 Abs. 1).

Für die Praxis entscheidet Art. 2 Abs. 1 in der Fassung der Berichtigung vom 7. Mai 2026: Die Richtlinie gilt für Produkte, die nach dem 8. Dezember 2026 in Verkehr gebracht oder in Betrieb genommen werden, also ab dem 9. Dezember 2026 (siehe https://eur-lex.europa.eu/eli/dir/2024/2853/corrigendum/2026-05-07/oj). Für Produkte, die davor in Verkehr gebracht wurden, gilt nach Art. 21 weiter das alte Recht. Maßgeblich ist also das Datum des Inverkehrbringens — das erstmalige Bereitstellen auf dem Unionsmarkt (Art. 4 Nr. 8) —, nicht das Datum des Schadens. Wer ein Produkt außerhalb der Kontrolle des Herstellers wesentlich verändert und anschließend auf dem Markt bereitstellt oder in Betrieb nimmt, gilt als Hersteller (Art. 8 Abs. 2); für das veränderte Produkt beginnt die zehnjährige Ausschlussfrist neu (Art. 17 Abs. 1 Buchst. b).

In Deutschland setzt das Gesetz zur Modernisierung des Produkthaftungsrechts und zur Änderung weiterer Vorschriften die Richtlinie um (Regierungsentwurf: Bundestags-Drucksache 21/4297, siehe https://dserver.bundestag.de/btd/21/042/2104297.pdf). Der Bundestag hat den Entwurf am 4. März 2026 in erster Lesung beraten und an den Ausschuss für Recht und Verbraucherschutz überwiesen, der am 13. April 2026 angehört hat. Am 8. Oktober 2026 hat der Bundestag das Gesetz in der Fassung der Beschlussempfehlung des Ausschusses (Drucksache 21/8429) angenommen (siehe https://www.bundestag.de/dokumente/textarchiv/2026/kw10-de-produkthaftungsrecht-1150448 und https://www.bundesregierung.de/breg-de/aktuelles/produkthaftung-digitalisierung-ki-2399966). Das Gesetz tritt am 9. Dezember 2026 in Kraft (Artikel 17 Abs. 1 des Gesetzes); lediglich die Artikel 2 und 5 bis 16 – darunter die Bestimmung, dass das bisherige Produkthaftungsgesetz am 9. Dezember 2026 außer Kraft tritt – treten am Tag nach der Verkündung in Kraft (Artikel 17 Abs. 2). Für Produkte, die bis einschließlich 8. Dezember 2026 in Verkehr gebracht oder in Betrieb genommen wurden, bleibt das bisherige Produkthaftungsgesetz anwendbar (§ 23 ProdHaftG; siehe Bundesrats-Drucksache 584/26, https://dserver.bundestag.de/brd/2026/0584-26.pdf). Der Bundesrat hat in seiner 1069. Sitzung am 16. Oktober 2026 beschlossen, zu dem Gesetz keinen Antrag nach Art. 77 Abs. 2 GG auf Einberufung des Vermittlungsausschusses zu stellen (Bundesrats-Drucksache 584/26 (Beschluss), https://dserver.bundestag.de/brd/2026/0584-26B.pdf); damit ist das Gesetz zustande gekommen (Art. 78 GG). Die Verkündung im Bundesgesetzblatt war am 17. Oktober 2026 noch nicht erfolgt (siehe https://www.recht.bund.de/de/bundesgesetzblatt/bgbl-1/bgbl-1_node.html). Für die Planung ziehen Richtlinie und deutsches Gesetz die Grenze am selben Tag: Für Produkte, die bis einschließlich 8. Dezember 2026 in Verkehr gebracht oder in Betrieb genommen wurden, gilt das bisherige Recht (Art. 2 Abs. 1 der Richtlinie in der berichtigten Fassung, § 23 ProdHaftG), für spätere Produkte das neue.

Software ist ein Produkt — auch bei Bereitstellung als Cloud-Anwendung oder SaaS und als KI-System

Nach Art. 4 Nr. 1 ist „Produkt" jede bewegliche Sache; ausdrücklich zählen auch Elektrizität, digitale Konstruktionsunterlagen, Rohstoffe und Software dazu. Erwägungsgrund 13 stellt klar, dass Software unabhängig von der Art ihrer Bereitstellung oder Nutzung ein Produkt ist — gleichgültig, ob sie auf einem Gerät gespeichert, über ein Kommunikationsnetz oder Cloud-Technologien abgerufen oder als Software-as-a-Service bereitgestellt wird. Entwickler oder Hersteller von Software, einschließlich der Anbieter von KI-Systemen im Sinne der Verordnung (EU) 2024/1689, sollten nach Erwägungsgrund 13 als Hersteller betrachtet werden (verbindlich: Art. 4 Nr. 10; siehe https://eur-lex.europa.eu/eli/dir/2024/2853/oj). Dienstleistungen als solche erfasst die Richtlinie nicht; mit dem Produkt integrierte oder verbundene digitale Dienste zählen jedoch als Komponenten, wenn sie der Kontrolle des Herstellers unterliegen (Erwägungsgrund 17, Art. 4 Nr. 3 und 4).

Zwei Abgrenzungen sind wichtig. Informationen sind kein Produkt: Der Inhalt digitaler Dateien wie Mediendateien oder E-Books und der reine Quellcode fallen nicht unter die verschuldensunabhängige Haftung (Erwägungsgrund 13). Und freie und quelloffene Software, die außerhalb einer Geschäftstätigkeit entwickelt oder bereitgestellt wird, ist nach Art. 2 Abs. 2 ausgenommen. Wer Open-Source-Komponenten dagegen im Rahmen einer Geschäftstätigkeit in ein eigenes Produkt integriert, ist für dieses Produkt Hersteller.

Für Delivery-Organisationen folgt daraus eine Rollenfrage vor jeder Haftungsfrage. „Hersteller" ist nach Art. 4 Nr. 10, wer ein Produkt entwickelt, herstellt oder produziert, wer es entwerfen oder herstellen lässt oder durch Anbringen des eigenen Namens, der eigenen Marke oder eines anderen Erkennungszeichens auf dem Produkt als Hersteller auftritt, und wer es für den Eigenbedarf entwickelt, herstellt oder produziert. Das Bereitstellen auf dem Markt umfasst jede entgeltliche oder unentgeltliche Abgabe im Rahmen einer Geschäftstätigkeit (Art. 4 Nr. 7). Ob und wann individuell für einen Auftraggeber entwickelte Software „in Verkehr gebracht" wird, folgt aus den Definitionen in Art. 4 Nr. 7 bis 9; die Richtlinie trifft dazu keine ausdrückliche Regelung, die Auslegung obliegt letztlich den Gerichten.

Wer haftet: Hersteller, Komponentenhersteller und die „Kontrolle des Herstellers"

Art. 8 Abs. 1 benennt die haftenden Wirtschaftsakteure: den Hersteller des fehlerhaften Produkts, den Hersteller einer fehlerhaften Komponente, wenn diese unter der Kontrolle des Produktherstellers integriert oder verbunden wurde und die Fehlerhaftigkeit verursacht hat, und — bei Herstellern mit Sitz außerhalb der Union — Importeur und Bevollmächtigter, nachrangig der Fulfilment-Dienstleister, wenn weder ein Importeur noch ein Bevollmächtigter in der Union ansässig ist. Die Haftung des Produktherstellers erstreckt sich ausdrücklich auch auf Schäden durch eine fehlerhafte Komponente, die er unter seiner Kontrolle integriert hat. Wer ein Produkt außerhalb der Herstellerkontrolle wesentlich verändert und danach auf dem Markt bereitstellt oder in Betrieb nimmt, gilt als Hersteller (Art. 8 Abs. 2); Lieferanten haften nachrangig, wenn sie auf Aufforderung binnen eines Monats keinen Wirtschaftsakteur benennen (Art. 8 Abs. 3).

Der Schlüsselbegriff für Software ist die „Kontrolle des Herstellers" (Art. 4 Nr. 5). Sie liegt vor, wenn der Hersteller die Integration, Verbindung oder Bereitstellung einer Komponente einschließlich Software-Updates oder -Upgrades vornimmt oder genehmigt, wenn er das Produkt ändert — oder wenn er in der Lage ist, Software-Updates oder -Upgrades selbst oder durch einen Dritten bereitzustellen. Komponente ist dabei auch ein nicht-körperlicher Gegenstand oder ein verbundener Dienst (Art. 4 Nr. 4), also ein digitaler Dienst, ohne den das Produkt eine seiner Funktionen nicht ausführen könnte (Art. 4 Nr. 3).

Mehrere haftende Akteure können gesamtschuldnerisch in Anspruch genommen werden (Art. 12 Abs. 1); der Rückgriff richtet sich nach nationalem Recht (Art. 14). Für Softwarekomponenten gilt eine Besonderheit in Art. 12 Abs. 2: Ein Hersteller, der Software als Komponente in ein Produkt integriert, hat kein Rückgriffsrecht gegen den Hersteller einer fehlerhaften Softwarekomponente, wenn dieser zum Zeitpunkt des Inverkehrbringens ein Kleinst- oder Kleinunternehmen im Sinne der Empfehlung 2003/361/EG war und beide vertraglich vereinbart haben, auf dieses Recht zu verzichten. Der Verzicht muss also vereinbart sein; er ist keine Automatik.

Wann Software als fehlerhaft gilt: Cybersicherheit, Lernfähigkeit und Zusammenspiel

Ein Produkt ist fehlerhaft, wenn es nicht die Sicherheit bietet, die eine Person erwarten darf oder die nach Unionsrecht oder nationalem Recht vorgeschrieben ist (Art. 7 Abs. 1). Art. 7 Abs. 2 nennt beispielhaft Umstände, die in die Beurteilung einfließen. Für Software sind vier besonders einschlägig: die Auswirkungen der Fähigkeit des Produkts, nach dem Inverkehrbringen weiter zu lernen oder neue Funktionen zu erwerben (Buchst. c), die vernünftigerweise vorhersehbaren Auswirkungen anderer Produkte auf das Produkt, die voraussichtlich zusammen mit ihm verwendet werden, auch durch eine Verbindung (Buchst. d), der Zeitpunkt des Inverkehrbringens oder — wenn der Hersteller die Kontrolle behält — der Zeitpunkt, in dem das Produkt die Kontrolle des Herstellers verlässt (Buchst. e), und die einschlägigen Produktsicherheitsanforderungen einschließlich sicherheitsrelevanter Cybersicherheitsanforderungen (Buchst. f).

Erwägungsgrund 32 benennt den Zusammenhang ausdrücklich: Ein Produkt kann wegen Sicherheitslücken im Bereich der Cybersicherheit fehlerhaft sein, etwa wenn es die sicherheitsrelevanten Cybersicherheitsanforderungen nicht erfüllt. Das verbindet die Produkthaftung mit dem Cyber Resilience Act, dessen Meldepflichten nach Art. 14 seit dem 11. September 2026 gelten und dessen übrige Pflichten grundsätzlich ab dem 11. Dezember 2027 anzuwenden sind (Art. 71, siehe https://eur-lex.europa.eu/eli/reg/2024/2847/oj und CRA-Meldepflicht und SDLC-Fahrplan).

Zwei Begrenzungen betreffen den Maßstab: Ein Produkt ist nicht allein deshalb fehlerhaft, weil ein besseres Produkt — einschließlich Updates oder Upgrades — bereits in Verkehr gebracht wurde oder künftig in Verkehr gebracht wird (Art. 7 Abs. 3). Und nach Art. 11 Abs. 1 Buchst. d haftet der Wirtschaftsakteur nicht, wenn er beweist, dass die Fehlerhaftigkeit gerade darauf beruht, dass das Produkt rechtlichen Anforderungen entspricht.

Updates: Warum bei Software der Einwand „Fehler erst später entstanden" nicht greift

Das klassische Entlastungsargument lautet, der Fehler habe zum Zeitpunkt des Inverkehrbringens noch nicht bestanden (Art. 11 Abs. 1 Buchst. c). Für Software hat der Richtliniengeber dieses Argument beschnitten: Nach Art. 11 Abs. 2 wird der Wirtschaftsakteur nicht von der Haftung befreit, wenn die Fehlerhaftigkeit auf einen verbundenen Dienst, auf Software einschließlich Software-Updates oder -Upgrades, auf das Fehlen von Updates oder Upgrades, die zur Aufrechterhaltung der Sicherheit erforderlich sind, oder auf eine wesentliche Änderung des Produkts zurückzuführen ist — sofern diese Ursache der Kontrolle des Herstellers unterliegt.

Das macht den Update-Prozess haftungsrelevant: Ein fehlerhaftes Update, das der Hersteller ausliefert, und ein ausbleibendes Sicherheitsupdate, das er hätte bereitstellen können, fallen beide in die Kontrolle des Herstellers (Art. 4 Nr. 5). Die Richtlinie selbst begründet keine Pflicht, Sicherheitsupdates für einen bestimmten Zeitraum anzubieten; solche Pflichten ergeben sich aus anderen Regelwerken. Für Entscheidungen über Support-Ende und Patch-Priorisierung gilt: Solange ein Hersteller Updates bereitstellen kann, bleibt das Produkt nach Art. 4 Nr. 5 Buchst. b (Erwägungsgrund 19) in seiner Kontrolle; wie ein erklärtes Support-Ende wirkt, ist nicht ausdrücklich geregelt.

Ein weiterer Entlastungsgrund ist der Stand von Wissenschaft und Technik: Der Wirtschaftsakteur haftet nicht, wenn er beweist, dass der Fehler nach dem objektiven Stand der Wissenschaft und Technik zum Zeitpunkt des Inverkehrbringens oder in dem Zeitraum unter der Kontrolle des Herstellers nicht erkannt werden konnte (Art. 11 Abs. 1 Buchst. e). Die Mitgliedstaaten dürfen davon abweichen und bestehende Regelungen beibehalten, wonach auch dann gehaftet wird; Mitgliedstaaten, die solche Maßnahmen beibehalten möchten, müssen sie der Kommission spätestens am 9. Dezember 2026 mitteilen (Art. 18 Abs. 1).

Beweislast und Offenlegung: Was im Streitfall vorgelegt werden muss

Grundsatz bleibt: Der Kläger muss Fehlerhaftigkeit, Schaden und Ursächlichkeit beweisen (Art. 10 Abs. 1). Die Richtlinie baut dafür zwei Erleichterungen. Erstens die Offenlegung: Auf Antrag eines Klägers, der Tatsachen und Beweismittel vorgetragen hat, die die Plausibilität des Anspruchs ausreichend stützen, muss der Beklagte relevante Beweismittel in seiner Verfügungsgewalt offenlegen (Art. 9 Abs. 1), begrenzt auf das erforderliche und verhältnismäßige Maß (Art. 9 Abs. 3) und unter Berücksichtigung von Vertraulichkeit und Geschäftsgeheimnissen (Art. 9 Abs. 4 und 5). Auch der Beklagte kann Offenlegung vom Kläger verlangen (Art. 9 Abs. 2).

Zweitens die Vermutungen in Art. 10 Abs. 2 bis 4: Die Fehlerhaftigkeit wird vermutet, wenn der Beklagte relevante Beweismittel nicht offenlegt (Buchst. a), wenn der Kläger nachweist, dass das Produkt verbindlichen Produktsicherheitsanforderungen nicht entspricht, die vor dem eingetretenen Schaden schützen sollen (Buchst. b), oder dass der Schaden durch eine offensichtliche Funktionsstörung bei vernünftigerweise vorhersehbarem Gebrauch oder unter gewöhnlichen Umständen verursacht wurde (Buchst. c). Der ursächliche Zusammenhang wird vermutet, wenn das Produkt fehlerhaft ist und der Schaden typischerweise auf diesen Fehler zurückgeht (Abs. 3). Ist dem Kläger der Beweis trotz Offenlegung insbesondere wegen technischer oder wissenschaftlicher Komplexität übermäßig schwierig, gehen Gerichte von Fehler oder Kausalität aus, wenn der Kläger deren Wahrscheinlichkeit nachweist (Abs. 4). Alle Vermutungen sind widerlegbar (Abs. 5).

Für Delivery-Organisationen ist die Konsequenz praktisch: Wer im Streitfall Beweismittel nicht vorlegt, obwohl er dazu verpflichtet ist, riskiert die Fehlervermutung nach Art. 10 Abs. 2 Buchst. a. Evidenz, die ohnehin für den Cyber Resilience Act und Sicherheitsprozesse entsteht — Stücklisten (siehe SBOM-Pflichtfelder nach BSI TR-03183-2), Test- und Freigabenachweise, Schwachstellenbearbeitung —, kann im Streitfall als Verteidigungsgrundlage dienen und ist zugleich das, was der Kläger nach Art. 9 Abs. 1 anfordern kann.

Wessen Schaden gedeckt ist — und wessen nicht

Anspruchsberechtigt ist nach Art. 5 Abs. 1 jede natürliche Person, die einen durch ein fehlerhaftes Produkt verursachten Schaden erleidet; Rechtsnachfolger und Personen, die im Namen Geschädigter handeln, können den Anspruch ebenfalls geltend machen (Abs. 2). Ersatzfähig sind nach Art. 6 Abs. 1 nur drei Schadensarten: Tod oder Körperverletzung einschließlich medizinisch anerkannter Beeinträchtigungen der psychischen Gesundheit; Beschädigung oder Zerstörung von Sachen — ausgenommen das fehlerhafte Produkt selbst, ein durch eine fehlerhafte Komponente unter Herstellerkontrolle beschädigtes Produkt und Sachen, die ausschließlich für berufliche Zwecke verwendet werden —; sowie Vernichtung oder Beschädigung von Daten, die nicht für berufliche Zwecke verwendet werden. Bei Sachen genügt gemischte Nutzung (Erwägungsgrund 25); bei Daten schließt schon teilweise berufliche Nutzung den Anspruch aus (Erwägungsgrund 22). Daraus folgende Vermögensschäden sind eingeschlossen, immaterielle Schäden, soweit das nationale Recht sie ersetzt (Art. 6 Abs. 2).

Die Haftung gegenüber der geschädigten Person kann weder vertraglich noch durch nationales Recht beschränkt oder ausgeschlossen werden (Art. 15). Ansprüche aus nationalem Vertrags- und Deliktsrecht aus anderen Gründen als der Fehlerhaftigkeit des Produkts im Sinne der Richtlinie bleiben unberührt (Art. 2 Abs. 4 Buchst. b, Art. 6 Abs. 3).

Daraus folgt eine Einordnung, die für B2B-Delivery oft übersehen wird: Eigene Schäden eines Unternehmens, etwa Betriebsausfall oder beruflich genutzte Daten, sind nicht Gegenstand dieser Richtlinie. Das Risiko für Zulieferer und Integratoren besteht gegenüber geschädigten natürlichen Personen unmittelbar (Hersteller einer fehlerhaften Komponente, Art. 8 Abs. 1 Buchst. b, gesamtschuldnerisch nach Art. 12 Abs. 1) und im Innenverhältnis über Rückgriff (Art. 14) und die Frage, wer den Verzicht nach Art. 12 Abs. 2 vereinbart hat.

Verjährung und Ausschluss: Wie lange die Haftung nachwirkt

Ansprüche verjähren in drei Jahren ab dem Tag, an dem die geschädigte Person Kenntnis von Schaden, Fehlerhaftigkeit und der Identität des haftenden Wirtschaftsakteurs erlangt hat oder hätte erlangen müssen (Art. 16). Unabhängig davon erlischt der Anspruch zehn Jahre nach dem Inverkehrbringen oder der Inbetriebnahme des Produkts, bei einem wesentlich veränderten Produkt zehn Jahre nach dessen erneutem Bereitstellen — es sei denn, es wurde in der Zwischenzeit ein Verfahren eingeleitet (Art. 17 Abs. 1). Bei Körperverletzungen mit Latenzzeit verlängert sich die Ausschlussfrist auf 25 Jahre (Art. 17 Abs. 2).

Für Software mit langer Lebensdauer — Firmware, Industriesteuerungen, Medizin- und Fahrzeugsoftware — ergibt sich daraus ein Haftungshorizont von zehn Jahren ab dem Inverkehrbringen des Produkts, bei latenter Körperverletzung von bis zu 25 Jahren. Wesentliche Änderungen, auch per Update, lassen eine neue Frist beginnen (Art. 17 Abs. 1 Buchst. b, Erwägungsgründe 40 und 58), nicht wesentliche Updates dagegen nicht. Die Richtlinie enthält keine Aufbewahrungspflicht; welche Artefakte — Quellstände, Build-Artefakte, Stücklisten, Freigabeentscheidungen — man so lange vorhält, ist eine Governance-Entscheidung, die vor dem 9. Dezember 2026 getroffen sein sollte.

Zusammenspiel mit Cyber Resilience Act und AI Act

Die Produkthaftungsrichtlinie ersetzt weder den Cyber Resilience Act noch die KI-Verordnung. Zum Cyber Resilience Act hält dessen Erwägungsgrund 31 fest, dass die Richtlinie (EU) 2024/2853 ergänzend zur Verordnung wirkt; fehlende Sicherheitsaktualisierungen nach dem Inverkehrbringen können die Haftung des Herstellers auslösen. Art. 10 Abs. 2 Buchst. b macht den Verstoß gegen verbindliche Produktsicherheitsanforderungen zum Anknüpfungspunkt einer Fehlervermutung, und Art. 7 Abs. 2 Buchst. f nennt sicherheitsrelevante Cybersicherheitsanforderungen ausdrücklich. Wer die Anforderungen des Cyber Resilience Act erfüllt, entzieht diesem Vermutungstatbestand die Grundlage; eine Haftungsbefreiung folgt daraus nicht, denn die Fehlerhaftigkeit bemisst sich nach Art. 7 insgesamt. Wer sie verfehlt, liefert dem Kläger den Anknüpfungspunkt. Für KI-Systeme sieht Erwägungsgrund 13 vor, dass Anbieter im Sinne der KI-Verordnung als Hersteller betrachtet werden sollten; die Lernfähigkeit nach dem Inverkehrbringen ist ein ausdrücklicher Beurteilungsfaktor (Art. 7 Abs. 2 Buchst. c). Wie die Fristen und Pflichten der vier großen Regelwerke zusammenwirken, zeigt die Regulierungs-Kollision 2026.

Fahrplan bis zum 9. Dezember 2026

Die folgende Reihenfolge priorisiert nach Rollen- und Beweisrisiko. Jeder Schritt hängt an einer Norm der Richtlinie, nicht an einer Erwartung zur nationalen Umsetzung.

1. 1Zuerst — Inventar und Stichtag: Alle ausgelieferten Artefakte — Anwendungen, SaaS-Dienste, Firmware, Bibliotheken — erfassen und je Produkt festhalten, wann es erstmals in Verkehr gebracht wurde (Art. 2 Abs. 1, Art. 4 Nr. 1 und 8); Versionen, die als wesentliche Änderung einzustufen sind (auch per Update, Erwägungsgrund 40), gesondert vermerken. Produkte, die vor dem Stichtag in Verkehr gebracht wurden, bleiben im alten Recht (Art. 21); ein per Update wesentlich verändertes Produkt gilt zum Zeitpunkt der tatsächlichen Änderung als bereitgestellt (Erwägungsgrund 40), Updates ohne wesentliche Änderung lassen die Ausschlussfrist des Originalprodukts unberührt (Erwägungsgrund 58).
2. 2Rolle je Artefakt klären: Hersteller, Komponentenhersteller, Bevollmächtigter, Importeur oder Lieferant (Art. 4 Nr. 10, 14 und 15, Art. 8). Wer unter eigenem Namen auftritt oder außerhalb der Herstellerkontrolle wesentlich ändert und bereitstellt, gilt als Hersteller (Art. 4 Nr. 10 Buchst. b, Art. 8 Abs. 2).
3. 3Update- und Supportpolicy festschreiben: Supportzeitraum, Triage von Schwachstellen, Kriterien für Sicherheitsupdates, Kommunikation des Support-Endes. Diese Entscheidungen sind für die Beurteilung der Herstellerkontrolle relevant (Art. 4 Nr. 5, Art. 11 Abs. 2).
4. 4Evidenz je Release standardisieren: Stückliste, Test- und Freigabenachweise, Schwachstellenbearbeitung, Entscheidungsprotokolle — auffindbar und für Offenlegungsanträge nutzbar (Art. 9 und 10). Den Aufbewahrungshorizont an Art. 17 ausrichten (die Richtlinie enthält keine Aufbewahrungspflicht).
5. 5Lieferantenverträge prüfen: Haftungsketten, Rückgriff und Verzichtsklauseln. Für Softwarekomponenten von Kleinst- und Kleinunternehmen ist der Rückgriffsverzicht nach Art. 12 Abs. 2 eine bewusste Entscheidung; gegenüber Geschädigten wirkt keine Haftungsbeschränkung (Art. 15). Lieferanten, Verträge und Risiken erfasst das [Vendor-Assessment-Template](/templates/vendor-assessment).
6. 6CRA-Prozess und Produkthaftungs-Evidenz verbinden: Meldekette, PSIRT und Release-Gates so aufsetzen, dass dieselben Artefakte beide Zwecke erfüllen (siehe [CRA-Melde-Readiness-Check](/check/cra) und das [Delivery-Audit-Template](/templates/delivery-audit)).
7. 7Versicherung und Vertragsklauseln juristisch prüfen lassen: Die Richtlinie lässt eine vertragliche Beschränkung gegenüber Geschädigten nicht zu (Art. 15); wie Betriebs- und Produkthaftpflichtdeckung dazu stehen, klärt der Versicherer — nicht dieser Beitrag.
8. 8Verfahren beobachten: Das deutsche Gesetz ist nach dem Bundesratsbeschluss vom 16. Oktober 2026 (kein Antrag nach Art. 77 Abs. 2 GG, Bundesrats-Drucksache 584/26 (Beschluss)) zustande gekommen; als Nächstes folgt die Verkündung im Bundesgesetzblatt. Die Mitteilungen der Mitgliedstaaten nach Art. 18 bestimmen Details wie die Haftung für Entwicklungsrisiken.