OTA-Firmware-Updates und der Cyber Resilience Act: Patchen als Dienstleistungspflicht
OTA-Updates sind nicht länger nur ein Komfortmerkmal – sie sind eine rechtliche Pflicht
Wenn ein chinesischer Roboterhersteller einen Manipulatorarm oder einen autonomen mobilen Roboter in die Europäische Union liefert, unterliegt die Firmware auf diesem Gerät nun dem Cyber Resilience Act (CRA). Die Verordnung, veröffentlicht im Amtsblatt der EU als Verordnung (EU) 2024/2847, verwandelt Over-the-Air-Updates (OTA) von einem Feature, das Kunden erfreut, in eine Compliance-Verpflichtung, die den Marktzugang bestimmen kann. Für ein Servicenetzwerk, das in Europa aufgebaut wird, ist die praktische Konsequenz klar: Patchen ist keine gelegentliche Reparatur, sondern ein kontinuierlicher Dienst, der geplant, dokumentiert und mit Blick auf Sicherheit ausgeführt werden muss.
Der CRA verlangt nicht nur, dass Schwachstellen behoben werden; er verlangt, dass der Update-Mechanismus selbst sicher ist. Anhang I, Teil I, Punkt 2(d) der Verordnung schreibt vor, dass digitale Elemente so gestaltet sein müssen, dass sie „Angriffsflächen begrenzen“ und „die Auswirkungen eines Vorfalls minimieren“. Konkreter verlangt Punkt 2(f), dass Sicherheitsupdates rechtzeitig bereitgestellt werden und der Update-Mechanismus sicher ist. Das bedeutet, dass ein OTA-System, das unsignierte Firmware zulässt oder durch einen Man-in-the-Middle-Angriff unterbrochen werden kann, nicht konform ist, selbst wenn der Update-Inhalt korrekt ist.
Was der CRA von Update-Mechanismen verlangt
Die Verordnung legt mehrere konkrete Sicherheitsanforderungen für OTA-Updates fest. Gemäß Anhang I, Teil I, Punkt 2(f) müssen Hersteller sicherstellen, dass Updates durch „sichere Mechanismen“ unterstützt werden, die die Installation unbefugter Firmware verhindern. Dies impliziert kryptografische Signierung von Update-Paketen, Überprüfung der Update-Quelle und Integritätsprüfungen vor der Installation. Darüber hinaus darf der Update-Prozess keine neuen Schwachstellen einführen – zum Beispiel darf er kein Rollback auf eine Version mit bekannten kritischen Schwachstellen zulassen, es sei denn, dies ist ausdrücklich autorisiert und protokolliert.
Artikel 13(8) des CRA fügt eine weitere Ebene hinzu: Hersteller müssen sicherstellen, dass ausnutzbare Schwachstellen durch Sicherheitsupdates, die kostenlos bereitgestellt werden, „wirksam behoben“ werden. Die Verordnung legt kein festes Zeitfenster fest, verlangt jedoch, dass Updates „unverzüglich“ nach Entdeckung einer Schwachstelle bereitgestellt werden. Für ein Servicenetzwerk schafft dies eine logistische Herausforderung: Wie bringt man einen kritischen Patch auf Hunderte von Robotern in mehreren EU-Mitgliedstaaten, jeweils mit unterschiedlicher Konnektivität und Wartungsplänen?
Darüber hinaus verlangt Artikel 13(9), dass Hersteller Updates dokumentieren und Benutzer darüber informieren, einschließlich ihrer Sicherheitsauswirkungen. Dies bedeutet, dass jedes OTA-Update von Versionshinweisen begleitet sein muss, die erklären, was behoben wurde und warum. Für einen Drittanbieter-Service wird diese Dokumentation Teil des Servicerecords, der von nationalen Marktüberwachungsbehörden geprüft werden kann.
Lieferung verwundbarer Firmware: Wer haftet?
Der CRA verschiebt die Haftung erheblich. Gemäß Artikel 13(1) müssen Hersteller sicherstellen, dass Produkte ohne bekannte ausnutzbare Schwachstellen auf den Markt gebracht werden. Dies ist eine strenge Verpflichtung: Wenn ein Roboter mit einer Firmware-Version ausgeliefert wird, die eine bekannte kritische Schwachstelle aufweist, verstößt der Hersteller, selbst wenn die Schwachstelle nach dem Design des Produkts offengelegt wurde. Die einzige Verteidigung ist, dass die Schwachstelle zum Zeitpunkt des Inverkehrbringens unbekannt war, aber die Beweislast liegt beim Hersteller.
Für ein Servicenetzwerk hat diese Haftung eine Kettenwirkung. Wenn ein Hersteller sich auf einen lokalen Partner für Updates verlässt, bleibt der Hersteller für die Sicherheit des Produkts verantwortlich. Der Dienstleister kann jedoch nach allgemeinem Vertragsrecht haftbar gemacht werden, wenn er ein Update nicht korrekt durchführt oder ein Update installiert, das eine neue Schwachstelle einführt. Der CRA reguliert Dienstleister nicht direkt, verlangt jedoch von Herstellern, dass „das Produkt mit den Informationen und Anweisungen versehen ist“, die für sichere Installation und Nutzung erforderlich sind (Anhang I, Teil I, Punkt 2(i)). Dies bedeutet, dass ein Servicenetzwerk Zugang zu detaillierter technischer Dokumentation haben und die Update-Verfahren des Herstellers genau befolgen muss.
In der Praxis bedeutet dies, dass ein Servicevertrag klar definieren sollte, wer für die Überwachung von Schwachstellenmeldungen verantwortlich ist, wer entscheidet, wann ein Update ausgerollt wird, und wer die Kosten für ein fehlgeschlagenes Update trägt. Der CRA schreibt keine bestimmte Arbeitsteilung vor, verlangt jedoch, dass der Hersteller einen Prozess für die „koordinierte Offenlegung“ von Schwachstellen hat (Artikel 13(5)). Ein Servicenetzwerk kann als die Augen und Ohren des Herstellers vor Ort fungieren, Vorfälle melden und überprüfen, dass Patches korrekt angewendet werden.
OTA versus physisches Service-Update: ein Vergleich
Während OTA-Updates oft der effizienteste Weg sind, Firmware zu patchen, sind sie nicht immer möglich. Einige Roboter arbeiten in isolierten Netzwerken, einige haben sicherheitskritische Funktionen, die physische Eingriffe erfordern, und einige haben Hardware, die kein sicheres OTA unterstützt. Die folgende Tabelle vergleicht die beiden Ansätze aus Service- und Compliance-Perspektive.
| Aspekt | OTA-Update | Physisches Service-Update |
|---|---|---|
| Geschwindigkeit der Bereitstellung | Kann gleichzeitig an viele Geräte gepusht werden, oft innerhalb von Stunden | Erfordert die Planung eines Technikerbesuchs; kann für große Flotten Tage oder Wochen dauern |
| Sicherheit des Update-Mechanismus | Muss kryptografische Signierung, sichere Kanäle und Integritätsprüfungen implementieren (CRA Anhang I Teil I 2(f)) | Physischer Zugriff reduziert das Risiko von Remote-Abfangen, erfordert jedoch sichere Handhabung von Update-Medien und Überprüfung der Technikeridentität |
| Dokumentation und Prüfpfad | Automatische Protokollierung von Update-Versuchen, Erfolg/Fehler und Gerätestatus; einfacher, Nachweise für Compliance zu erbringen | Erfordert manuelle Protokollierung; Risiko menschlicher Fehler oder unvollständiger Aufzeichnungen |
| Kosten pro Update | Niedrige Grenzkosten nach anfänglicher Infrastrukturinvestition | Hoch: Reisezeit, Arbeitskraft und mögliche Ausfallzeiten |
| Eignung für sicherheitskritische Systeme | Kann zusätzliche Validierung erfordern; einige Sicherheitsfunktionen benötigen möglicherweise physische Anwesenheit zur Überprüfung | Bevorzugt, wenn ein Techniker den Roboter visuell inspizieren muss oder wenn ein Fail-Safe benötigt wird |
| Compliance mit der CRA-Anforderung für kostenlose Updates | Einfacher, Updates kostenlos bereitzustellen, da keine Reisekosten anfallen | Kann kostenlos sein, aber die Arbeitskosten müssen vom Hersteller oder Servicevertrag getragen werden |
Die Wahl zwischen OTA und physischen Updates ist nicht binär. Viele Hersteller verwenden einen hybriden Ansatz: OTA für nicht-kritische Firmware und physische Besuche für größere Upgrades oder sicherheitsrelevante Patches. Für ein Servicenetzwerk bedeutet dies, Fähigkeiten in beiden Bereichen aufzubauen, aber mit dem klaren Verständnis, dass OTA der Standard für Compliance ist, weil es schneller und besser prüfbar ist.
Praktische Auswirkungen für ein Servicenetzwerk
Für ein lokales Servicenetzwerk, das in Europa aufgebaut wird, schafft der CRA eine neue Einnahmequelle: Patchen als Dienstleistung. Hersteller können die Überwachung von Schwachstellendatenbanken, die Vorbereitung von Update-Paketen und die Überprüfung der erfolgreichen Installation auslagern. Dies erfordert jedoch ein Maß an technischem Fachwissen und rechtlichem Bewusstsein, das über die traditionelle Reparatur hinausgeht.
Erstens muss das Netzwerk Zugang zum Schwachstellen-Offenlegungsprozess des Herstellers haben. Der CRA verlangt von Herstellern, eine „einzige Anlaufstelle“ für die Meldung von Schwachstellen zu unterhalten (Artikel 13(5)), verlangt jedoch nicht, dass diese mit Dritten geteilt wird. Ein Servicevertrag sollte daher Bestimmungen enthalten, dass der Hersteller den Dienstleister über relevante Schwachstellen informiert und die notwendigen Patches bereitstellt.
Zweitens muss das Netzwerk in der Lage sein, zu überprüfen, ob ein Update authentisch und nicht manipuliert ist. Dies bedeutet, dass Techniker kryptografische Signaturen verstehen und vor der Installation prüfen können müssen. In der Praxis kann dies die Verwendung eines sicheren Bootloaders beinhalten, der nur signierte Firmware akzeptiert, aber der Techniker muss dennoch bestätigen, dass das Update-Paket mit den Versionshinweisen des Herstellers übereinstimmt.
Drittens muss das Netzwerk sorgfältige Aufzeichnungen führen. Gemäß Artikel 13(9) müssen Hersteller Benutzer über Updates informieren, aber ein Dienstleister muss möglicherweise dokumentieren, dass ein Update auf einem bestimmten Gerät angewendet wurde, zu welcher Zeit und mit welchem Ergebnis. Dies dient nicht nur der Compliance, sondern auch dem Haftungsschutz: Wenn ein Roboter nach einem Update ausfällt, muss der Dienstleister nachweisen können, dass das Update korrekt durchgeführt wurde.
Schließlich muss das Netzwerk auf die Möglichkeit vorbereitet sein, dass ein Hersteller in Konkurs geht oder die Unterstützung für ein Produkt einstellt. Der CRA verlangt von Herstellern, Sicherheitsupdates für die „erwartete Lebensdauer“ des Produkts bereitzustellen (Artikel 13(8)), aber wenn der Hersteller verschwindet, kann die Verantwortung auf Importeure oder Händler übergehen. Ein Servicenetzwerk kann einspringen, um Updates bereitzustellen, muss jedoch das rechtliche Recht dazu haben, was wiederum auf die Notwendigkeit klarer Verträge hinweist.
Quellen
- EUR-Lex — Verordnung (EU) 2024/2847 — https://eur-lex.europa.eu/eli/reg/2024/2847/oj (abgerufen am 2026-03-14)
- Europäische Kommission — Cyber Resilience Act — https://digital-strategy.ec.europa.eu/ (abgerufen am 2026-03-14)