Fehlerbegriff und Cybersicherheit: wann eine Sicherheitslücke zum Produktfehler wird

Problem in der Praxis

Security-Organisationen bewerten Schwachstellen nach Ausnutzbarkeit, Score und Patch-Aufwand. Die Haftungsfrage stellt anders: Bot das Produkt die Sicherheit, die eine Person erwarten darf oder die vorgeschrieben ist? Diese Wertung kennt kein CVSS-Schwellenwert-Raster, und sie wird im Streitfall von einem Gericht getroffen, nicht vom PSIRT. Nach einem Vorfall greifen Teams zudem reflexhaft zum Angreifer-Argument; zivilrechtlich ist es durch Art. 13 Abs. 1 abgeschnitten, solange der Schaden zugleich auf der Fehlerhaftigkeit beruht.

Auf der anderen Seite wird die Richtlinie regelmäßig überlesen: Sie definiert selbst keine einzige Cybersicherheitsanforderung. Welche Anforderungen "einschlägig" sind, ergibt sich aus dem Produktsicherheitsrecht; für Produkte mit digitalen Elementen kommen dafür insbesondere die CRA-Anforderungen in Betracht, als Ergebnis der Auslegung im Einzelfall, nicht kraft Verweises. Oft falsch wiedergegeben: Die Richtlinie nennt CRA, Maschinenverordnung und NIS2 an keiner Stelle; wer eine normative Verweisung behauptet, erfindet sie.

CISO-Einordnung

Art. 7 Abs. 1 enthält zwei Maßstäbe, von denen jeder für sich trägt: die berechtigte Sicherheitserwartung und die rechtlich vorgeschriebene Sicherheit. Daraus folgt zweierlei. Erstens kann ein Produkt fehlerhaft sein, obwohl es alle vorgeschriebenen Anforderungen erfüllt, wenn es hinter der Sicherheit zurückbleibt, die eine Person erwarten darf; Konformität ist kein automatischer Haftungsschutz. Zweitens macht die Verletzung vorgeschriebener Sicherheit den Fehlervorwurf greifbar, und auf der Beweisseite kann ein nachgewiesener Verstoß gegen verbindliche Produktsicherheitsanforderungen die Fehlerhaftigkeit sogar vermuten lassen, sofern die verletzte Anforderung gerade vor dem eingetretenen Schadensrisiko schützen soll (Art. 10 Abs. 2 Buchst. b; Beweisfragen vertieft pld-004).

Die Beurteilungsumstände des Art. 7 Abs. 2 sind nicht abschließend ("alle Umstände ... einschließlich"). Für die Security-Perspektive zählen vor allem:

• Buchst. a: Aufmachung und Merkmale des Produkts einschließlich Kennzeichnung und der Anleitungen für Montage, Installation, Gebrauch und Wartung; die eigene Produktkommunikation setzt den Erwartungsmaßstab mit.
• Buchst. b: der vernünftigerweise vorhersehbare Gebrauch.
• Buchst. c: die Auswirkungen der Fähigkeit des Produkts, nach Inverkehrbringen oder Inbetriebnahme weiter zu lernen oder neue Funktionen zu erwerben; das ist die KI-Klausel des Fehlermaßstabs (AI-Act-Pflichten selbst: ai-governance-Track).
• Buchst. d: die vernünftigerweise vorhersehbaren Auswirkungen anderer Produkte, die voraussichtlich zusammen mit dem Produkt verwendet werden, einschließlich der Verbindung; Interkonnektivität ist ausdrücklich Beurteilungsumstand.
• Buchst. e: der Zeitpunkt des Inverkehrbringens oder der Inbetriebnahme; behält der Hersteller danach die Kontrolle über das Produkt, kommt es stattdessen darauf an, wann das Produkt die Kontrolle des Herstellers verlassen hat (Nachmarktlogik vertieft pld-003).
• Buchst. f: die einschlägigen Anforderungen an die Produktsicherheit einschließlich sicherheitsrelevanter Cybersicherheitsanforderungen.
• Buchst. g: Produktrückrufe und sonstige behördliche oder herstellerseitige Eingriffe im Zusammenhang mit der Produktsicherheit.

Erwägungsgrund 34 verankert dieselbe Logik für die Fehlerbeurteilung insgesamt: Einschlägige Produktsicherheitsanforderungen, einschließlich sicherheitsrelevanter Cybersicherheitsanforderungen, sind zu berücksichtigen. Woher diese Anforderungen kommen, sagt der jeweilige Rechtsakt des Produktrechts: der CRA für Produkte mit digitalen Elementen (cra-Track), die Maschinenverordnung für Maschinen (mvo-Track), die RED-Welt für Funkanlagen (red-Track). Die Produkthaftungsrichtlinie importiert diesen Maßstab nur.

Art. 13 rundet das Bild ab: Handlungen oder Unterlassungen Dritter mindern die Haftung nicht (Abs. 1); ein Verschulden der geschädigten Person selbst kann sie dagegen mindern oder entfallen lassen (Abs. 2). Für die Security-Praxis heißt das: Der Exploit eines Angreifers verschiebt die Verantwortung nicht vom Produkt weg, solange die Schwachstelle das Produkt fehlerhaft macht. Und weil die Haftung verschuldensunabhängig ist (pld-001), hilft auch der Nachweis größter Sorgfalt nicht gegen den Befund, dass das Produkt die gebotene Sicherheit nicht bot; Entlastung bieten nur die Tatbestände des Art. 11 (unter anderem der Entwicklungsrisiko-Einwand; zur Nachmarktphase pld-003).

Umsetzungsperspektive

Der Fehlermaßstab gilt für Produkte, die ab dem 09.12.2026 in Verkehr gebracht oder in Betrieb genommen werden (Art. 2 Abs. 1 in der Fassung der Berichtigung ABl. L, 2026/90364 vom 07.05.2026; Zeitplan und Übergang in pld-001). Bis dahin sollte die Produktsecurity vier Dinge aufbauen:

• Anforderungslandkarte je Produkt: Welche verbindlichen Sicherheits- und Cybersicherheitsanforderungen gelten wo (CRA, sektorales Recht)? Das ist Konformitätsarbeit der Nachbar-Tracks, wird aber über Art. 7 Abs. 2 Buchst. f und Art. 10 Abs. 2 Buchst. b haftungsrelevant.
• Erwartungsmanagement: Sicherheitsaussagen in Werbung, Datenblättern, Anleitungen und Standardkonfigurationen prägen, was eine Person erwarten darf (Buchst. a). Wer Sicherheit verspricht, hebt den Maßstab, an dem das eigene Produkt gemessen wird.
• Schwachstellen-Triage um die Haftungsdimension erweitern: Neben Ausnutzbarkeit und Score gehört die Frage in den Prozess, ob das Produkt mit dieser Lücke die gebotene beziehungsweise vorgeschriebene Sicherheit noch bietet und ob ein Verstoß gegen eine verbindliche Anforderung im Raum steht.
• Produktgedächtnis pflegen: vorhersehbare Einsatzumgebungen und Interkonnektivität (Buchst. d), Rückrufe und behördliche Eingriffe (Buchst. g) sowie der Zeitpunkt, zu dem ein Produkt die Kontrolle verlassen hat (Buchst. e), müssen im Schadensfall rekonstruierbar sein.

Typische Fehler

1. Nach dem Vorfall mit dem Angreifer als Ursache argumentieren; Art. 13 Abs. 1 schneidet das Argument ab, wenn der Schaden zugleich auf der Fehlerhaftigkeit beruht.
2. Konformität, CE-Kennzeichnung oder Zertifikate als Haftungsfreibrief behandeln; die berechtigte Sicherheitserwartung ist ein eigenständiger Maßstab (Art. 7 Abs. 1).
3. Die Richtlinie als Anforderungskatalog lesen und dort konkrete Controls suchen; sie definiert keine Anforderungen, sie importiert sie (Art. 7 Abs. 2 Buchst. f).
4. Eine normative Verweisung "PLD verweist auf CRA" behaupten; die Richtlinie nennt CRA, Maschinenverordnung und NIS2 nirgends, die Verbindung ist Auslegungsergebnis.
5. Schwachstellen ausschließlich nach Score priorisieren und die Erwartungs- und Anforderungsseite der Fehlerbeurteilung ausblenden.
6. Sicherheitsbezogene Marketingaussagen ohne Gegencheck der Produktrealität freigeben; Aufmachung, Kennzeichnung und Anleitungen fließen in die Beurteilung ein (Art. 7 Abs. 2 Buchst. a).

Risiken und Trade-offs

Der Kern-Trade-off liegt im Wertungscharakter des Fehlerbegriffs: Was "eine Person erwarten darf", entscheidet im Streitfall ein Gericht anhand aller Umstände. Das lässt sich nicht in eine Checkliste pressen; wer es versucht, erzeugt Scheinsicherheit. Belastbar ist stattdessen die Kombination aus sauberer Anforderungserfüllung, ehrlicher Produktkommunikation und dokumentierter Risikoabwägung.

Zweitens die Kommunikation: Offensive Sicherheitsversprechen differenzieren im Markt, heben aber den Erwartungsmaßstab, an dem die Fehlerhaftigkeit gemessen wird; zu leise Kommunikation kann dagegen Warn- und Instruktionslücken reißen, die über die Anleitungen (Buchst. a) ebenfalls in die Beurteilung eingehen. Drittens die Dokumentation: Interne Sicherheitsanalysen und Testberichte können im Prozess offenzulegendes Beweismaterial werden (Art. 9, pld-004). Das spricht nicht gegen Dokumentation, sondern für disziplinierte: Dieselben Unterlagen tragen die Entlastungsbeweise des Art. 11 und den Nachweis, dass das Produkt die gebotene Sicherheit bot.

Entscheidungspunkte

• Welche verbindlichen Cybersicherheitsanforderungen gelten je Produkt, und wer hält diese Zuordnung aktuell (Verzahnung mit cra-Track, mvo-Track, red-Track)?
• Wie fließt die Haftungsdimension in die Schwachstellen-Triage ein, und wer entscheidet über die Frage der gebotenen Sicherheit?
• Wer prüft sicherheitsbezogene Produktaussagen (Werbung, Datenblätter, Anleitungen) vor Veröffentlichung gegen die Produktrealität?
• Wie werden vorhersehbarer Gebrauch, Einsatzumgebungen und Interkonnektivität je Produkt dokumentiert?
• Sind Rückrufe, behördliche Eingriffe und Kontrollzeitpunkte im Produktgedächtnis so erfasst, dass sie im Schadensfall rekonstruierbar sind?

Praktische Empfehlungen

1. Führen Sie je Produkt eine versionierte Landkarte der einschlägigen Sicherheits- und Cybersicherheitsanforderungen; konkrete Anforderungen ziehen Sie aus dem Produktsicherheitsrecht (cra-Track, mvo-Track, red-Track), nicht aus der Produkthaftungsrichtlinie.
2. Ergänzen Sie die Schwachstellen-Triage um die Haftungsfrage: bietet das Produkt mit dieser Lücke noch die Sicherheit, die erwartet werden darf oder vorgeschrieben ist?
3. Etablieren Sie einen Review sicherheitsbezogener Produktaussagen gegen die Produktrealität, bevor sie veröffentlicht werden.
4. Dokumentieren Sie vorhersehbare Einsatzumgebungen, Zusammenwirken mit anderen Produkten und Standardkonfigurationen als Teil der Produktakte.
5. Verbinden Sie PSIRT und Legal schon vor dem Schadensfall: Die Frage, ob das Produkt fehlerhaft war, wird gemeinsam beantwortet, nicht nacheinander.
6. Behandeln Sie das Angreifer-Argument intern als das, was es haftungsrechtlich ist: keine Entlastung (Art. 13 Abs. 1), sondern ein Anlass, die Fehlerfrage sauber zu prüfen.

Relevante Normreferenzen

• Richtlinie (EU) 2024/2853 (neue Produkthaftungsrichtlinie): Art. 7 (Fehlerhaftigkeit), Art. 13 (Haftungsminderung), Art. 10 Abs. 2 Buchst. b (Vermutung bei Verstoß gegen verbindliche Anforderungen), Erwägungsgründe 32, 34, 55; 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): Quelle verbindlicher Cybersicherheitsanforderungen für Produkte mit digitalen Elementen; in der Richtlinie (EU) 2024/2853 nicht genannt (cra-Track).
• Maschinenverordnung (VO (EU) 2023/1230): Anforderungsquelle für Maschinen; in der Richtlinie (EU) 2024/2853 nicht genannt (mvo-Track).