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). Anders als bei reiner Maschinenrichtlinien-Welt reicht es nicht mehr, dass die Achse nicht in den Bediener fährt: Der CRA verlangt, dass der Roboter auch gegen Manipulation, Übernahme und ungepatchte Schwachstellen abgesichert ist — über den gesamten Support-Zeitraum.

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 zivile Luftfahrt-Regulierung im Blick behalten und sauber trennen, was unter EASA-Typgenehmigung fällt (dann CRA-ausgenommen) und was als Consumer- oder Industrie-Drohne sehr wohl unter den CRA fällt. Diese Regime greifen parallel, nicht alternativ — und viele Hersteller unterschätzen, dass Cybersicherheit kein Anhängsel des bestehenden CE-Prozesses ist, sondern 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 kommt oft von Zulieferern, und Flotten stehen jahrelang im Feld. Wer heute keinen belastbaren Überblick über seine Komponenten und keinen definierten Update- und Meldeprozess hat, wird die CRA-Fristen nur unter Druck erreichen. 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

Der weit überwiegende Teil der Robotik- und Drohnenprodukte dürfte in die Standardkategorie fallen — dort ist die interne Konformitätsbewertung (Modul A, Selbstbewertung) vorgesehen. „Wichtig" im Sinne von Anhang III wird ein Produkt erst über eine der dort gelisteten Funktionsklassen. Für Robotik/Drohnen ist das meist keine Kernfunktion des Roboters selbst, sondern eine sicherheitskritische Teilkomponente (z. B. eine VPN-/PKI-Funktion in der Fernsteuerung). Die folgende Tabelle ist eine schematische Orientierung, kein rechtsverbindliches Einzelfall-Urteil:

Merksatz: Für die große Mehrheit gilt Standard + Modul A. Sobald eine im Produkt gelieferte Komponente eine Anhang-III-Funktion erfüllt (typischerweise Klasse I über VPN/PKI), verschiebt sich der Pfad — bei Klasse I bleibt Selbstbewertung nur möglich, wenn die einschlägigen harmonisierten Normen vollständig angewandt werden, sonst muss eine notifizierte Stelle eingebunden werden. 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 — funktionale Maschinensicherheit (nebst ISO 10218 für Industrieroboter, ISO 13849 für Steuerungen). Sie adressiert, dass die Maschine niemanden verletzt; der CRA adressiert, dass die digitalen Elemente nicht kompromittiert werden. Beide gelten parallel — der eine verdrängt den anderen nicht.
• Zivile Luftfahrt / EASA — typgenehmigte Luftfahrt ist vom CRA ausgenommen. Viele Consumer- und Industrie-Drohnen laufen aber nicht über Typgenehmigung, sondern über die offene/spezielle Kategorie und fallen damit unter den CRA. Diese Abgrenzung im Einzelfall zu klären ist der erste Schritt.
• RED / Funk-Delegierte-Verordnung 2022/30 — für die Funkschnittstelle relevant; hier gibt es inhaltliche Überschneidungen mit CRA-Cybersicherheitsanforderungen, die abzugrenzen sind.
• NIS2 adressiert Betreiber wesentlicher/wichtiger Einrichtungen, nicht das Produkt — ein Drohnendienstleister kann NIS2-pflichtig sein, während der Drohnenhersteller CRA-pflichtig ist. Getrennte Rechtsakte.
• AI Act — greift für KI-Komponenten (Wahrnehmung, autonome Navigation) mit eigenen Pflichten; er ersetzt den CRA nicht, sondern tritt hinzu.

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

Kaum eine Branche hat einen so tiefen Open-Source-Stack wie die Robotik. 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 maschinenlesbare SBOM als Teil der technischen Dokumentation — im Format CycloneDX ab Version 1.6 oder SPDX ab Version 3.0.1 (vgl. BSI TR-03183-2). Sie muss mindestens die Top-Level-Abhängigkeiten mit Komponenten, Versionen und Lieferant abbilden und ist 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

Ab 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 stehen, bevor die Produktanforderungen voll greifen. Die Kaskade ist präzise einzuhalten:

• 24 Stunden — Frühwarnung ab Kenntnisnahme einer aktiv ausgenutzten Schwachstelle oder eines schweren Sicherheitsvorfalls.
• 72 Stunden — vollständige Meldung, inklusive der ergriffenen bzw. geplanten Korrektur- und Minderungsmaßnahmen.
• 14 Tage — Abschlussbericht bei einer aktiv ausgenutzten Schwachstelle, gerechnet ab Verfügbarkeit einer Korrekturmaßnahme.
• 1 Monat — Abschlussbericht bei einem schweren Sicherheitsvorfall, gerechnet ab der 72-Stunden-Meldung.

Die Meldung läuft über die ENISA Single Reporting Platform (SRP), die zum Stichtag bereitzustellen ist, an das CSIRT der Hauptniederlassung und ENISA. Die pauschale Merkregel „24h/72h/14 Tage" ist falsch: Die 14-Tage-Frist gilt nur für die aktiv ausgenutzte Schwachstelle, für schwere Vorfälle gilt ein Monat.

Welche Frist zuerst zählt: 11.09.2026 vor 11.12.2027

Für die Priorisierung ist die Reihenfolge entscheidend. Zuerst greift am 11.09.2026 die Melde- und Berichtspflicht (Art. 14) — hier 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 nach Inverkehrbringen zehn Jahre aufzubewahren, der Support-Zeitraum orientiert sich an der erwarteten Lebensdauer mit einem Richtwert von mindestens fünf Jahren — 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, die Kernsteuerung in der Standardkategorie liegt (Modul A), aber die integrierte VPN-Fernwartung als Klasse-I-Kandidat zu prüfen ist. 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. Bis 11.09.2026 steht der PSIRT-/CVD-Prozess; wird eine aktiv ausgenutzte Schwachstelle in der Fernwartung bekannt, laufen 24-h-Frühwarnung, 72-h-Meldung und 14-Tage-Abschlussbericht über die SRP. 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

Die Blackfort Technology UG (haftungsbeschränkt) begleitet Robotik- und Drohnenhersteller entlang genau dieser Kette — praxisnah, herstellernah und ohne Rechtsberatung zu ersetzen:

• Betroffenheits- und Scope-Analyse: Welche Ihrer Produkte sind PDE, was fällt unter EASA-Typgenehmigung, wo greift Standard/Modul A und wo droht eine Anhang-III-Klasse-I-Einordnung über Teilkomponenten.
• SBOM-Setup: Aufbau maschinenlesbarer SBOMs (CycloneDX ≥ 1.6 / SPDX ≥ 3.0.1) 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 (24h/72h/14 Tage bzw. 1 Monat) und Anbindung an die SRP.
• 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 zehn Jahre aufzubewahrenden Doku, Trennung von Security- und Safety-Nachweis, EU-Konformitätserklärung und CE.

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.