Produkthaftung für Software ab 9. Dezember 2026: Warum das fehlende Update haftet und der Auslieferungsstand nicht mehr schützt

Am 9. Dezember 2026 wird Software ein Produkt. Der Satz steht inzwischen in jedem Ratgeber, und er stimmt: Artikel 4 Nummer 1 der Richtlinie (EU) 2024/2853 zählt Software ausdrücklich zu den Sachen, für die verschuldensunabhängig gehaftet wird. Was in den meisten Darstellungen fehlt, steht sieben Artikel weiter. Dort ist der Einwand, mit dem bisher fast jede Diskussion über Softwarehaftung endete, für einen bestimmten Fall abgeschaltet. Der Fall ist das fehlende Sicherheitsupdate.

Dieser Beitrag verfolgt beide Hälften des Bildes: die Stelle, an der die neue Haftung erheblich weiter reicht, als sie aussieht, und die Stelle, an der sie sehr viel enger ist, als der Ton der Berichterstattung vermuten lässt. Für ein mittelständisches Unternehmen, das Software herstellt oder herstellen lässt, entscheidet erst die Kombination aus beidem darüber, ob am 9. Dezember überhaupt etwas passiert.

Was sich am 9. Dezember 2026 tatsächlich ändert

Zwei Vorschriften tragen das Datum. Artikel 22 verpflichtet die Mitgliedstaaten, die erforderlichen Vorschriften bis zum 9. Dezember 2026 in Kraft zu setzen. Artikel 2 Absatz 1 sagt, welche Produkte sie dann erfassen: Die Richtlinie gilt für Produkte, die nach dem 9. Dezember 2026 in Verkehr gebracht oder in Betrieb genommen werden. Alles, was vorher in Verkehr gebracht wurde, bleibt beim bisherigen Regime der Richtlinie 85/374/EWG. Der Stichtag hängt am einzelnen Produkt und nicht am Unternehmen, und diese Unterscheidung ist das Nützlichste an der ganzen Reform.

Die vierte Zeile lohnt das Innehalten. Im bisherigen Regime gab es keinen Weg, der von einem nie ausgelieferten Update zur Haftung des Herstellers geführt hätte. Die neue Richtlinie baut diesen Weg absichtlich, und sie tut es an einer Stelle, die die meisten Zusammenfassungen überspringen, weil sie als Ausnahme von einer Ausnahme formuliert ist.

Der Einwand, der abgeschaltet wurde

Artikel 11 Absatz 1 zählt die Gründe auf, aus denen ein Wirtschaftsakteur nicht haftet. Buchstabe c ist derjenige, der in der Praxis die Arbeit gemacht hat: Der Akteur haftet nicht, wenn er beweist, dass es wahrscheinlich ist, dass die schadensursächliche Fehlerhaftigkeit zum Zeitpunkt des Inverkehrbringens oder der Inbetriebnahme noch nicht bestanden hat oder erst danach entstanden ist. Für Software war dieser Einwand kaum zu schlagen. Eine Schwachstelle, die drei Jahre nach der Auslieferung entdeckt wird, war fast definitionsgemäß bei der Auslieferung kein Fehler.

Artikel 11 Absatz 2 nimmt genau das zurück. Abweichend von Absatz 1 Buchstabe c wird ein Wirtschaftsakteur nicht von der Haftung befreit, wenn die Fehlerhaftigkeit auf einen verbundenen Dienst, auf Software einschließlich Updates oder Upgrades, auf das Fehlen von Software-Updates oder -Upgrades, die zur Aufrechterhaltung der Sicherheit erforderlich sind, oder auf eine wesentliche Änderung des Produkts zurückgeht, sofern dies der Kontrolle des Herstellers unterliegt. Vier Fälle, und der dritte ist derjenige, den niemand einplant.

Die Vorschrift greift nur bei Kontrolle des Herstellers, also entscheidet die Definition dieser Kontrolle darüber, wie viel von ihr in der Wirklichkeit übrig bleibt. Artikel 4 Nummer 5 beantwortet das zweigliedrig. Nach Buchstabe a liegt Kontrolle vor, wenn der Hersteller die Integration, Verbindung oder Bereitstellung einer Komponente einschließlich Updates oder eine Änderung des Produkts vornimmt, genehmigt oder ihr zustimmt. Nach Buchstabe b liegt sie vor, wenn der Hersteller in der Lage ist, Software-Updates oder -Upgrades selbst bereitzustellen oder durch einen Dritten bereitstellen zu lassen. Nicht die Ausübung. Die Fähigkeit.

Liest man beide Vorschriften zusammen, ist die Folge unbequem und eindeutig. Das Haftungsfenster schließt sich nicht mit der Auslieferung. Es schließt sich, wenn Sie kein Update mehr liefern können, und bei einem Produkt mit Update-Mechanismus tritt dieser Zeitpunkt kaum je ein, solange der Mechanismus existiert. Wer eine bekannte Schwachstelle offen lässt, weil der Kunde klein ist, der Releasezug voll oder die Version alt, trifft keine Supportentscheidung mehr. Er trifft eine Haftungsentscheidung, und Artikel 11 Absatz 2 Buchstabe c ist die Vorschrift, die ihm dann vorgehalten wird.

Wo die Haftung dagegen gar nicht hinreicht

Bis hierhin liest sich das als Grund zur Sorge, und ein großer Teil der deutschen Berichterstattung hört genau dort auf. Das sollte sie nicht, denn dieselbe Richtlinie zieht eine Grenze, die sehr viel enger ist als der Alarm, und sie zieht sie in zwei Sätzen.

Artikel 5 Absatz 1 verpflichtet die Mitgliedstaaten sicherzustellen, dass jede natürliche Person, die einen durch ein fehlerhaftes Produkt verursachten Schaden erleidet, Anspruch auf Schadensersatz hat. Ein Unternehmen ist keine natürliche Person. Nach dieser Richtlinie kann ein Unternehmen nichts verlangen, nicht weniger, sondern nichts. Und Artikel 6 Absatz 1 zählt die ersatzfähigen Schäden abschließend auf, im Wortlaut gilt das Recht nur für die folgenden Arten von Schäden: Tod oder Körperverletzung einschließlich medizinisch anerkannter Beeinträchtigungen der psychischen Gesundheit; Beschädigung oder Zerstörung von Sachen mit Ausnahme des fehlerhaften Produkts selbst, eines durch eine fehlerhafte Komponente beschädigten Produkts unter der Kontrolle desselben Herstellers und von Sachen, die ausschließlich für berufliche Zwecke verwendet werden; sowie die Vernichtung oder Beschädigung von Daten, die nicht für berufliche Zwecke verwendet werden.

Für einen echten Business-to-Business-Anbieter liest sich diese Tabelle über weite Strecken als Entwarnung, und die Entwarnung ist berechtigt. Sie ist zugleich enger, als sie aussieht, und zwar auf drei Wegen, die man einzeln benennen sollte.

Die drei Wege, auf denen es einen B2B-Lieferanten doch trifft

Der erste ist der Personenschaden, und er verschluckt die Berufsausnahme vollständig. Die Ausnahme in Artikel 6 Absatz 1 Buchstabe b Ziffer iii betrifft Sachen. Artikel 6 Absatz 1 Buchstabe a berührt sie nicht. Wenn Ihre Steuerungssoftware eine Maschine bewegen kann, obwohl sie stehen müsste, ändert der Umstand, dass Maschine, Halle und Arbeitsverhältnis allesamt gewerblich sind, nichts am Anspruch der Person, die daneben stand.

Der zweite ist Artikel 8 Absatz 1 Buchstabe b, und ein Komponentenlieferant sollte ihn vor allen anderen lesen. Haftbar ist der Hersteller einer fehlerhaften Komponente, wenn diese unter der Kontrolle des Herstellers in ein Produkt integriert oder mit ihm verbunden wurde und die Fehlerhaftigkeit dieses Produkts verursacht hat, unbeschadet der Haftung des Herstellers des Endprodukts. Eine Bibliothek, ein Steuerungsmodul oder ein Firmware-Abbild, das Sie in das Gerät eines anderen liefern, macht Sie zu einem eigenständigen Wirtschaftsakteur neben Ihrem Kunden. Ihr eigener Vertriebsweg kann streng B2B sein, während das Produkt, in dem Ihre Komponente landet, im Handel beim Verbraucher steht, und dieses Endprodukt bestimmt, wer klagen kann.

Für genau diese Position ist ein Entlastungsgrund vorgesehen. Nach Artikel 11 Absatz 1 Buchstabe f entlastet sich der Komponentenhersteller mit dem Nachweis, dass die Fehlerhaftigkeit des Produkts, in das die Komponente integriert wurde, auf die Gestaltung dieses Produkts oder auf die Anweisungen seines Herstellers zurückgeht. Dieser Nachweis wird auf Papier gewonnen oder verloren: an einer schriftlichen Spezifikation, einer dokumentierten Zweckbestimmung und einer Aufzeichnung dessen, was Ihnen über den Einsatz gesagt wurde. Wer ein Modul gegen einen Anruf und eine Bestellnummer liefert, hat nichts, womit er ihn führen könnte.

Der dritte Weg ist ein einzelnes Wort. Artikel 6 Absatz 1 Buchstabe b Ziffer iii nimmt Sachen aus, die ausschließlich beruflich verwendet werden, und Artikel 6 Absatz 1 Buchstabe c schützt Daten, die nicht beruflich verwendet werden. Ein Telefon, ein Notebook oder ein Fahrzeug, das auch privat genutzt wird, erfüllt ausschließlich nicht, und in einem mittelständischen Unternehmen beschreibt das einen erheblichen Teil der Hardware im Feld. Dieselbe Technik trat schon in der KI-Verordnung auf: Ein einzelnes Wort entscheidet darüber, wer in einer Vorschrift steht und wer nicht, und es ist selten das Wort, das zweimal gelesen wird.

Warum der Cyber Resilience Act plötzlich einen Preis hat

Artikel 10 Absatz 1 belässt die Beweislast dort, wo sie immer lag: Der Kläger beweist Fehlerhaftigkeit, Schaden und den ursächlichen Zusammenhang. Artikel 10 Absatz 2 nennt dann drei Fälle, in denen die Fehlerhaftigkeit vermutet wird. Buchstabe a erfasst den Beklagten, der es unterlässt, relevante Beweismittel nach Artikel 9 Absatz 1 offenzulegen. Buchstabe c erfasst eine offensichtliche Funktionsstörung bei vernünftigerweise vorhersehbarem Gebrauch. Buchstabe b ist derjenige, der diese Richtlinie mit dem übrigen Regulierungsbestand verbindet: Die Fehlerhaftigkeit wird vermutet, wenn der Kläger nachweist, dass das Produkt verbindlichen Anforderungen des Unionsrechts oder des nationalen Rechts an die Produktsicherheit nicht entspricht, die vor dem Risiko der erlittenen Schädigung schützen sollen.

Der Cyber Resilience Act, die Verordnung (EU) 2024/2847, ist genau ein solcher Bestand verbindlicher Unionsanforderungen an Produkte mit digitalen Elementen. Das BSI fasst den praktischen Kern in einem Satz zusammen: Der Supportzeitraum muss vom Hersteller kommuniziert werden und beträgt in der Regel fünf Jahre, und während dieses gesamten Zeitraums müssen Sicherheitsupdates zur Verfügung gestellt und das Schwachstellenhandling betrieben werden.

Legt man beide Rechtsakte nebeneinander, ist die Arbeitsteilung exakt. Der eine sagt, dass Sie Sicherheitsupdates liefern müssen. Der andere sagt, was es kostet, wenn Sie es nicht tun, und er sagt es gleich zweimal: über Artikel 11 Absatz 2 Buchstabe c, der den Einwand des fehlerfreien Auslieferungsstands nimmt, und über Artikel 10 Absatz 2 Buchstabe b, der den Verstoß gegen die Sicherheitsanforderung in eine Vermutung der Fehlerhaftigkeit verwandelt. An dieser Stelle hört ein Rückstand bei der Cybersicherheit auf, eine technische Schuld zu sein, und wird ein Posten in der Bilanz. Über die Meldeseite derselben Verordnung haben wir in unserem Beitrag zur 24-Stunden-Pflicht geschrieben; dies ist das andere Ende desselben Seils.

Buchstabe a verdient einen eigenen Satz, weil er der leise ist. Wer die Beweismittel nicht vorlegen kann, deren Offenlegung ein Gericht anordnet, argumentiert nicht nur aus einer schwächeren Position. Die Fehlerhaftigkeit wird gegen ihn vermutet. In einem Softwarestreit sind diese Beweismittel Build-Aufzeichnungen, Schwachstellenverfolgung und Release-Historie, also genau das Material, das eher rekonstruiert als aufbewahrt wird.

Drei Jahre, zehn Jahre, fünfundzwanzig Jahre

Artikel 16 Absatz 1 setzt eine Verjährungsfrist von drei Jahren für die Einleitung eines Verfahrens, laufend ab dem Tag, an dem die geschädigte Person von Schaden, Fehlerhaftigkeit und der Identität des haftenden Wirtschaftsakteurs Kenntnis erlangt hat oder vernünftigerweise hätte erlangen müssen. Weil die Frist an der Kenntnis und nicht an der Auslieferung hängt, tröstet sie einen Hersteller nur begrenzt.

Artikel 17 Absatz 1 legt darüber eine Ausschlussfrist von zehn Jahren, laufend ab dem Inverkehrbringen oder der Inbetriebnahme des fehlerhaften Produkts, bei einem wesentlich veränderten Produkt ab dem Zeitpunkt, zu dem es nach der Änderung bereitgestellt wurde. Artikel 17 Absatz 2 verlängert diese Frist auf fünfundzwanzig Jahre, wenn die geschädigte Person wegen der Latenzzeit einer Körperverletzung nicht binnen zehn Jahren tätig werden konnte. Und Artikel 15 schließt den naheliegenden Ausweg: Die Mitgliedstaaten stellen sicher, dass die Haftung gegenüber der geschädigten Person weder durch eine vertragliche Bestimmung noch durch nationales Recht beschränkt oder ausgeschlossen wird.

In die Sprache der Entwicklung übersetzt beantwortet sich die Aufbewahrungsfrage von selbst. Die Dokumentation dessen, was eine Version konnte, welche Schwachstellen wann bekannt waren und welche Updates wem angeboten wurden, muss zehn Jahre ab dem Inverkehrbringen auffindbar bleiben, und bei einem Produkt, das Personen verletzen kann, reicht der Horizont noch weiter. Die meisten Entwicklungsorganisationen bewahren dieses Material auf, solange das Repository zufällig existiert, und das ist etwas anderes als ein Jahrzehnt bewusster Aufbewahrung.

Wo das deutsche Gesetz gerade steht

Deutschland setzt über ein neues Stammgesetz um, das den alten Namen behält. Der Regierungsentwurf zur Modernisierung des Produkthaftungsrechts, Bundestagsdrucksache 21/4297 vom 25. Februar 2026, war am 4. März 2026 in erster Lesung und wurde an den Ausschuss für Recht und Verbraucherschutz überwiesen. Der Ausschuss führte am 13. April 2026 seine Anhörung durch, in der die beabsichtigte Eins-zu-eins-Umsetzung von den Sachverständigen teils als zu weitgehend, teils als zu zurückhaltend bewertet wurde. Eine abschließende Beratung ist bis zum Stand dieses Beitrags nicht ergangen.

Es liegt nahe, darin Luft zu sehen, und rechtlich ist das teilweise richtig: Eine Richtlinie begründet für sich genommen keine Pflichten zwischen Privaten, bevor sie umgesetzt ist, und die Grenzen richtlinienkonformer Auslegung im Verhältnis zwischen Privaten sind real. Der Schluss, den Unternehmen daraus ziehen, ist trotzdem meist falsch. Die Umsetzungsfrist bindet den Gesetzgeber, nicht Sie, und die Vorbereitung, die das neue Regime verlangt, schulden Sie Ihrem eigenen Betrieb ohnehin: zu wissen, welche Versionen im Feld sind, zu wissen, wie lange Sie sie noch patchen können, und beides Jahre später beweisen zu können. Nichts davon kommt mit der Verkündung eines Gesetzes. Alles davon dauert länger als die verbleibende Zeit.

Die Frage, die dieser Beitrag nicht entscheidet

Redlichkeit verlangt, den offenen Punkt zu benennen, und er betrifft hier Produkte, die es schon gibt. Artikel 2 Absatz 1 knüpft die Anwendung an das Inverkehrbringen oder die Inbetriebnahme nach dem 9. Dezember 2026, und die Aufhebungsvorschrift hält die alte Richtlinie für Produkte am Leben, die vorher in Verkehr gebracht wurden. Artikel 17 Absatz 1 Buchstabe b lässt die Zehnjahresfrist bei einem wesentlich veränderten Produkt jedoch ab dem Zeitpunkt laufen, zu dem dieses veränderte Produkt bereitgestellt wurde, behandelt die wesentliche Änderung also als eigenständiges Ereignis.

Ob eine wesentliche Änderung nach dem 9. Dezember 2026 ein Produkt, das etwa 2024 erstmals verkauft wurde, in das neue Regime zieht, beantworten die hier geprüften Vorschriften nicht ausdrücklich, und entschieden hat es noch kein Gericht. Planen würden wir gegen die vorsichtige Lesart: Wer ein Bestandsprodukt nach dem Stichtag wesentlich überarbeitet, sollte für die überarbeitete Fassung vom neuen Regime ausgehen. Der Preis dafür, in diese Richtung falsch zu liegen, ist Dokumentation, die man streng genommen nicht gebraucht hätte. Der Preis für den Irrtum in die andere Richtung ist ein Entlastungsgrund nach Artikel 11 Absatz 1 Buchstabe c, den es nicht gibt.

Was jetzt zu tun ist

• Beantworten Sie zuerst eine Frage: Kann eines unserer Produkte einen Menschen verletzen. Lautet die ehrliche Antwort nein, und landet nichts von dem, was Sie liefern, in einem Verbraucherprodukt, ist die Belastung durch diese Richtlinie gering, und Sie sollten dieses Ergebnis samt Begründung aufschreiben statt es als Gefühl mitzuführen. Für eine ganze Reihe reiner B2B-Softwarehäuser endet das Thema hier.
• Behandeln Sie die Update-Fähigkeit als das, was sie jetzt ist: ein Haftungstatbestand. Eine Liste: jede Version im Feld, ob Sie dafür noch einen Patch bauen und ausliefern können, und bis wann Sie es zusagen. Das Ende eines Supportzeitraums ist keine Marketingentscheidung mehr, sobald Artikel 11 Absatz 2 Buchstabe c an die Lücke zwischen dem, was Sie hätten patchen können, und dem, was Sie getan haben, eine Haftung knüpft.
• Richten Sie die Aufbewahrung an Artikel 17 aus, nicht am Repository. Build-Aufzeichnungen, Schwachstellenverfolgung und Release-Historie zehn Jahre ab dem Inverkehrbringen. Artikel 10 Absatz 2 Buchstabe a macht die Alternative teuer: Wer nicht offenlegen kann, gegen den wird die Fehlerhaftigkeit vermutet.
• Wenn Sie Komponenten liefern, halten Sie die Zweckbestimmung schriftlich fest. Artikel 11 Absatz 1 Buchstabe f ist der einzige Entlastungsgrund, der für Ihre Position geschrieben ist, und er lebt von der Spezifikation und den Anweisungen, die Sie erhalten haben. Ein Modul, das gegen einen Anruf geliefert wurde, lässt sich damit nicht verteidigen.
• Trennen Sie die beiden Ebenen in Ihren Verträgen. Gegenüber der geschädigten Person macht Artikel 15 eine Haftungsbegrenzung unwirksam, und keine Formulierung repariert das. Zwischen Ihnen und Ihren Lieferanten oder Kunden bleiben Regress, Freistellung und Versicherung offen, und dorthin gehört die Klauselarbeit tatsächlich.

Fazit

Die neue Produkthaftung ist zugleich enger und weiter als ihr Ruf. Enger, weil nur natürliche Personen anspruchsberechtigt sind und rein beruflich genutzte Sachen und Daten ausdrücklich draußen bleiben, was den klassischen B2B-Schadensfall weitgehend herausnimmt. Weiter, weil zum ersten Mal das Ausbleiben eines Sicherheitsupdates ein eigener Haftungsgrund ist und weil Kontrolle nach der Definition der Richtlinie nichts weiter verlangt, als eines liefern zu können. Getroffen werden nicht die Unternehmen, die die Richtlinie falsch lesen. Getroffen werden die, die die erste Hälfte lesen, zutreffend feststellen, dass ihr B2B-Geschäft weitgehend draußen ist, und vor der Stelle aufhören, an der ihre Firmware im Verbraucherprodukt eines anderen landet. Wenn Sie diese Grenze an Ihren tatsächlichen Produkten statt an einer Checkliste gezogen haben möchten, ist genau das der Zweck eines Erstgesprächs, und das benachbarte Regime steht in unserem Beitrag zum Data Act und vernetzten Produkten.

Häufige Fragen zur Produkthaftung für Software