Cyber Resilience Act: Neue Pflichten für Roboterhersteller
Für Hersteller vernetzter Roboter wird der Cyber Resilience Act (CRA) jetzt praktisch relevant: Ab dem 11. September 2026 gelten erstmals die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle. Der CRA macht Cybersicherheit damit zur Produkteigenschaft und erfasst bei Physical AI nicht nur den Roboter selbst, sondern unter bestimmten Voraussetzungen auch Cloud-Backends und andere Formen der Fernverarbeitung. Zugleich kann ein Sicherheitsvorfall neben dem CRA auch Pflichten nach dem NIS2-Regime auslösen. Für Roboterhersteller kommt es deshalb darauf an, Meldeprozesse, Schwachstellenmanagement, Updates und Cyber-Risikobewertung rechtzeitig auf die neuen Anforderungen auszurichten.
Dies ist der erste von zwei Texten zum Thema IT-Sicherheit und Verkörperte KI innerhalb unserer Serie „Robotics und Physical AI“. Im Mittelpunkt steht der Cyber Resilience Act; der zweite Teil widmet sich der Betreiberperspektive unter dem deutschen NIS2-Regime sowie konkreten Handlungsempfehlungen.
Wie FCC-Importstopp, CRA und NIS2 dasselbe Risiko unterschiedlich regulieren
Ende Juli hat die US-Telekommunikationsaufsicht FCC den Marktzugang für neue, im Ausland gefertigte humanoide und vierbeinige Roboter weitreichend beschränkt – begründet unter anderem mit Cybersicherheits- und Datenabflussrisiken internetverbundener Maschinen (FCC, 28.07.2026). Die Maßnahme zielt erkennbar auf China; aufschlussreich ist aber der Vergleich der Instrumente. Auf dasselbe Risiko – den vernetzten, wahrnehmenden, aus der Ferne erreichbaren Roboter – antworten die USA mit einer weitreichenden Marktzugangsbeschränkung. Die EU antwortet mit einem produktrechtlichen Sicherheits- und Nachweisprogramm: Der CRA verlangt Cybersicherheit als Produkteigenschaft vom Hersteller. Die NIS2-Richtlinie adressiert dagegen die Organisation der erfassten Einrichtung – in unserem Szenario also den Betreiber. Beide Regime sind bereits relevant: Die Meldepflichten des CRA gelten ab dem 11. September 2026 (Art. 71 Abs. 2 CRA), das deutsche NIS2-Umsetzungsgesetz ist seit dem 6. Dezember 2025 in Kraft.
Der Serien-Auftakt hat gezeigt: Schon ein einzelner vernetzter Roboter ruft mehrere Rechtsregime nebeneinander auf den Plan. Für die IT-Sicherheit gilt das mit einer Besonderheit: Hier adressieren zwei Regime dasselbe System aus unterschiedlichen Richtungen, wobei derselbe Vorfall zwei Meldeketten auslösen kann.
Warum vernetzte Roboter besondere Cyberrisiken schaffen
Ein fiktives, aber typisches Szenario begleitet uns durch diesen Beitrag: Ein Maschinenbauer bringt einen autonomen mobilen Roboter (AMR) für die Intralogistik auf den Markt. Zum Produkt gehört ein Flottenmanager als Cloud-Dienst, den der Hersteller selbst entwickelt hat und auf angemieteter Infrastruktur eines Cloud-Anbieters betreibt: Er weist Fahraufträge zu, verteilt Software-Updates „over the air“ und berechnet aus den Kamerabildern der Flotte Navigations- und Greifkorrekturen. Ein Automobilzulieferer aus der Herstellung von Kraftwagenteilen mit 800 Beschäftigten betreibt vierzig dieser Roboter; für Störungen unterhält der Hersteller einen Fernwartungszugang bis auf die Steuerungsebene.
Teil 2 unserer Blogserie hat den Datenstrom als das eigentliche Asset der Physical AI beschrieben („Data is the asset“). Die sicherheitstechnische Kehrseite: Derselbe Datenstrom ist der Angriffspfad. Jeder Kanal, der den Roboter leistungsfähiger macht – die Telemetrie in die Cloud, der Update-Mechanismus, der neue Fähigkeiten nachlädt, der Fernwartungszugang, die Schnittstelle zum Lagerverwaltungssystem –, vergrößert zugleich seine Angriffsfläche. Und anders als beim Bürorechner steht am Ende dieses Pfades keine Datei, sondern ein bewegtes Objekt mit Masse, Geschwindigkeit und Werkzeug. Ein Cyberangriff kann hier unmittelbar auf die Maschinensicherheit durchschlagen.
Die klassische Industrierobotik hatte dieses Problem doppelt eingehegt: Die Roboterzelle war physisch abgeschlossen und netzwerkseitig eine Insel. Bei vernetzten Robotern lösen sich beide Grenzen auf. In Teil 3 unserer Blogserie haben wir beschrieben, dass der Roboter seinen Käfig verlässt und mitten unter Menschen arbeitet – dasselbe gilt netzwerkseitig: Aus der isolierten Insel wird ein dauerverbundenes System aus Gerät, Flotten-Backend und Update-Kanal. Genau an dieser Stelle setzen CRA und NIS2 an.
Cyber Resilience Act: Der CRA erfasst Roboter samt Cloud-Backend
Der CRA gilt für „Produkte mit digitalen Elementen“: Hard- und Software, deren bestimmungsgemäßer Gebrauch eine direkte oder indirekte Datenverbindung einschließt (Art. 2 Abs. 1, Art. 3 Nr. 1 CRA). Der vernetzte Roboter ist der Lehrbuchfall. Von der Steuerung über die Kommunikationsmodule bis zur mitgelieferten Software ist eine Datenverbindung für den Gebrauch notwendig. Die Pflichten sind gestaffelt: Seit dem 11. Juni 2026 gelten die Vorschriften zur Notifizierung von Konformitätsbewertungsstellen, ab dem 11. September 2026 die Meldepflichten des Art. 14, ab dem 11. Dezember 2027 das vollständige Pflichtenprogramm – Anforderungen nach Anhang I, Konformitätsbewertung, CE-Kennzeichnung, technische Dokumentation.
Seit Ende Juli gibt es dazu erstmals eine amtliche Auslegungshilfe: Die Kommission hat am 27. Juli 2026 ihre Anwendungsleitlinien zum CRA veröffentlicht (C(2026) 5252 – Leitlinien nach Art. 26 CRA; rechtlich unverbindlich). Für die Robotik ist vor allem eine Klarstellung zentral: Zum Produkt gehört auch die „Fernverarbeitung“ („remote data processing“, Art. 3 Nr. 2 CRA). Die Leitlinien machen daraus einen Drei-Fragen-Test: Findet Datenverarbeitung in der Ferne statt? Würde ihr Ausfall das Produkt an einer seiner Funktionen hindern? Und ist die Software vom Hersteller oder unter seiner Verantwortung entwickelt worden? Werden alle drei Fragen mit Ja beantwortet, gilt das Backend als Teil des Produkts. Die Folge: Es muss unter anderem in die Cyber-Risikobewertung, die Anforderungen des Anhangs I, einschließlich Software-Stückliste (SBOM), und die CRA-Meldepflichten einbezogen werden.
Die Leitlinien wählen als Anwendungsfall ausgerechnet einen Industrieroboter: Ein Roboter greift Teile, deren Position ein herstellereigener Cloud-Dienst aus den Kamerabildern berechnet – der Dienst ist Teil des Produkts, obwohl er auf angemieteter Infrastruktur eines Dritten läuft. Für unseren Flottenmanager gilt nichts anderes: Fahrauftragszuweisung, OTA-Update-Verteilung und Bildauswertung sind jeweils Funktionen des Produkts, die durch herstellereigene Software aus der Ferne erbracht werden.
Die Mietinfrastruktur darunter ist dagegen nicht Teil des Produkts, sondern eine Abhängigkeit, die der Hersteller in der Risikobewertung und technischen Dokumentation berücksichtigen muss – die Leitlinien empfehlen ausdrücklich, sich vom Infrastruktur-Anbieter die Erfüllung von dessen NIS2-Pflichten nachweisen zu lassen. Klare Grenzen zieht die Kommission ebenfalls: Telemetrie, die allein statistischen Zwecken oder der Produktentwicklung dient, ist keine Fernverarbeitung; zugekaufte Standard-Dienste („SaaS“) sind wie Komponenten zu behandeln; das Mobilfunk- oder Campusnetz ist bloßer Übertragungsweg.
Wer einen ROS-2-basierten Software-Stack nutzt, bleibt für das Gesamtprodukt verantwortlich. Bei der Integration quelloffener Komponenten gelten die Sorgfaltspflichten des Art. 13 Abs. 5 CRA. Erkennt der Hersteller eine Schwachstelle in einer integrierten Komponente, muss er sie dem Hersteller oder Maintainer der Komponente melden und Maßnahmen zu ihrer Behandlung in seinem Produkt ergreifen; hat er einen Fix entwickelt, ist grundsätzlich auch der relevante Code bzw. die Dokumentation weiterzugeben (Art. 13 Abs. 6 CRA). Für bestimmte Open-Source-Akteure („Stewards“) sieht Art. 24 CRA dagegen ein eigenes, gegenüber Herstellern reduziertes Pflichtenprogramm vor.
CRA-Meldepflichten ab 11. September 2026: Was Hersteller beachten müssen
Ab dem 11. September 2026 muss der Hersteller zwei Ereignisklassen melden: aktiv ausgenutzte Schwachstellen seines Produkts und schwerwiegende Vorfälle mit Auswirkung auf dessen Sicherheit (Art. 14 Abs. 1 und 3 CRA). Die Meldung erfolgt über die zentrale Meldeplattform („Single Reporting Platform“) an das als Koordinator zuständige CSIRT und zugleich an ENISA. Für die Plattform hat ENISA inzwischen Registrierungs- und Meldeleitfäden veröffentlicht; der operative Start ist für den 11. September vorgesehen. Die Kaskade ist eng getaktet: Frühwarnung unverzüglich, spätestens binnen 24 Stunden ab Kenntnis, vollständigere Meldung binnen 72 Stunden, Abschlussbericht binnen 14 Tagen nach Bereitstellung einer Abhilfemaßnahme (bei Vorfällen: binnen eines Monats nach der 72-Stunden-Meldung). Entscheidend für den Beginn der Meldefrist ist die „Kenntnis“ des Herstellers. Sie liegt nach den Leitlinien vor, wenn der Hersteller nach einer unverzüglichen Erstbewertung mit hinreichender Gewissheit von der aktiven Ausnutzung bzw. dem Vorfall ausgehen kann – die Uhr läuft also nicht mit dem ersten vagen Hinweis, aber die Erstbewertung duldet keinen Aufschub. Parallel sind betroffene Nutzer zu informieren (Art. 14 Abs. 8 CRA), wobei die Leitlinien eine risikobasierte, auf den betroffenen Kreis begrenzte Information ausdrücklich zulassen, es bleibt damit ein für Robotik in sensiblen Produktionsumgebungen wichtiger Spielraum.
Zwei Punkte werden unterschätzt. Einerseits die Reichweite: Die Meldepflicht gilt ab dem Stichtag für alle in den Anwendungsbereich fallenden Produkte – auch für solche, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, und über das Ende des Support-Zeitraums hinaus (Art. 69 Abs. 3, Art. 71 Abs. 2 CRA). Die Bestandsflotte ist also nicht außen vor: Was zählt, ist die Kenntnis von der aktiven Ausnutzung nach dem 11. September 2026. Eine rückwirkende Meldung ist dagegen nicht erforderlich, wenn die aktive Ausnutzung bereits vor diesem Stichtag bekannt war. Die Pflicht zur Schwachstellenbehandlung nach Anhang I Teil II gilt dagegen grundsätzlich für Produkte, die ab dem 11. Dezember 2027 in Verkehr gebracht werden, sowie für Bestandsprodukte, die ab diesem Zeitpunkt wesentlich geändert werden. Für Melden und Beheben ergeben sich somit zwei unterschiedliche Zeitpläne. Andererseits die Vorbereitung: Wer am 11. September melden können will, braucht dafür praktisch schon vorher funktionierende Aufnahmewege („Coordinated Vulnerability Disclosure“-Policy, Kontaktstelle), eine Triage, die aus einem Hinweis binnen Stunden eine belastbare Erstbewertung macht, und geklärte Zuständigkeiten zwischen Produktsicherheit, IT und Recht.
Durchgespielt am Szenario: Am Freitagabend meldet ein Sicherheitsforscher dem AMR-Hersteller, eine Schwachstelle im Update-Dienst des Flottenmanagers werde aktiv ausgenutzt. Freitagabend ist dabei kein Schonraum: Die Erstbewertung muss unverzüglich anlaufen. Sobald sie mit hinreichender Gewissheit bestätigt, dass die Schwachstelle aktiv ausgenutzt wird, beginnt die 24-Stunden-Frist – auch über das Wochenende. Binnen 72 Stunden folgt die angereicherte Meldung, und mit Bereitstellung des Patches oder einer anderen Abhilfemaßnahme beginnt die 14-Tage-Frist für den Abschlussbericht. Gemeldet ist damit aber erst die Herstellerseite – die Betreiberseite folgt im zweiten Beitrag.
Updates, Retrofit und Support-Zeitraum unter dem Cyber Resilience Act
Roboter leben lang, Software ändert sich ständig – der CRA ordnet dieses Spannungsverhältnis über zwei Begriffe: die „wesentliche Änderung“ und den Support-Zeitraum.
Eine „wesentliche Änderung“ liegt nach Art. 3 Nr. 30 CRA vor, wenn eine nachträgliche Änderung die Konformität mit Anhang I Teil I berührt oder die vorgesehene Zweckbestimmung verändert. Wird das wesentlich geänderte Produkt anschließend auf dem Markt bereitgestellt, kann dies als neues Inverkehrbringen gelten und eine erneute Konformitätsbewertung erforderlich machen. Der Maßstab der Leitlinien ist erfreulich klar: Es kommt nicht auf den Umfang der Änderung an, sondern auf das Cyber-Risikoprofil – führt das Update neue Angriffsvektoren oder Angriffsszenarien ein, erhöht es Eintrittswahrscheinlichkeit oder Schadenspotenzial bereits bekannter Szenarien. Fraglich ist dann, ob all das in der Risikobewertung schon berücksichtigt wurde. Sicherheitsupdates sind danach regelmäßig keine wesentliche Änderung, sofern sie die Zweckbestimmung nicht verändern oder neue Cyberrisiken einführen. Ebenso wenig neue Funktionen, die der Hersteller in seiner Risikobewertung bereits antizipiert hat. Aus den Leitlinien ergibt sich der Fall eines Produktionsüberwachungssystems, dessen später aktivierte Regelungsfunktionen von Anfang an mitbewertet waren. Übertragen auf die Robotik: Der nachgeladene Greif-„Skill“, den das Sicherheitskonzept vorgesehen hat, spricht eher gegen eine wesentliche Änderung; das nachgerüstete Teleoperations-Feature, das erstmals einen Fernzugriff auf die Bewegungssteuerung öffnet, ist nach obiger Definition ein Kandidat für eine wesentliche Änderung.
Übertragen auf kontinuierlich nachtrainierte Steuerungsmodelle heißt das: Nicht das Nachtraining als solches ist der Prüfstein, sondern die Frage, ob das aktualisierte Modell das bewertete Risikoprofil verlässt – eine Dokumentationsaufgabe, die im „MLOps“-Prozess mitlaufen muss.
Zwei Warnungen gehören hierher. Erstens der Doppelbegriff: Ab dem 20. Januar 2027 führt die Maschinenverordnung (VO (EU) 2023/1230) in Art. 3 Nr. 16 eine eigene, anders geschnittene Definition der „wesentlichen Veränderung“ ein – dieselbe Modifikation an derselben Maschine ist dann zweimal, nach zwei Maßstäben, zu prüfen. Zweitens, die Betreiber-Falle: Wer ein bereits in Verkehr gebrachtes Produkt wesentlich verändert und anschließend auf dem Markt bereitstellt, kann nach Art. 22 CRA selbst zum Hersteller werden; für Bestandsprodukte greifen die entsprechenden CRA-Anforderungen bei wesentlichen Änderungen ab dem 11. Dezember 2027 (Art. 69 Abs. 2 CRA). Für einen Betreiber, der weder Hersteller, noch Importeur oder Händler ist, genügt der Umbau der eigenen Flotte zum ausschließlichen Eigengebrauch hierfür nach Art. 22 CRA dagegen nicht. Anders unter der Maschinenverordnung: Dort kann auch der professionelle Betreiber, der eine Maschine für den eigenen Gebrauch wesentlich verändert, in die Herstellerrolle einrücken. Rüstet in unserem Szenario der Zulieferer seine 2024 beschaffte Bestandsflotte mit einem KI-Vision-Kit eines Drittanbieters nach, sind deshalb beide Regime getrennt zu prüfen. Stellt er nach dem CRA wesentlich geänderte Produkte anschließend auf dem Markt bereit, treffen ihn die Herstellerpflichten für den geänderten Teil oder – wenn dessen Cybersicherheit insgesamt betroffen ist – für das Gesamtprodukt.
Beim Support-Zeitraum räumen die Leitlinien mit einem verbreiteten Missverständnis auf: Die fünf Jahre des Art. 13 Abs. 8 CRA sind grundsätzlich Untergrenze, nicht Standard. Nur wenn die erwartete Nutzungsdauer eines Produkts weniger als fünf Jahre beträgt, darf auch der Support-Zeitraum entsprechend kürzer sein – bei langlebiger Industrierobotik dürfte diese Ausnahme regelmäßig nicht greifen. Ein Roboterhersteller, der pauschal fünf Jahre ansetzt, wird das gegenüber Marktüberwachung und Kunden begründen müssen; das Enddatum ist beim Kauf anzugeben (mindestens Monat und Jahr, Art. 13 Abs. 19 CRA). Eine wesentliche Änderung führt zwar zu einer erneuten Bestimmung des Support-Zeitraums, setzt ihn aber nicht automatisch neu in Gang. Ändert die Modifikation die für die erwartete Nutzungsdauer maßgeblichen Faktoren nicht, etwa wenn nur das Cloud-Backend umgebaut wird, kann der Support-Zeitraum des geänderten Produkts der verbleibenden ursprünglich bestimmten Nutzungsdauer entsprechen. Die Lücke zwischen regulatorischem Minimum und realer Laufzeit ist damit Vertragsthema: Update-Zusagen jenseits des CRA-Zeitraums, Eskalations- und End-of-Life-Regelungen gehören in Beschaffungs- und Serviceverträge – ein Vorgriff auf einen der nächsten Teile dieser Serie zum IT-Vertragsrecht.
CRA und Maschinenverordnung: Konformitätsbewertung ohne harmonisierte Normen
Wie weist der Hersteller die Konformität nach? Der Roboter als Ganzes wird nach seiner Kern-Funktionalität eingestuft; die Kategorien „wichtiger“ und „kritischer“ Produkte (Anhänge III und IV CRA) erfassen vor allem bestimmte Cybersecurity-, Netzwerk- und Systemkomponenten sowie einzelne besonders sensible vernetzte Produkte. Ein AMR oder Cobot hat als Gesamtprodukt typischerweise nicht die Kern-Funktionalität einer solchen Kategorie und kann damit grundsätzlich im Verfahren der internen Kontrolle bewertet werden – aber Vorsicht bei der Produktarchitektur: Wer Module auch separat vermarktet (etwa den Flottenmanager als eigenständiges Produkt), muss jedes Modul nach seiner eigenen Kern-Funktionalität einstufen. Robotersteuerungen und Kommunikationsmodule verdienen hier eine Einzelfallprüfung; die pauschale Aussage, Maschinen fielen nie unter die Anhänge, trägt nicht.
Praktisch gewichtiger ist die Normenlage: Stand August 2026 ist für den CRA noch keine harmonisierte Norm im EU-Amtsblatt gelistet. Hersteller können sich daher derzeit nicht auf die Konformitätsvermutung nach Art. 27 CRA stützen. Nach dem Normungsauftrag M/606 werden die ersten Normungsprodukte zum horizontalen Rahmen und zur Schwachstellenbehandlung für Ende August 2026 erwartet; die produktspezifischen Standards für die Kategorien der Anhänge III und IV sollen bis Ende Oktober 2026 folgen. Eine Konformitätsvermutung entsteht erst, wenn die jeweiligen Fundstellen anschließend im Amtsblatt veröffentlicht werden. Die Robotik kennt diese Lage bereits von der Maschinenverordnung, für die die ISO 10218:2025 bislang nicht harmonisiert ist – zwei parallele Vermutungslücken, in denen der Stand der Technik dokumentiert werden muss, statt ihn über eine gelistete Norm zu vermuten.
Umso wertvoller ist eine Brücke, die die Leitlinien ausdrücklich bestätigen: EU-Baumusterprüfbescheinigungen, die unter der Maschinenverordnung für deren Cyber-Anforderungen ausgestellt werden – Schutz gegen Korrumpierung und Sicherheit von Steuerungen (Anhang III Abschnitte 1.1.9 und 1.2.1 MaschVO) –, bleiben für die dort abgedeckten Cyber-Risiken auch für Zwecke des CRA gültig, längstens bis zum 11. Juni 2028 (Art. 69 Abs. 1 CRA). Wer die MaschVO-Konformitätsbewertung ab 2027 klug aufsetzt, muss die davon erfassten Cyber-Risiken für den CRA also nicht erneut bewerten und nachweisen: Safety- und Security-Nachweis lassen sich verzahnen. Für die verbleibenden CRA-Risiken – etwa Schwachstellen-Handling, Angriffsflächen-Minimierung, Update-Mechanik – bleibt der Hersteller in der Pflicht.
CRA und NIS2: Ein Cybervorfall, zwei Meldeketten
Zurück zum Freitagabend-Szenario: Während der Hersteller die ausgenutzte Schwachstelle meldet, steht beim Betreiber die Intralogistik still – der kompromittierte Update-Dienst hat die Flotte in den sicheren Halt geschickt. An die Meldepflichten des Betreibers knüpft der in 14 Tagen folgende Beitrag zum deutschen NIS2-Regime an, in dem wir auch praktische Handlungsempfehlungen zur Umsetzung von CRA und NIS2 geben.
Cyber Resilience Act für Roboterhersteller: Was jetzt zu tun ist
- Ab dem 11. September 2026 greifen die CRA-Meldepflichten: Roboterhersteller müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle innerhalb enger Fristen melden.
- Bei vernetzten Robotern kann auch das Cloud-Backend Teil des Produkts sein: Entscheidend ist insbesondere, ob die Fernverarbeitung für Produktfunktionen erforderlich ist und die Software vom Hersteller oder unter seiner Verantwortung entwickelt wurde.
- Die Bestandsflotte ist bei den Meldepflichten nicht automatisch außen vor: Für Melden und Beheben gelten unterschiedliche zeitliche Anwendungsregeln.
- Schwachstellenmanagement muss vor dem Stichtag funktionieren: Hersteller benötigen insbesondere Aufnahmewege für Meldungen, eine schnelle Triage sowie klare Zuständigkeiten zwischen Produktsicherheit, IT und Recht.
- Updates und Retrofits können eine neue CRA-Prüfung auslösen: Entscheidend ist nicht allein der Umfang einer Änderung, sondern insbesondere, ob sie das bewertete Cyber-Risikoprofil oder die Zweckbestimmung verändert.
- Der Support-Zeitraum sollte zur realen Lebensdauer des Roboters passen: Die fünf Jahre des CRA sind grundsätzlich Untergrenze und nicht pauschaler Standard.
- CRA und Maschinenverordnung sollten gemeinsam gedacht werden: Safety- und Security-Nachweise können teilweise verzahnt werden; zugleich müssen wesentliche Änderungen nach beiden Regelwerken getrennt geprüft werden.
Building the legal stack for Physical AI.
Redaktioneller Hinweis: Die Angaben geben den Stand zum Redaktionsschluss (31. Juli 2026) wieder; die Kommissionsleitlinien C(2026) 5252 lagen zu diesem Zeitpunkt in der am 27. Juli 2026 gebilligten englischen Fassung vor und werden erst mit Vorliegen aller Sprachfassungen förmlich angenommen. Vor einer konkreten Umsetzung sind die Primärquellen (EUR-Lex, ENISA, BSI) heranzuziehen.
*Gemeint sind Personen jeder Geschlechtsidentität. Um der leichteren Lesbarkeit willen wird im Beitrag die grammatikalisch männliche Form verwendet.
Related Experts
