Haftung bei Hardware-Defekten: Was Entwickler wissen müssen

Haftung bei Hardware-Defekten ist für Entwickler, Maker und kleine Unternehmen in Deutschland ein Thema, das oft erst dann akut wird, wenn ein Gerät im Feld ausfällt – und plötzlich Fragen zu Schadenersatz, Rückruf, Gewährleistung oder Produktsicherheit auf dem Tisch liegen. Gerade bei Embedded-Projekten (z. B. Steuerungen, Sensorik, IoT-Gateways oder Netzteil-Platinen) sind Fehlerbilder vielfältig: von sporadischen Resets über thermische Probleme bis hin zu Sicherheitsrisiken durch falsche EMV-Auslegung. Wer Hardware entwickelt oder vertreibt, sollte daher nicht nur „funktionierend“, sondern auch „rechtlich und sicherheitstechnisch belastbar“ denken. Dieser Beitrag erklärt praxisnah, welche Haftungsarten es gibt, wie du deine Risiken durch saubere Prozesse reduzierst und welche Dokumente und Prüfungen in Deutschland typischerweise erwartet werden. Der Fokus liegt auf verständlichen Grundlagen – ohne Juristendeutsch – damit du typische Stolperfallen früh erkennst und Verantwortung sauber organisierst.

Warum Hardware-Defekte rechtlich anders wirken als reine Software-Bugs

Ein Softwarefehler kann Schaden verursachen, aber Hardwaredefekte haben oft eine unmittelbarere physische Komponente: Überhitzung, Brand, Stromschlag, mechanische Verletzungen oder Folgeschäden an angeschlossenen Geräten. Das führt dazu, dass neben „klassischen“ kaufrechtlichen Ansprüchen (Gewährleistung) häufig auch produkthaftungs- und deliktsrechtliche Fragen relevant werden. Entscheidend ist außerdem: In der Praxis wird selten nur ein einzelner Fehler betrachtet. Behörden, Versicherer oder Kunden schauen auf das Gesamtbild: War die Konstruktion angemessen? Wurden Risiken analysiert? Gab es Warnhinweise? Wurde dokumentiert, getestet und ggf. nachgebessert?

Die drei wichtigsten Haftungs-Schienen in Deutschland

Für Hardwareprodukte im deutschen Markt sind typischerweise drei Ebenen zu unterscheiden. Sie greifen teils parallel – und genau das macht das Thema so wichtig.

• Gewährleistung (Sachmängelhaftung) im Kaufrecht: betrifft die Beziehung zwischen Verkäufer und Käufer. Relevant sind z. B. Mängelrechte, Nachbesserung, Ersatzlieferung, Rücktritt oder Minderung. Die Verjährungsregeln für Mängelansprüche findest du im BGB § 438 (Verjährung der Mängelansprüche).
• Produkthaftung (verschuldensunabhängig): hier geht es um Personen- und bestimmte Sachschäden, die durch ein fehlerhaftes Produkt verursacht werden. Grundlage ist das Produkthaftungsgesetz (ProdHaftG), z. B. mit Verjährung nach § 12 ProdHaftG und dem Haftungshöchstbetrag nach § 10 ProdHaftG.
• Deliktsrecht/Produzentenhaftung (verschuldensabhängig): wenn z. B. Verkehrssicherungspflichten verletzt wurden. Das kann auch dann relevant sein, wenn das ProdHaftG nicht greift oder zusätzliche Aspekte im Raum stehen.

Gewährleistung vs. Garantie: Was viele verwechseln

Gewährleistung ist gesetzlich geregelt und kann gegenüber Verbrauchern nur begrenzt eingeschränkt werden. Sie hängt nicht davon ab, ob du „Garantie“ anbietest. Garantie ist dagegen eine freiwillige Zusatzleistung des Herstellers oder Verkäufers mit eigenen Bedingungen (Dauer, Umfang, Abwicklung). Aus Haftungssicht ist wichtig:

• Eine Garantie kann Vertrauen schaffen, aber sie erweitert häufig deine Pflichten – achte auf klare Bedingungen.
• Die Gewährleistung betrifft vorrangig den Verkäufer. Wenn du über Händler verkaufst, können Regressfragen entstehen (Lieferkette).
• Bei B2B-Verträgen lassen sich bestimmte Punkte vertraglich flexibler gestalten als im B2C-Geschäft.

Produkthaftung: Wann du auch ohne Verschulden in der Verantwortung bist

Die Produkthaftung nach ProdHaftG ist besonders heikel, weil sie grundsätzlich verschuldensunabhängig ist: Es kommt nicht primär darauf an, ob du „schuld“ bist, sondern ob das Produkt fehlerhaft war und dadurch ein Schaden entstanden ist. Für Entwickler bedeutet das: Nicht nur „best effort“, sondern nachweisbare Sorgfalt zählt.

Praktisch relevant sind dabei auch Fristen und Grenzen. Ansprüche nach ProdHaftG verjähren regelmäßig innerhalb von drei Jahren ab Kenntnis (Details in § 12 ProdHaftG). Bei Personenschäden durch gleiche Produkte mit demselben Fehler gibt es zudem einen Haftungshöchstbetrag von 85 Millionen Euro (siehe § 10 ProdHaftG). Diese Zahlen sind für kleine Unternehmen zwar „fern“, zeigen aber die grundsätzliche Systematik: Produkthaftung ist nicht nur ein Theoriethema.

Typische Fehlerarten bei Hardware – und warum sie juristisch relevant sind

In der Praxis werden Produktfehler häufig in Kategorien gedacht. Für Embedded-Hardware sind diese besonders hilfreich, weil sie direkt auf Entwicklungsprozesse abbilden.

Konstruktionsfehler

Die Konstruktion ist an sich unsicher – selbst wenn jedes einzelne Gerät korrekt gefertigt wurde. Beispiele: zu knapp ausgelegte Leiterbahnen für Strompfade, fehlende Schutzbeschaltung an Schnittstellen, unzureichende Kriechstrecken im Netzspannungsbereich, thermisch ungünstiges Layout oder fehlende Entkopplungskondensatoren. Konstruktionsfehler sind kritisch, weil sie systematisch auftreten können.

Fabrikationsfehler

Die Konstruktion ist grundsätzlich in Ordnung, aber einzelne Geräte weichen durch Fertigungsprobleme ab: kalte Lötstellen, falsche Bauteilwerte, fehlerhafte Bestückung, Chargenschwankungen, beschädigte Bauteile. Hier wird häufig gefragt: Welche Wareneingangs- und Produktionskontrollen gab es? Wie wurde rückverfolgt (Seriennummern, Chargen)?

Instruktions- und Warnfehler

Das Produkt wäre bei richtiger Nutzung sicher, aber Informationen fehlen oder sind missverständlich: falsche Pinbelegung im Handbuch, unklare Grenzwerte, fehlender Hinweis auf erforderliche Sicherungen, falsche Montageanleitung. Für DIY-Kits und Entwicklerboards ist das ein häufiger Stolperstein: „Nur für Entwicklungszwecke“ reicht als Satz oft nicht, wenn die reale Nutzung absehbar anders ist.

Rollen in der Lieferkette: Hersteller, Importeur, Händler, „Quasi-Hersteller“

Ein zentraler Punkt: Rechtliche Pflichten hängen nicht nur an der Entwicklung, sondern an der Rolle im Markt. Wer als „Hersteller“ gilt, muss typischerweise mehr leisten als ein reiner Händler. Gleichzeitig kann ein Händler unter Umständen in eine herstellerähnliche Rolle rutschen (z. B. bei eigener Marke/Labeling). Eine gut verständliche Einordnung liefert u. a. die DGUV-Seite zur Verantwortung bei CE-Konformität (Hersteller, Importeur, Händler).

• Hersteller: bringt das Produkt unter eigenem Namen in Verkehr oder lässt es entwickeln/fertigen und vertreibt es.
• Importeur/Einführer: bringt Ware aus Nicht-EU-Staaten in den EU-Markt und hat eigene Pflichten.
• Händler: muss u. a. prüfen, ob Produkte korrekt gekennzeichnet sind und keine offensichtlichen Sicherheitsmängel haben.

Produktsicherheit und CE: Haftung beginnt oft vor dem ersten Verkauf

Viele Entwickler denken bei Haftung an Reklamationen. In der Realität beginnt Risikominimierung deutlich früher: bei Produktsicherheitsanforderungen, Risikobeurteilung, Prüfungen, technischen Unterlagen und – falls einschlägig – CE-Kennzeichnung. In Deutschland ist das zentrale Gesetz hier das Produktsicherheitsrecht. Ein Einstieg ist die Übersicht des BMAS zum Produktsicherheitsgesetz (ProdSG).

Die CE-Kennzeichnung ist dabei kein „Qualitätssiegel“, sondern eine Herstellererklärung, dass das Produkt die einschlägigen EU-Anforderungen erfüllt. Je nach Produkt können z. B. EMV-, Niederspannungs- oder Maschinen-Richtlinien/Verordnungen relevant sein. Praxisnah beschrieben wird das z. B. im Beitrag zur CE-Kennzeichnung und den erforderlichen Unterlagen. Für Embedded-Geräte ist besonders häufig die EMV-Konformität ein Thema – und damit auch die technische Dokumentation, mit der du im Zweifel nachweist, dass du Risiken adressiert hast.

Was im Streitfall wirklich zählt: Nachweise statt Bauchgefühl

Wenn ein Hardwaredefekt einen relevanten Schaden verursacht, wird häufig rekonstruiert, ob du „Stand der Technik“ und übliche Sorgfalt eingehalten hast. Dabei sind nicht nur Messergebnisse wichtig, sondern auch die Nachvollziehbarkeit: Wer hat wann was entschieden, geprüft und freigegeben?

• Risikobeurteilung: Welche Gefahren gibt es (elektrisch, thermisch, mechanisch, EMV, Fehlbedienung) und wie wurden sie reduziert?
• Design-Reviews: dokumentierte Review-Checklisten (z. B. für Schutzbeschaltung, Reset- und POR-Design, Überspannung, ESD, Layout-Regeln).
• Verifikation/Tests: Prüfpläne, Grenzwerte, Testabdeckung, Worst-Case-Betrachtungen.
• Änderungsmanagement: ECOs/Revisionen, nachvollziehbare Stücklisten, Freigaben, Rückverfolgbarkeit.
• Dokumentation für Nutzer: klare Spezifikationen, Warnhinweise, Betriebsbedingungen, Anschlusspläne.

Typische Haftungsfallen in Embedded-Projekten

Gerade bei kleinen Teams entstehen Risiken nicht durch „grobe Fahrlässigkeit“, sondern durch typische Muster: zu wenig Zeit, fehlende Prüfmittel oder unterschätzte Randbedingungen. Diese Punkte tauchen in der Praxis überdurchschnittlich oft auf:

• Thermik unterschätzt: Bauteile laufen im Labor stabil, aber im Gehäuse bei Sommerhitze versagt der Regler oder MOSFET.
• ESD/Überspannung nicht sauber adressiert: Feld-Ausfälle an UART/USB/Sensorleitungen durch fehlende Schutzdioden oder falsche Masseführung.
• Reset- und Brown-out-Themen: sporadische Fehlzustände durch unzureichenden POR/BOR-Entwurf oder ungeeignete WDT-Strategien.
• Netzteil/Isolation: fehlende Abstände, falsche Sicherungen, unpassende Kondensatoren, keine Schutzleiterkonzepte.
• Undokumentierte Grenzen: Nutzer betreibt das Produkt außerhalb der Spezifikation, weil die Spezifikation nicht klar war.

Rechnen, um Risiken greifbar zu machen: Verlustleistung als Klassiker

Viele Defekte entstehen durch Wärme. Ein typisches Beispiel ist der lineare Spannungsregler (LDO), der aus 12 V Eingang 5 V für eine PIC-Schaltung macht. Die Verlustleistung muss als Wärme weg – und kann Bauteile oder Kunststoffgehäuse überfordern. Die Rechnung ist simpel, aber entscheidend:

$P=(V_{\mathrm{in}}-V_{\mathrm{out}})·I_{\mathrm{out}}$

Wenn du z. B. 12 V auf 5 V bei 200 mA regelst, ergibt sich P = (12−5)·0,2 = 1,4 W. 1,4 W sind in kleinen Gehäusen schnell kritisch. Solche nachvollziehbaren Berechnungen sind nicht nur technisch wichtig, sondern helfen auch, im Zweifel zu zeigen, dass du Risiken methodisch bewertet hast.

Was tun, wenn ein Defekt im Feld auftaucht?

Bei echten Vorfällen entscheiden die ersten Tage oft über den weiteren Verlauf. Ziel ist, Schaden zu begrenzen, Ursachen zu klären und die Kommunikation sauber zu halten – ohne vorschnelle Schuldzuweisungen.

• Incident-Triage: Welche Symptome, welche Charge, welche Umgebung? Gibt es Sicherheitsrisiken (Brand, Stromschlag)?
• Rückverfolgbarkeit aktivieren: Seriennummern/Chargen, Produktionsdaten, Firmwarestände, Lieferantenlose.
• Containment: Verkaufsstopp für betroffene Revision, Austauschprogramm, Workaround (z. B. zusätzlicher Schutz, Firmware-Limit).
• Technische Ursachenanalyse: FMEA/8D-Logik, reproduzierbare Tests, Bauteilanalysen, Layout-Review.
• Dokumentation: Jede Maßnahme dokumentieren – auch, um später transparent erklären zu können, wie du reagiert hast.

Wenn es um unsichere Produkte geht, spielen auch Marktüberwachungsstellen eine Rolle. Ein Überblick über Ziele und Praxis der Marktüberwachung findet sich bei der BAuA unter Marktüberwachung und Produktsicherheit.

Versicherungen und Vertragsgestaltung: Sinnvoll, aber kein Freifahrtschein

Eine Produkthaftpflichtversicherung kann existenzsichernd sein – ersetzt aber nicht saubere Prozesse. Versicherer erwarten häufig nachweisbare Entwicklungs- und Qualitätsstandards. Ebenso wichtig ist eine klare Vertragsgestaltung (B2B), z. B. zu Spezifikationen, Abnahme, Einsatzbedingungen und Verantwortlichkeiten. Dennoch gilt: Zwingende gesetzliche Haftungsregeln lassen sich nicht beliebig „wegverhandeln“. Deshalb sind technische Prävention und nachvollziehbare Dokumentation meist die beste „Versicherung“ im Alltag.

Praxis-Checkliste: So reduzierst du Haftungsrisiken schon im Entwicklungsalltag

• Safety-by-Design: Schutzbeschaltungen, Fail-Safe-Zustände, klare Reset-Strategien, sichere Default-Konfigurationen.
• EMV- und ESD-Konzept: Layout-Regeln, Entkopplung, Masseführung, Schutzbauteile, realistische Tests.
• Risikobeurteilung schriftlich: kurze, aber konkrete Risikoanalyse – regelmäßig aktualisieren.
• Dokumentation nutzerorientiert: klare Grenzwerte, Anschlusspläne, Warnhinweise, Montage-/Betriebsanleitung.
• Qualitätskontrollen definieren: Wareneingang, In-Circuit-Tests, Stichproben, End-of-Line-Checks, Burn-in (wenn sinnvoll).
• Rückverfolgbarkeit: Seriennummern, Chargen, BOM-Revisionsstände, Firmware-Versionen.
• Change-Management: keine „stillen“ Änderungen; jede Revision braucht Test- und Freigabeprotokoll.
• Release-Gates: klare Kriterien, wann ein Produkt in den Verkauf darf (inkl. Dokumente, Prüfungen, Freigaben).

Wichtiger Hinweis zur Einordnung: Keine Rechtsberatung, aber ein guter nächster Schritt

Haftung bei Hardware-Defekten hängt stark vom Einzelfall ab: Produkttyp, Zielgruppe (B2B/B2C), Vertriebskanal, Dokumentation, Sicherheitsanforderungen und tatsächlicher Schaden. Wenn ein konkreter Vorfall vorliegt oder du ein Produkt in den Markt bringen willst, ist eine kurze Prüfung durch spezialisierte Rechtsberatung sinnvoll – idealerweise kombiniert mit einer technischen Compliance-Sicht (CE/ProdSG/EMV). Für die fachliche Orientierung sind die Primärquellen besonders wertvoll: das Produkthaftungsgesetz im Volltext, die Verjährungsregel in § 12 ProdHaftG sowie die grundlegenden Verjährungsregeln für Mängelansprüche in § 438 BGB. So kannst du Anforderungen sauber von Mythen trennen und deine Prozesse gezielt verbessern.

IoT-PCB-Design, Mikrocontroller-Programmierung & Firmware-Entwicklung

PCB Design • Arduino • Embedded Systems • Firmware

Ich biete professionelle Entwicklung von IoT-Hardware, einschließlich PCB-Design, Arduino- und Mikrocontroller-Programmierung sowie Firmware-Entwicklung. Die Lösungen werden zuverlässig, effizient und anwendungsorientiert umgesetzt – von der Konzeptphase bis zum funktionsfähigen Prototyp.

Diese Dienstleistung richtet sich an Unternehmen, Start-ups, Entwickler und Produktteams, die maßgeschneiderte Embedded- und IoT-Lösungen benötigen. Finden Sie mich auf Fiverr.

Leistungsumfang:

• IoT-PCB-Design & Schaltplanerstellung

• Leiterplattenlayout (mehrlagig, produktionstauglich)

• Arduino- & Mikrocontroller-Programmierung (z. B. ESP32, STM32, ATmega)

• Firmware-Entwicklung für Embedded Systems

• Sensor- & Aktor-Integration

• Kommunikation: Wi-Fi, Bluetooth, MQTT, I²C, SPI, UART

• Optimierung für Leistung, Stabilität & Energieeffizienz

Lieferumfang:

• Schaltpläne & PCB-Layouts

• Gerber- & Produktionsdaten

• Quellcode & Firmware

• Dokumentation & Support zur Integration

Arbeitsweise:Strukturiert • Zuverlässig • Hardware-nah • Produktorientiert

CTA:
Planen Sie ein IoT- oder Embedded-System-Projekt?
Kontaktieren Sie mich gerne für eine technische Abstimmung oder ein unverbindliches Angebot. Finden Sie mich auf Fiverr.