Software als Produkt: Wer haftet bei Individualsoftware ab Dezember 2026?

Bisher war Software rechtlich ein Graubereich: Ob ein Programm überhaupt ein „Produkt“ ist, für das man ohne Verschulden haftet, war umstritten. Ab dem 9. Dezember 2026 ist das geklärt. Die neue EU-Produkthaftungsrichtlinie (EU) 2024/2853 macht Software ausdrücklich zum Produkt – und betrifft damit nicht nur große Softwarehäuser, sondern jedes Unternehmen, das Software entwickeln lässt, betreibt oder an seine Kunden weitergibt.

Als Softwareentwickler und IT-Dienstleister werden wir derzeit oft gefragt, was das konkret bedeutet. Hier die wichtigsten Antworten.

Was gilt künftig als Produkt?

Die Richtlinie erfasst Software unabhängig davon, wie sie bereitgestellt wird:

• installierte Programme und Apps
• Cloud-Lösungen und Software as a Service
• Firmware und Steuerungssoftware in Geräten und Maschinen
• KI-Systeme sowie Updates und Upgrades

Nicht erfasst ist freie Open-Source-Software, die außerhalb einer Geschäftstätigkeit entwickelt wird. Wer Open-Source-Bausteine in ein eigenes, kommerzielles Produkt einbaut, ist dafür aber sehr wohl verantwortlich.

Wer haftet bei Individualsoftware?

Das ist die Frage, die uns am häufigsten gestellt wird. Die Antwort hängt davon ab, wer die Software unter wessen Namen anbietet:

• Der Entwickler gilt als Hersteller der Software – auch als Hersteller einer Komponente, wenn die Software Teil eines größeren Produkts ist.
• Der Auftraggeber gilt ebenfalls als Hersteller, wenn er die Software oder ein Gerät damit unter seinem eigenen Namen oder seiner Marke in Verkehr bringt.
• Wer eine Software wesentlich verändert, etwa ein bestehendes System umbaut, gilt für diese Änderung selbst als Hersteller.

Mehrere Haftende haften gegenüber dem Geschädigten gemeinsam. Wer am Ende wie viel trägt, regeln Entwickler und Auftraggeber untereinander – deshalb gehört diese Frage in jeden Entwicklungsvertrag.

Wann haftet man überhaupt?

Hier gibt es für viele Unternehmen eine wichtige Entwarnung: Die Produkthaftung schützt Privatpersonen. Ersetzt werden Personenschäden, Schäden an privat genutzten Sachen und – neu – der Verlust oder die Beschädigung von privat genutzten Daten.

Software, die ausschließlich im eigenen Betrieb oder für Geschäftskunden läuft, fällt damit weitgehend heraus: Schäden an beruflich genutzten Sachen und Daten sowie reine Vermögensschäden sind nicht erfasst. Dort gelten wie bisher Vertrag, Gewährleistung und Schadenersatz.

Anders sieht es aus, sobald die Software bei Endkunden ankommt: ein Kundenportal, eine App, eine Gerätesteuerung, ein Onlineshop. Gegenüber geschädigten Privatpersonen lässt sich die Haftung vertraglich nicht ausschließen.

Updates und Sicherheitslücken werden zur Pflicht

Der für den Alltag wichtigste Punkt: Ein Hersteller haftet auch dafür, dass eine Software durch ein Update fehlerhaft wird – oder dafür, dass er eine bekannte Sicherheitslücke nicht schließt, solange die Software in seiner Verantwortung liegt. Mangelnde Cybersicherheit kann ein Produktfehler sein.

Software, die nach dem Livegang niemand mehr wartet, wird damit zum Haftungsrisiko. Ein Wartungsvertrag mit festen Abläufen für Sicherheitsupdates ist künftig kein Zusatz mehr, sondern Teil eines verantwortungsvoll betriebenen Systems.

Beweise: Dokumentation ist Schutz

Die Richtlinie erleichtert Geschädigten die Beweisführung. Gerichte können Unternehmen verpflichten, technische Unterlagen offenzulegen. Wer das nicht kann oder will, bei dem wird ein Fehler vermutet. Bei technisch komplexen Produkten – und Software ist fast immer komplex – kann das Gericht Fehler oder Ursächlichkeit vermuten.

Im Ernstfall zählt deshalb, was belegt ist:

• Welche Version war wann im Einsatz?
• Welche Änderungen wurden wann und von wem gemacht?
• Wann wurde eine bekannte Sicherheitslücke geschlossen?
• Welche Tests wurden vor einer Auslieferung durchgeführt?

Saubere Versionsverwaltung, Änderungsprotokolle und nachvollziehbare Releases sind damit nicht nur gute Entwicklungspraxis, sondern auch rechtliche Absicherung.

Nicht verwechseln: der Cyber Resilience Act

Parallel zur Produkthaftung kommt eine zweite EU-Regel: der Cyber Resilience Act (Verordnung (EU) 2024/2847). Er gilt für „Produkte mit digitalen Elementen“ – also Software und Geräte, die vertrieben werden, etwa Desktop-Programme, Apps oder vernetzte Geräte. Reine Cloud-Dienste sind größtenteils nicht erfasst.

• Seit 11. September 2026 müssen Hersteller aktiv ausgenutzte Sicherheitslücken und schwere Sicherheitsvorfälle melden.
• Ab 11. Dezember 2027 gelten die übrigen Pflichten, unter anderem Sicherheitsanforderungen, ein geregelter Umgang mit Schwachstellen und die CE-Kennzeichnung.

Beide Regelwerke greifen ineinander: Wer die Sicherheitsanforderungen des Cyber Resilience Act nicht erfüllt, liefert unter Umständen auch im Sinne der Produkthaftung ein fehlerhaftes Produkt.

Was Sie jetzt tun sollten

• Bestandsaufnahme: Welche Software setzen Sie ein, und welche geben Sie an Kunden oder Endverbraucher weiter?
• Verträge prüfen: Ist zwischen Ihnen und Ihrem Entwickler geregelt, wer wofür einsteht und wer Sicherheitsupdates liefert?
• Wartung sicherstellen: Gibt es für jede produktive Software jemanden, der Sicherheitslücken schließt – auch in drei Jahren noch?
• Dokumentation aufbauen: Versionen, Änderungen und Sicherheitsupdates nachvollziehbar festhalten.
• Versicherung klären: Deckt Ihre Betriebshaftpflicht die neue Produkthaftung auch für Software ab?

So arbeiten wir

Bei der Softwareentwicklung in unserem Haus ist jede Änderung in der Versionsverwaltung nachvollziehbar, jede Auslieferung dokumentiert. Für Systeme, die wir hosten und betreuen, gibt es feste Abläufe für Sicherheitsupdates. Das war schon bisher unser Anspruch – ab Dezember ist es zusätzlich das, was im Haftungsfall zählt.

Sie möchten wissen, wo Ihre Software steht? Sprechen Sie uns an – wir sehen uns Ihre Systeme gemeinsam mit Ihnen an.

Hinweis: Dieser Beitrag gibt einen allgemeinen Überblick und ersetzt keine Rechtsberatung. Österreich und Deutschland setzen die Richtlinie bis 9. Dezember 2026 in nationales Recht um; Details hängen von der jeweiligen Umsetzung ab.