CRA in Robotik & Drohnen

Warum der CRA gerade Robotik- und Drohnenhersteller mitten trifft

Roboter und unbemannte Systeme sind heute das Paradebeispiel für ein „Produkt mit digitalen Elementen" (PDE): ein Serviceroboter, ein fahrerloses Transportfahrzeug oder eine Industriedrohne ist zu großen Teilen Software - Wahrnehmungs- und Navigationsstacks, Firmware auf Motorcontrollern, Funk- und Fernsteuerung, Over-the-Air-Updates, Cloud-Anbindung für Flottenmanagement. Genau solche Produkte mit direkter oder indirekter Datenverbindung adressiert der Cyber Resilience Act (Verordnung (EU) 2024/2847). Neben der Maschinensicherheit verlangt der CRA, dass der Roboter gegen Manipulation, Übernahme und ungepatchte Schwachstellen abgesichert ist - über den gesamten Unterstützungszeitraum.

Der reale Schmerz dieser Branche ist die Vielschichtigkeit. Ein AMR-Hersteller jongliert mit Maschinensicherheit (Maschinenverordnung (EU) 2023/1230), funktionaler Sicherheit (ISO 10218, ISO 13849), Funkregulierung (RED) und jetzt zusätzlich Produkt-Cybersicherheit. Ein Drohnenhersteller muss zusätzlich die Luftfahrt-Regulierung im Blick behalten: Vom CRA ausgenommen sind Produkte, die nach der Verordnung (EU) 2018/1139 zertifiziert worden sind (Art. 2 Abs. 3). Diese Regime greifen nebeneinander - und Cybersicherheit bildet darin eine eigene Nachweiskette mit eigener Dokumentation, eigener Schwachstellenbehandlung und eigener Meldepflicht.

Hinzu kommt die Software-Realität: Robotik lebt von Open Source (ROS/ROS 2, unzählige Bibliotheken, ML-Frameworks), Firmware kann von Zulieferern stammen, und Flotten stehen jahrelang im Feld. Ein verlässlicher Überblick über die eigenen Komponenten und ein definierter Update- und Meldeprozess sind deshalb die Grundlage, um die CRA-Fristen zu halten. Dieser Beitrag ordnet die Lage branchenspezifisch ein - er ist eine fachliche Orientierung und keine Rechtsberatung.

Typische PDE-Produkte, wahrscheinliche Anhang-III-Einordnung und Konformitätspfad

Robotik- und Drohnenprodukte ohne Anhang-III-Kernfunktion dürften in die Standardkategorie fallen - dort ist die interne Konformitätsbewertung (Modul A, Selbstbewertung) vorgesehen. „Wichtig" im Sinne von Anhang III wird ein Produkt erst, wenn seine Kernfunktion einer der dort gelisteten Kategorien entspricht (Art. 7 Abs. 1). Eine eingebaute Komponente mit Anhang-III-Funktion stuft den Roboter für sich genommen nicht hoch (Art. 7 Abs. 1 Satz 2). Die folgende Tabelle ist eine schematische Orientierung, kein rechtsverbindliches Einzelfall-Urteil:

Merksatz: Ohne Anhang-III-Kernfunktion gilt Standard + Modul A. Eine eingebaute VPN- oder PKI-Komponente stuft den Roboter nicht hoch; Klasse I wird erst relevant, wenn Sie eine solche Komponente, etwa eine Fernwartungs-Box oder Software mit VPN-Funktion, als eigenes Produkt in Verkehr bringen. Für ein solches Klasse-I-Produkt bleibt Selbstbewertung nur möglich, wenn harmonisierte Normen, gemeinsame Spezifikationen oder ein europäisches Cybersicherheitszertifizierungsschema (mindestens Vertrauenswürdigkeitsstufe „mittel“) vollständig angewandt werden, sonst muss eine notifizierte Stelle eingebunden werden (Modul B+C oder H). Die technischen Beschreibungen der wichtigen/kritischen Kategorien konkretisiert die Durchführungsverordnung (EU) 2025/2392.

Branchennormen und Abgrenzung zu angrenzenden Regimen

Für die Steuerungssicherheit ist IEC 62443 die einschlägige Normenfamilie (Security für industrielle Automatisierungs- und Steuerungssysteme) - sie liefert die Struktur für sichere Entwicklung, Härtung und Schwachstellenbehandlung, die der CRA im Kern verlangt. Wichtig ist die saubere Trennung der Schutzziele:

• Maschinenverordnung (EU) 2023/1230 (nebst ISO 10218 für Industrieroboter, ISO 13849 für Steuerungen): Sie regelt die Sicherheit der Maschine einschließlich des Schutzes gegen Korrumpierung und der Sicherheit von Steuerungen (Anhang III Abschnitte 1.1.9 und 1.2.1); der CRA regelt die Cybersicherheit der digitalen Elemente. Beide gelten nebeneinander; CRA-Nachweise können die Erfüllung der genannten Anforderungen erleichtern (Erwägungsgrund 53).
• Luftfahrt / EASA - ausgenommen sind Produkte, die nach der Verordnung (EU) 2018/1139 zertifiziert worden sind (Art. 2 Abs. 3). Ob das auch für Drohnen der offenen Kategorie mit Klassenkennzeichnung gilt, ist eine Auslegungsfrage, die im Einzelfall zu klären ist. Diese Abgrenzung ist der erste Schritt.
• RED / Funk-Delegierte-Verordnung 2022/30: für Funkschnittstellen relevant, über die das Gerät mit dem Internet kommuniziert; bis zu ihrer Aufhebung zum 11.12.2027 gibt es inhaltliche Überschneidungen mit CRA-Cybersicherheitsanforderungen, die abzugrenzen sind.
• NIS2 adressiert wesentliche und wichtige Einrichtungen, nicht das Produkt - ein Drohnendienstleister kann NIS2-pflichtig sein, während der Drohnenhersteller CRA-pflichtig ist. Hersteller elektronischer Erzeugnisse oder elektrischer Ausrüstungen können ab mittlerer Größe selbst unter NIS2 fallen (Anhang II Nr. 5); das betrifft dann die Organisation, nicht die Produktkonformität. Getrennte Rechtsakte.
• AI Act - gilt zusätzlich zum CRA, sobald ein KI-System verbaut ist (Wahrnehmung, autonome Navigation); der Umfang der Pflichten hängt von der Risikostufe ab.

Der CRA-Nachweis fokussiert also auf Security-by-Design und -Default, Härtung und Vulnerability-Handling - funktionale Sicherheit bleibt ein separater, paralleler Strang.

SBOM- und Lieferketten-Realität in der Robotik

Robotik baut auf einem tiefen Open-Source-Stack auf. Ein typischer Roboter kombiniert ein Echtzeit-/Linux-Betriebssystem, ROS oder ROS 2 als Middleware, dutzende bis hunderte OSS-Pakete für Navigation, Perzeption und Bildverarbeitung, ML-Bibliotheken sowie zugelieferte Firmware auf Motor-, Funk- und Sensorcontrollern. Genau hier liegen die Risiken: End-of-Life-Komponenten (etwa eine ROS-Distribution nach Support-Ende), transitiv eingeschleppte verwundbare Bibliotheken und Firmware-Blobs von Zulieferern, für die der Hersteller trotzdem geradestehen muss.

Der CRA verlangt eine Software-Stückliste in einem gängigen maschinenlesbaren Format, aus der zumindest die obersten Abhängigkeiten hervorgehen (Anhang I Teil II Nr. 1), als Teil der technischen Dokumentation. Ein bestimmtes Format schreibt die Verordnung nicht vor; die Kommission kann Format und Elemente per Durchführungsrechtsakt festlegen (Art. 13 Abs. 24). Die Technische Richtlinie BSI TR-03183-2 (v2.1.0) empfiehlt CycloneDX ab Version 1.6 oder SPDX ab Version 3.0.1; sie ist eine nationale Empfehlung, keine Pflicht aus dem CRA. Mit Komponenten, Versionen und Lieferant ist die SBOM die Grundlage dafür, bei einer neuen CVE innerhalb von Stunden zu wissen, ob und welche Produkte betroffen sind. Eine allgemeine Veröffentlichungspflicht der SBOM besteht nicht - sie gehört in die Doku, nicht zwingend ins Datenblatt. Offen und branchenspezifisch zu klären ist, ob eingebettete KI-Modelle in die SBOM aufzunehmen sind; das ist zu entscheiden und zu dokumentieren. Und: Updatefähigkeit ist Pflicht, darf aber die Betriebs- und Maschinensicherheit nicht aushebeln - Sicherheitsupdates müssen so ausgerollt werden, dass die Konformität nach Maschinenverordnung unberührt bleibt.

Meldefähigkeit und PSIRT: die Art.-14-Kaskade korrekt

Seit dem 11.09.2026 greift die Melde- und Berichtspflicht nach Art. 14, die erste harte Herstellerpflicht überhaupt. Für Robotik- und Drohnenhersteller bedeutet das: Ein funktionierender PSIRT-Prozess (Product Security Incident Response Team) und eine Coordinated-Vulnerability-Disclosure-Policy müssen schon jetzt stehen, lange bevor die Produktanforderungen voll greifen. Die Kaskade ist präzise einzuhalten:

• 24 Stunden - Frühwarnung: unverzüglich, spätestens 24 Stunden nach Kenntnis einer aktiv ausgenutzten Schwachstelle oder eines schwerwiegenden Sicherheitsvorfalls.
• 72 Stunden - Meldung: unverzüglich, spätestens 72 Stunden nach Kenntnis, mit den verfügbaren allgemeinen Informationen und den ergriffenen Korrektur- oder Risikominderungsmaßnahmen.
• 14 Tage - Abschlussbericht bei einer aktiv ausgenutzten Schwachstelle, gerechnet ab Verfügbarkeit einer Korrektur- oder Risikominderungsmaßnahme.
• 1 Monat - Abschlussbericht bei einem schwerwiegenden Sicherheitsvorfall, gerechnet ab der 72-Stunden-Meldung.

Die Meldung läuft über die einheitliche Meldeplattform (Art. 16), über den Endpunkt des als Koordinator benannten CSIRT im Mitgliedstaat Ihrer Hauptniederlassung, gleichzeitig für ENISA zugänglich. Die pauschale Merkregel „24h/72h/14 Tage" ist falsch: Die 14-Tage-Frist gilt nur für die aktiv ausgenutzte Schwachstelle, für schwerwiegende Vorfälle gilt ein Monat.

Welche Frist zuerst zählt: 11.09.2026 vor 11.12.2027

Für die Priorisierung zählt die Reihenfolge. Zuerst griff am 11.09.2026 die Melde- und Berichtspflicht (Art. 14); seitdem muss der PSIRT-/CVD-Prozess laufen. Erst am 11.12.2027 werden die vollen Produktanforderungen (Security-by-Design, SBOM, technische Doku, EU-Konformitätserklärung, CE) anwendbar. Wer also priorisieren muss, richtet den Meldeprozess zuerst ein und baut die vollständige Produktkonformität mit klarem Zieldatum 2027 auf. Die technische Dokumentation ist mindestens zehn Jahre nach Inverkehrbringen oder für den längeren Unterstützungszeitraum aufzubewahren (Art. 13 Abs. 13); der Unterstützungszeitraum orientiert sich an der erwarteten Nutzungsdauer, in der Regel mit einer Mindestdauer von fünf Jahren, kürzer nur bei kürzerer voraussichtlicher Nutzungsdauer (Art. 13 Abs. 8) - für Feldflotten in der Robotik eine realistische Größe.

Durchgespieltes Szenario: ein AMR-Hersteller

Ein mittelständischer Hersteller autonomer mobiler Roboter (AMR) für Intralogistik liefert seine Fahrzeuge mit einem ROS-2-basierten Stack, einer Fleet-Management-Software und OTA-Updates aus. Schematisch durchgespielt hieße das: In der Betroffenheitsanalyse zeigt sich, dass das AMR als PDE unter den CRA fällt und in der Standardkategorie liegt (Modul A). Die integrierte VPN-Fernwartung stuft das AMR nicht hoch; verkauft der Hersteller die Fernwartungs-Box auch separat als eigenes Produkt, ist sie als Klasse-I-Produkt (Anhang III Nr. 5) zu bewerten. Für die SBOM wird der ROS-2-Stack samt transitiver OSS- und ML-Abhängigkeiten in CycloneDX 1.6 erfasst und an die CI-Pipeline gekoppelt, sodass jede neue CVE automatisch gegen die Feldflotte abgeglichen wird. Der Security-Nachweis (IEC-62443-orientiert) wird sauber von der funktionalen Sicherheit (ISO 13849/10218, Maschinenverordnung) getrennt dokumentiert. Seit dem 11.09.2026 muss der PSIRT-/CVD-Prozess stehen; wird eine aktiv ausgenutzte Schwachstelle in der Fernwartung bekannt, laufen Frühwarnung (unverzüglich, spätestens nach 24 Stunden), Meldung (spätestens nach 72 Stunden) und 14-Tage-Abschlussbericht über die einheitliche Meldeplattform. Sicherheitsupdates werden so ausgerollt, dass die Maschinen-Konformität nach VO 2023/1230 unberührt bleibt. Bis 11.12.2027 ist die vollständige technische Doku inklusive Konformitätserklärung fertig.

Was Blackfort Technology für Sie tut

Blackfort Technology begleitet Robotik- und Drohnenhersteller entlang genau dieser Kette - praxisnah, herstellernah und ohne Rechtsberatung zu ersetzen:

• Betroffenheits- und Scope-Analyse: technische Einschätzung, welche Ihrer Produkte PDE sind, wo die Luftfahrt-Ausnahme in Betracht kommt, wo Standard/Modul A gilt und welche separat vertriebenen Komponenten in Anhang III Klasse I fallen.
• SBOM-Setup: Aufbau maschinenlesbarer SBOMs, etwa in CycloneDX oder SPDX, für ROS-basierte Stacks, Integration in die Build-Pipeline und Verknüpfung mit dem Schwachstellenabgleich.
• PSIRT & CVD: Aufbau des Meldeprozesses nach Art. 14 mit korrekter Kaskade (Frühwarnung, Meldung, Abschlussbericht nach 14 Tagen bzw. 1 Monat) und Anbindung an die einheitliche Meldeplattform.
• Risikobewertung & Threat-Modeling: die nach Art. 13 und Anhang I dokumentationspflichtige Risikobewertung, methodisch als Threat-Modeling für Ihre Robotik-/Drohnen-Architektur.
• Technische Dokumentation: Aufbau der Unterlagen nach Anhang VII bis zur EU-Konformitätserklärung, aufbewahrt mindestens zehn Jahre oder für den längeren Unterstützungszeitraum (Art. 13 Abs. 13), mit Trennung von Security- und Safety-Nachweis.

Der pragmatische Einstieg ist unser Betroffenheits-Check. Für kleinere Hersteller lohnt der Blick auf die KMU-Perspektive, den Gesamtrahmen erläutert die Seite Cyber Resilience Act. Wenn Sie Ihre konkrete Situation besprechen möchten, erreichen Sie uns über Kontakt.