Ein vernetztes Gerät fällt aus. Zunächst ist unklar, ob die Ursache in der Hardware, einer bestimmten Softwareversion, einem fehlenden Sicherheitsupdate oder einer späteren Veränderung liegt. Entwicklung, Qualitätsmanagement und Operations müssen nun klären: Welche Produktvarianten sind betroffen? Welche Komponenten wurden verarbeitet? Welcher Datenstand wurde tatsächlich programmiert? Und welche Übergaben lassen sich noch belastbar rekonstruieren?
Die neue EU-Produkthaftungsrichtlinie 2024/2853 bezieht Software ausdrücklich in den Produktbegriff ein. Dazu können unter anderem Betriebssysteme, Firmware, Anwendungen und KI-Systeme gehören – unabhängig davon, ob sie auf einem Gerät gespeichert, über ein Netzwerk bereitgestellt oder als Software-as-a-Service genutzt werden.
Für Hersteller vernetzter Elektronik wird damit noch deutlicher: Der technisch relevante Produktzustand besteht nicht allein aus physischen Komponenten. Software, Updates, Cybersecurity-Eigenschaften und das Zusammenspiel verbundener Elemente können ebenfalls für die Beurteilung eines Produktfehlers wichtig werden.
Was sich bei Software ändert
Die reformierte Produkthaftung erfasst Software ausdrücklich als Produkt. Das bedeutet jedoch nicht, dass jeder Bug oder jede Funktionsabweichung automatisch einen haftungsrechtlich relevanten Produktfehler darstellt. Entscheidend bleibt unter anderem, ob ein Produkt nicht die Sicherheit bietet, die eine Person berechtigterweise erwarten darf, ob ein erfasster Schaden eingetreten ist und ob zwischen Fehler und Schaden ein ursächlicher Zusammenhang besteht.
Für die Praxis sollten deshalb drei Ebenen getrennt betrachtet werden:
- Funktionsabweichung: Das Produkt arbeitet nicht wie spezifiziert.
- Sicherheitsrelevanter Fehler: Das Produkt bietet nicht die berechtigterweise zu erwartende Sicherheit.
- Haftungsfall: Ein Produktfehler hat einen vom Produkthaftungsrecht erfassten Schaden verursacht.
Dokumentation kann helfen, diese Ebenen technisch voneinander abzugrenzen. Sie ersetzt aber weder die Ursachenprüfung noch die rechtliche Bewertung.
Updates und Cybersecurity
Die Richtlinie trägt dem Umstand Rechnung, dass digitale Produkte nach dem Inverkehrbringen weiter verändert werden können. Software-Updates, Upgrades und verbundene digitale Dienste können dem Kontrollbereich des Herstellers zugerechnet werden, wenn er sie selbst bereitstellt oder ihre Integration autorisiert. Ein Produkt kann zudem wegen einer Cybersecurity-Schwachstelle fehlerhaft sein, etwa wenn sicherheitsrelevante Cybersecurity-Anforderungen nicht erfüllt werden.
Damit verschiebt sich die Betrachtung vom einmaligen Auslieferungszustand auf den Produktlebenszyklus. Relevant kann beispielsweise werden, welcher Softwarestand freigegeben war, welche Version tatsächlich aufgebracht wurde, ob ein notwendiges Sicherheitsupdate bereitgestellt wurde und welche Geräte oder Chargen davon betroffen waren.
Das bedeutet nicht, dass die Produkthaftungsrichtlinie für sich allein eine allgemeine Updatepflicht für jedes Produkt und jede Laufzeit festlegt. Sie kann aber die haftungsrechtliche Bewertung beeinflussen, wenn ein Fehler auf Software, einen verbundenen Dienst oder das Fehlen eines sicherheitsnotwendigen Updates zurückzuführen ist, solange entsprechende Faktoren innerhalb der Kontrolle des Herstellers liegen.
Welche Schäden erfasst sind
Der neue EU-Rahmen erfasst insbesondere Tod und Körperverletzung, einschließlich medizinisch anerkannter Beeinträchtigungen der psychischen Gesundheit, bestimmte Sachschäden sowie die Zerstörung oder Beschädigung von Daten, die nicht für berufliche Zwecke genutzt werden.
Der bloße Umstand, dass Software nicht wie erwartet funktioniert, begründet daher noch keinen Anspruch nach der Produkthaftungsrichtlinie. Ob ein konkreter Schaden erfasst ist, muss anhand des Einzelfalls und des anwendbaren nationalen Rechts beurteilt werden.
Wer kann betroffen sein?
Im Mittelpunkt steht weiterhin der Hersteller des fehlerhaften Produkts beziehungsweise einer fehlerhaften Komponente. Unter bestimmten Voraussetzungen können jedoch auch weitere Wirtschaftsakteure einbezogen werden – beispielsweise Importeure, Bevollmächtigte, Fulfilment-Dienstleister oder Lieferanten, insbesondere wenn kein verantwortlicher Hersteller innerhalb der EU greifbar ist. Auch wer ein Produkt nach dem Inverkehrbringen wesentlich verändert und erneut bereitstellt, kann wie ein Hersteller behandelt werden.
Für technische Dienstleister folgt daraus keine pauschale Herstellerhaftung. Entscheidend sind die konkrete Rolle, der übernommene Leistungsumfang, die vertraglichen Schnittstellen und die tatsächliche Einflussmöglichkeit auf Produkt oder Prozess. Herstellerpflichten bleiben Herstellerpflichten; zugleich können Informationen aus ausgelagerten Komponenten- und Programmierprozessen für deren Erfüllung und für einen späteren Haftungsfall wichtig werden.
Ab wann gilt der neue Rahmen?
Die Mitgliedstaaten müssen die Richtlinie bis zum 9. Dezember 2026 in nationales Recht umsetzen. Der neue Rahmen ist auf Produkte anzuwenden, die nach diesem Datum in Verkehr gebracht oder in Betrieb genommen werden; für zuvor bereitgestellte Produkte gilt grundsätzlich das bisherige Regime weiter.
In Deutschland liegt ein Regierungsentwurf für ein vollständig neu gefasstes Produkthaftungsgesetz vor. Nach dem offiziellen Stand vom 3. Oktober 2026 ist das parlamentarische Verfahren noch nicht abgeschlossen; der Entwurf wurde nach der ersten Lesung an den Ausschuss für Recht und Verbraucherschutz überwiesen.
Unternehmen sollten den deutschen Gesetzgebungsstand deshalb vor Veröffentlichung eigener Rechtsinformationen und vor operativen Entscheidungen erneut prüfen. Unabhängig davon ist die Richtung der europäischen Reform klar: Software, digitale Komponenten, Updates und komplexe Wertschöpfungsketten werden ausdrücklich in das Produkthaftungsrecht einbezogen.
Beweismittel werden wichtiger
Die Richtlinie sieht unter bestimmten Voraussetzungen die gerichtliche Offenlegung relevanter Beweismittel vor. Sie enthält außerdem widerlegbare Vermutungen zur Fehlerhaftigkeit beziehungsweise zum ursächlichen Zusammenhang – etwa wenn relevante Beweismittel nicht offengelegt werden, verbindliche Sicherheitsanforderungen verletzt wurden oder die technische beziehungsweise wissenschaftliche Komplexität den Nachweis übermäßig erschwert.
Das ist keine pauschale Beweislastumkehr bei jedem Softwarefehler. Die Regeln erhöhen aber die praktische Bedeutung belastbarer Produkt-, Software- und Prozessinformationen. Wer den Zustand eines Produkts nicht eingrenzen kann, gerät schneller in Abgrenzungs- und Rekonstruktionsprobleme.
Für Qualitätsmanagement, Entwicklung, Einkauf und Operations lautet die operative Frage daher nicht nur: Welche Daten speichern wir? Ebenso wichtig ist: Lassen sich diese Daten eindeutig zu Produkt, Bauteil, Version und Prozessschritt in Beziehung setzen?
Rückverfolgbarkeit allein reicht nicht
Ein Programmierprotokoll beantwortet zunächst eine rückblickende Frage: Was wurde wann auf welches Bauteil aufgebracht? Davon zu unterscheiden ist die Prozessintegrität: Welche Maßnahmen schützen Firmware, Schlüssel, Zertifikate und freigegebene Datenstände vor unbefugtem Zugriff oder Veränderung? Für ausgelagerte Programmierprozesse sollten beide Perspektiven zusammengeführt werden.
Daraus ergeben sich zwei Prüfaufgaben:
- Den Vorgang rekonstruieren: Bauteilzuordnung, Firmwarestand, Freigabe, Zeitpunkt und dokumentiertes Ergebnis zusammenführen.
- Den Vorgang schützen: Zugriffsrechte, Datenübertragung, Verarbeitung und Löschung so organisieren, dass sensible Daten nicht unnötig offengelegt oder persistent im Klartext gespeichert werden.
Ein vollständig protokollierter Prozess ist nicht automatisch ein sicherer Prozess. Umgekehrt sollte ein abgesicherter Prozess so dokumentiert sein, dass seine Durchführung später geprüft und einem konkreten Bauteil oder Auftrag zugeordnet werden kann.
Ein Beispiel aus der Fertigung
Ein Hersteller untersucht eine sicherheitsrelevante Fehlfunktion vernetzter Steuergeräte. Zwei Firmwarestände wurden nacheinander verarbeitet; zunächst steht nur einer davon im Verdacht.
Für eine schnelle Eingrenzung wären folgende Verknüpfungen hilfreich:
- Bauteil- oder Geräteidentität
- Charge oder Verpackungseinheit
- Freigegebener Firmwarestand und eindeutige Dateireferenz
- Tatsächlich ausgeführter Programmiervorgang
- Zeitpunkt, Auftrag und dokumentiertes Prüfergebnis
- Nachgelagerte Änderungen oder Neuprogrammierungen
- Liefer- und Übergabehistorie
Diese Informationen können zeigen, welche Geräte vertieft untersucht werden sollten. Sie beweisen jedoch weder automatisch die Fehlerhaftigkeit der Firmware noch die haftungsrechtliche Verantwortung eines bestimmten Akteurs.
CRA und Produkthaftung unterscheiden
Der Cyber Resilience Act und die Produkthaftungsrichtlinie berühren ähnliche technische Informationen, verfolgen aber unterschiedliche Zwecke. Der CRA legt Cybersicherheitsanforderungen für Produkte mit digitalen Elementen fest; die Produkthaftungsrichtlinie regelt den Ersatz bestimmter Schäden, die durch fehlerhafte Produkte verursacht werden.
Ein CRA-Konformitätsnachweis ist deshalb kein Haftungsfreibrief. Umgekehrt beweist eine fehlende Einzelinformation aus einem vorgelagerten Prozess nicht automatisch einen Produktfehler. Praktisch können dieselben Daten dennoch für unterschiedliche Aufgaben nützlich sein – etwa für technische Dokumentation, Schwachstellenmanagement, Audit, Rückruf oder Ursachenanalyse.
Nachweisführung vorab organisieren
Unternehmen sollten nicht nur mehr Informationen erfassen, sondern deren Zuordnung, Verfügbarkeit und Schutz festlegen. Für neue Projekte helfen sieben Fragen:
- Identifikation: Wie werden Bauteil, Gerät, Charge oder Verpackungseinheit eindeutig zugeordnet?
- Softwarestand: Wie unterscheiden sich freigegebene Datei, bereitgestellter Datenstand und tatsächlich programmierte Version?
- Freigabe: Wer darf Firmware oder Parameter zur Verarbeitung freigeben?
- Prozessintegrität: Wie werden Firmware, Schlüssel und Zertifikate während Übertragung und Verarbeitung geschützt?
- Prüfung: Welches Ergebnis wird nach der Programmierung erfasst und wie wird es zugeordnet?
- Änderungen: Wie bleiben Nachprogrammierungen, Updates und Versionswechsel nachvollziehbar?
- Schnittstellen: Wer stellt welche Nachweise bereit, wie lange bleiben sie verfügbar und wie werden Abweichungen eskaliert?
Diese Punkte gehören frühzeitig in Leistungsbeschreibungen, Qualitätsvereinbarungen und technische Schnittstellen. So entsteht keine pauschale Compliance-Zusage, sondern eine definierte Informationskette für den tatsächlich übernommenen Prozessbereich.
Wo btv technologies ansetzt
btv technologies steht an der Schnittstelle zwischen Komponentenversorgung, Lagerung, Bauteil-Services und Programmierung. Genau dort entstehen Informationen über Materialbewegungen, Bearbeitungsschritte, Firmwarestände und Geräteidentitäten, die sich später nicht zuverlässig aus dem Endprodukt allein rekonstruieren lassen.
btv TAK® unterstützt die Nachvollziehbarkeit vereinbarter Lieferketteninformationen und Materialbewegungen. btv SEEL® ergänzt diese physische Prozessspur bei programmierten Komponenten durch geschützte Firmwareverarbeitung sowie zugeordnete Programmier- und Geräteidentitätsdaten. Das RAM-only-Verfahren ist darauf ausgerichtet, persistente Klartextkopien in der Programmierumgebung zu vermeiden; der Audit-Trail unterstützt die Zuordnung von Prozessschritten zum programmierten Bauteil.
So können Informationen aus vorgelagerten Materialprozessen und aus der Programmierung für Untersuchung, Audit oder Eingrenzung zusammengeführt werden. Welche Daten tatsächlich vorliegen und wie lange sie verfügbar sind, hängt vom vereinbarten Leistungsumfang und den definierten Schnittstellen ab.
Der Beitrag von btv technologies ist technische Nachvollziehbarkeit und Prozessintegrität im übernommenen Bereich – keine Zusage zur Haftungsfreiheit und keine Konformitätsbewertung des Endprodukts.
Prozesse belastbar verbinden
Sie möchten Komponenten, Firmwarestände und Bearbeitungsschritte so organisieren, dass relevante Informationen im Ereignisfall verfügbar und zuordenbar sind?
Gemeinsam betrachten wir die Schnittstellen zwischen Komponentenversorgung, Lagerung, Bauteil-Services und Programmierung – und klären, welche Prozessinformationen für Ihre Fertigung und Nachweisführung sinnvoll sind.
FAQ
Ja. Die Richtlinie erfasst Software ausdrücklich und unabhängig von ihrer Bereitstellungsform. Dazu können unter anderem Betriebssysteme, Firmware, Anwendungen, KI-Systeme und cloudbasierte Software gehören. Für freie und quelloffene Software außerhalb einer Geschäftstätigkeit gelten besondere Ausnahmen.
Sinnvoll sind insbesondere eindeutige Produkt- und Bauteilzuordnungen, Chargen, freigegebene und tatsächlich programmierte Softwarestände, Prüfergebnisse, Änderungen sowie Liefer- und Übergabeinformationen. Welche Nachweise erforderlich sind, hängt jedoch vom Produkt, der Rolle des Unternehmens und dem konkreten Prozess ab.
Hinweis: Dieser Beitrag gibt den Rechts- und Verfahrensstand vom 3. Oktober 2026 wieder. Die EU-Produkthaftungsrichtlinie ist in Kraft; ihre Umsetzung in deutsches Recht war zum Redaktionsschluss noch nicht abgeschlossen. Aussagen zum künftigen deutschen Produkthaftungsrecht beziehen sich daher auf den vorliegenden Gesetzentwurf. Der Beitrag dient der allgemeinen Information und ersetzt keine Rechtsberatung.
