Industrieroboter & Cobots: wichtige Produkte unter dem CRA?
Zusammenfassung
Dieser Leitfaden begleitet eine fiktive Version eines Cobots von der Klassifizierung über die Produktgrenze, die Risikobewertung, die SBOM, die Versionssignatur, die Meldung von Schwachstellen bis hin zur Übergabe zwischen den Wirtschaftsakteuren. Dieselbe Struktur eignet sich für einen 6-Achs-Arm, eine kollaborative Zelle oder eine Robotersteuerung, die mit optionaler Bildverarbeitung und Flottencloud-Diensten verkauft wird.
- Der Standardweg ist der Ausgangspunkt. Industrieroboter und Cobots stehen heute nicht auf den CRA-Listen wichtiger oder kritischer Produkte. Behandeln Sie jedes Angebot, in dem Firewall-, Netzwerkmanagement- oder manipulationssichere Controller-Funktionen dominieren, als gesonderte Klassifizierung.
- Beginnen Sie mit dem Abgrenzungsmemo. Benennen Sie die genaue Variante: Arm, Steuerschrank, Programmierhandgerät, Feldbusoptionen, Laufzeitumgebung, Flottenkonnektor oder Cloud, Verwendungszweck, gelieferte digitale Elemente, Supportzeitraum und Grund für den gewählten Weg.
- Cybersicherheit und Maschinensicherheit überschneiden sich ab 2027. ISO 10218-1:2025 ergänzt Cybersicherheitsanforderungen, soweit sie die Sicherheit des Roboters betreffen, und die Maschinenverordnung gilt ab dem 20. Januar 2027. Das CRA-Dossier und der Sicherheitsnachweis teilen sich an diesen Punkten Nachweise.
- Der Support benötigt ein glaubwürdiges Datum. Der Supportzeitraum beträgt mindestens fünf Jahre, es sei denn, die voraussichtliche Nutzungsdauer ist kürzer. Viele Roboter laufen in der Fabrik deutlich länger; das Dossier muss daher ein Fenster benennen, das der Hersteller einhalten kann, und das Datum des Supportendes vor dem Kauf kommunizieren.
- Die Verwaltung von Schwachstellen ist ein Betriebsmodell. Das Dossier muss benennen, wer Warnungen erhält, wer Wartungsfenster freigibt, wer ein Update zurückrollen darf und wie verbleibende Hinweise sichtbar bleiben.
- Auch die Übergabe ist ein Nachweis. Der Hersteller bewahrt das Produktdossier auf; der Integrator bewahrt das Dossier der fertigen Zelle auf, wenn diese unter seinem Namen ausgeliefert wird; der Betreiber betreibt die Zelle. Jede Übergabe wird dokumentiert und nicht informell an den Kunden weitergereicht.
Wie wird eine Version eines Industrieroboters oder Cobots klassifiziert?
Beginnen Sie mit dem Angebot, nicht mit dem Arm. Ein 6-Achs-Arm, der an einen Integrator verkauft wird, und derselbe Arm, der als komplette Cobot-Zelle an einen kleinen Betrieb verkauft wird, sind unterschiedliche CRA-Produkte. Der Weg hängt davon ab, was der Kunde kauft, welche Steuerung und welches Programmierhandgerät geliefert werden und ob der Hersteller auch die Flottencloud, die Sicherheitskonfiguration und den OTA-Aktualisierungsweg bereitstellt.
Die Abbildung legt den Weg fest. Die Matrix legt das Abgrenzungsmemo fest: Sobald die Variante gewählt ist, sind dies die Nachweiszeilen, die der Hersteller für diese konkrete Variante ausfüllen können sollte.
Verkauf als Komponente; der Integrator baut die Zelle auf.
Arm, Steuerung, Programmierhandgerät, Laufzeitumgebung, Feldbusoptionen, signierte Aktualisierungen, Prozess zur Verwaltung von Schwachstellen und Integratorhandbuch.
Schreibrechte der Engineering-Station, Recovery-Slot, Feldbusexposition, Verfolgung von Lieferantenhinweisen und Rotation von Zugangsdaten bei Stilllegung der Zelle.
Kollaborativer kraftbegrenzter Arm, einsatzbereite Konfiguration, optionale Bildverarbeitung und Flottencloud.
Arm, Steuerung, Programmierhandgerät, Sicherheitskonfiguration, Bildsensor, Laufzeitumgebung, Flottencloud-Konnektor und OTA-Dienst.
Kollaborativer Modus, Rolle des Bedieners im geteilten Arbeitsraum, Autorität der Flottencloud, Konten am Handgerät und Weg signierter Sicherheits-Firmware.
Weiterverkauf innerhalb einer Verpackungslinie oder Prozessmaschine unter der CE-Kennzeichnung des Integrators.
Der Roboterhersteller behält in seinem Dossier Arm, Steuerung, Programmierhandgerät und gelieferte Software. Die fertige Maschine besitzt ein eigenes Dossier unter der CE-Kennzeichnung des Integrators.
Lieferantenhinweise zu RT OS, Feldbus und Bildverarbeitung; Konsistenz der Konformitätserklärungen der Lieferanten; Exposition während der Integration; Passung des Supports mit dem Maschinenhersteller.
Was gehört zur Produktgrenze des Roboters?
Bei einem Roboter oder Cobot fällt die Grenze nicht immer mit dem Zellenzaun zusammen. Sie fällt mit dem zusammen, was der Hersteller liefert und betreut: Arm, Steuerschrank, Firmware, Laufzeitumgebung, Programmierhandgerät, signierte Aktualisierungen, Cloud-Konnektor und Benutzerdokumentation. Was der Kunde oder der Integrator beisteuert, liegt standardmäßig außerhalb, sofern der Hersteller es nicht als Teil des Angebots ausliefert.
Welcher Konformitätsbewertungsweg ist anwendbar?
Industrieroboter und Cobots stehen heute nicht auf den CRA-Listen wichtiger oder kritischer Produkte, daher ist der Standardweg die Planungsannahme. Der Hersteller kann zwischen interner Kontrolle, EU-Baumusterprüfung mit Konformität zum Baumuster, umfassender Qualitätssicherung oder einem anwendbaren europäischen Zertifizierungsschema für Cybersicherheit wählen. Die Wahl hängt nicht von der Anwendung harmonisierter Normen ab.
Die Bedingung „Normen vollständig angewendet” gehört zum Rückfallweg für wichtige Produkte, nicht zum Standardweg. Sollte eine künftige Aktualisierung ein Roboter- oder Cobot-Teilprodukt in diese Liste aufnehmen und die verfügbaren Normen oder Schemata die einschlägigen wesentlichen Anforderungen nicht abdecken, benötigt der Hersteller für den nicht abgedeckten Teil eine Bewertung durch Dritte. Die Liste umfasst heute keine Roboter.
Die Maschinenverordnung 2023/1230 gilt ab dem 20. Januar 2027 und enthält Sicherheitsanforderungen, die sich mit Cybersicherheitsnachweisen überschneiden, insbesondere Schutz vor Korruption und Zuverlässigkeit der Steuerungssysteme. Behandeln Sie das CRA-Dossier und das Maschinensicherheitsdossier als zwei Stränge derselben Produktakte.
Welche Architekturkontrollen gehören in das Roboterdossier?
Das Dossier muss erläutern, wie der Hersteller die Punkte kontrolliert, an denen ein digitaler Befehl Bewegung, Sicherheitskonfiguration oder Aktualisierungszustand verändern kann.
| Architekturpunkt | Was geprüft wird | Mindestnachweis |
|---|---|---|
| Steuerung und Bewegungs-CPU | Wer Logik, Parameter und Firmware schreiben darf | Rechtemodell, Firmware-Signatur, Änderungsprotokoll |
| Programmierhandgerät | Welche Rollen den Roboter bewegen, Programme laden oder den Modus ändern dürfen | Rollenmatrix, Nachweis der Zugangsdaten, Sitzungsaudit |
| Feldbus | Welcher Datenverkehr den Bewegungszyklus beeinflussen kann | Protokollliste, Segmentierungsregeln, Test mit anomalen Frames |
| Flottencloud | Welche entfernten Befugnisse über Aktualisierungen und Telemetrie bestehen | Endpunktkarte, Zertifikate, Wartungsfenster, Rollback |
| Lokaler Service | Wie USB, Recovery und temporäre Tunnel gesteuert werden | Servicemodus, Eingriffsprotokoll, Nachweis automatischer Schließung |
Wie wird die Risikobewertung des Roboters aufgebaut?
Welches Produkt bewerten wir?
Das Beispiel verwendet eine komplette Cobot-Zelle, die an ein KMU verkauft wird: kraftbegrenzter Arm, Steuerung, Programmierhandgerät, vorbereitete Sicherheitskonfiguration, optionale Bildverarbeitung, Flottencloud-Konnektor, signierte Aktualisierungen und Benutzerdokumentation. Es bewertet keine vollständige Fertigungslinie und keine vom Integrator entworfene Zelle, außer an den Übergabepunkten.
| Umfangsentscheidung | Wahl im Beispiel | Warum es zählt |
|---|---|---|
| Variante | Komplette Cobot-Zelle | Der Hersteller bewahrt das vollständige Produktdossier auf |
| Digitale Grenze | Steuerung, Handgerät, Firmware, Bildverarbeitung, Cloud, OTA | Genau das kann Bewegung, Konfiguration oder Verfügbarkeit ändern |
| Kunde | KMU-Betreiber | Geringeres internes Sicherheitsteam, stärkere Abhängigkeit vom Hersteller |
| Integrator | Darf installieren, kennzeichnet das Produkt aber nicht um | Die Übergabe besteht, verschiebt aber das Dossier nicht automatisch |
Bevor Sie die Bedrohungstabelle schreiben, prüfen Sie die drei Wege, die das Roboterrisiko meist bestimmen: Programmladevorgänge und Handgeräteautorität, Grenze zwischen funktionaler Sicherheit und Cybersicherheit sowie Übergabe an den Integrator. Die Abbildung verwandelt das Beispiel in Ingenieurfragen statt in eine generische Bedrohungsliste.
Wie verändert sich die Angriffsfläche zwischen einem eingezäunten Roboter und einem Cobot?
| Angriffsfläche | Eingezäunter Industrieroboter | Kraftbegrenzter Cobot |
|---|---|---|
| Menschliche Nähe | Durch Zaun, Vorhang oder Verriegelung ausgeschlossen | Dauerhaft; Überwachung von Kraft, Geschwindigkeit oder Trennung ist Teil des Sicherheitsnachweises |
| Zugang zum Handgerät | In der Regel innerhalb der gesperrten Zelle | Geteilter Arbeitsraum, häufig mit aktiver Bedienerrolle |
| Bildverarbeitung als Eingang | Optional und lokal begrenzt | Häufig, teils zentral für Sicherheit und Betrieb |
| Teleoperation | Seltener | Bei einigen Baureihen zunehmend üblich |
| Wahrscheinlichster Akteur | Service, Engineering oder Integrator | Bediener, entfernte Station oder Missbrauch einer geteilten Rolle |
Welche Assets werden geschützt?
| Asset | Warum es zählt | Beispielnachweis |
|---|---|---|
| Bewegungsautorität | Ändert Bahn, Geschwindigkeit oder Modus | Rollenmatrix, Sitzungsnachweis, Modussperre |
| Sicherheits-Firmware | Beeinflusst Stopp, Geschwindigkeit, Trennung und Verriegelungen | Signatur, gemeinsame Prüfung funktionale Sicherheit/Cyber |
| Roboterprogramme | Können unsichere Bewegungen oder Unterbrechungen einführen | Parser-Validierung, Herkunftskontrolle, Ladeprotokoll |
| Zugangsdaten des Handgeräts | Erlauben lokale Änderungen im Produktionsbetrieb | Erstrotation, Ablauf, Bediener-Audit |
| Cloud-Konnektor | Kann Hinweise, Aktualisierungen oder Tunnel verteilen | Zertifikate, Endpunktliste, Rollback-Nachweis |
| Softwarekomponenten | RT OS, Bildverarbeitung, Feldbus und Bibliotheken haben Schwachstellen | SBOM, Verfolgung von Hinweisen, Patch-Entscheidung |
Wo liegen die wichtigsten Vertrauensgrenzen?
| Grenze | Übergang | Risikofrage |
|---|---|---|
| Hersteller an Integrator | Handbuch, Importeurpaket, Sicherheitskonfiguration und Hinweise | Was wird geliefert, was bleibt außen vor? |
| Integrator an Betreiber | Installierte Zelle, Rollen, Wartungsfenster | Wer darf die Bewegung nach der Übergabe ändern? |
| Engineering-Station an Steuerung | Projekt, Programm, Firmware, Parameter | Welcher Test verhindert eine Schreibaktion außerhalb einer Sitzung? |
| Cloud an Flotte | Hinweise, Aktualisierungen, Zertifikate, Tunnel | Welche entfernten Befugnisse bestehen und wie werden sie widerrufen? |
| Lieferant an Hersteller | Komponenten, Bibliotheken, Drittanbieter-Firmware | Wie wird ein Hinweis erkannt, der den Roboter betrifft? |
Welche Bedrohungen werden zuerst bewertet?
| ID | Bedrohung | Betroffenes Asset | Grenze |
|---|---|---|---|
| R1 | Ein Werks- oder Integratorkonto bleibt nach der Übergabe aktiv | Bewegungsautorität | Integrator an Betreiber |
| R2 | Ein altes Firmware-Paket wird während der Wiederherstellung akzeptiert | Firmware-Integrität | Lokaler Service |
| R3 | Die Flottencloud startet einen Tunnel außerhalb des Wartungsfensters | Entfernte Autorität | Cloud an Flotte |
| R4 | Ein manipuliertes Projekt ändert die Logik für Geschwindigkeit oder Trennung | Kollaborative Sicherheit | Engineering-Station |
| R5 | Ein abgelaufenes Zertifikat blockiert Hinweise oder Aktualisierungen | Verfügbarkeit | Cloud |
| R6 | Der Betreiber erhält eine Schwachstellenwarnung nicht rechtzeitig | Verwaltung von Schwachstellen | Hersteller an Betreiber |
| R7 | Ein Lieferant veröffentlicht einen Hinweis zu RT OS oder Bildverarbeitung und er wird nicht erkannt | Komponenten | Lieferant an Hersteller |
| R8 | Ein Feldbus-Frame führt zu einem Ausfall der Bewegungs-CPU oder zur Überlastung des Zyklus | Bewegungsverfügbarkeit | Feldbus |
| R9 | Ein USB-Recovery-Image wird ohne Audit eingespielt | Firmware-Integrität | Servicemedium |
| R10 | Ein Diagnosepaket gibt Programmnamen, Zertifikate oder Netzdaten preis | Servicedaten | Support-Portal |
| R11 | Eine Schwachstelle in RT OS, Feldbus oder Bildverarbeitung wird während des Supports nicht erkannt | Firmware-Komponenten | Lieferantenhinweise |
| R12 | Eine Kundenübertragung lässt die alte Engineering-Station aktiv | Zugangsdaten | Stilllegung |
| R13 | Der Parser der Laufzeitumgebung fällt aus oder führt unsicheren Inhalt aus einem fehlerhaften Projekt aus | Werkzeugintegrität | Projektimport |
| R14 | Der Integrator kombiniert den Arm mit einer Sicherheits-PLC eines Dritten ohne gültige Nachweise | Lieferantenkonformität | Zellenübergabe |
Wie werden die initialen Risiken priorisiert?
Verwenden Sie eine Entscheidungsleiter. Nicht jedes Risiko benötigt dieselbe Antwort.
| Restergebnis | Warum es bleibt | Operativer Nachweis |
|---|---|---|
| Langlaufender Patch | Eine Lieferantenkomponente hat noch keine Korrektur | Komponentenhinweis, temporäre Minderung, Überprüfungsdatum |
| Kundenseitige Änderung | Der Betreiber möchte eine eigene Station integrieren | Abgrenzungsmemo, Umfangsnotiz, Supportanweisung |
| Zeitpunkt des Patches | Die Halle benötigt Fenster und Validierung | Hinweis mit Maschinenauswirkung, Minderung, Rollback |
| Physischer Servicezugang | Schränke, Handgeräte und Stationen sind bei Wartung zugänglich | Einschränkungen im Servicemodus, Audit-Stichprobe, Debug-Sperre |
Welche Designkontrollen verändern das Risiko?
| Kontrolle | Was sie reduziert | Nachweis |
|---|---|---|
| Signierte Firmware mit Ablehnung älterer Versionen | Alte oder manipulierte Pakete | Update-Testprotokoll, Hash, Ablehnungsergebnis |
| Geräteindividuelle Zugangsdaten und Erstrotation | Geteilte Werkskonten | Provisionierungsprotokoll, Nachweis des ersten Starts |
| Getrennte Rollen für Bediener, Wartung und Engineering | Bewegungsänderungen außerhalb der Rolle | Berechtigungsmatrix und Audit |
| Wartungsfenster für Cloud und Tunnel | Dauerhaft offene entfernte Autorität | Fensterprotokoll, automatische Schließung, Rollback |
| SBOM und Lieferantenverfolgung | Hinweise, die das Team nicht erreichen | SBOM, Hinweisquellen, Klassifizierungsentscheidung |
Welches Restrisiko bleibt nach den Kontrollen?
Nach Anwendung der Kontrollen muss der Hersteller benennen, was verbleibt und warum. In diesem Beispiel bleibt das Risiko von Lieferantenschwachstellen bestehen, weil der Roboter von RT OS, Bildverarbeitung und Feldbus Dritter abhängt. Das Risiko wird nicht abstrakt akzeptiert: Es ist mit der Verfolgung von Hinweisen, der Paketsignatur, Wartungsfenstern, der Kommunikation mit Integratoren und Korrekturtests verknüpft. Die dokumentierte Minderung muss zeigen, dass der Prozess vor Beginn der Produktion existiert.
Wie sollen Hinweise der Flottencloud zirkulieren?
Die vorherige Bewertung lebt in einem Roboterschrank. Die Weiterleitung von Hinweisen lebt in Hunderten von Robotern. Wenn die Flottencloud des Herstellers mehrere Integratoren und Standorte bedient, ist die Frage nicht nur, ob die Cloud sicher ist. Die Frage ist, wer eine Schwachstellenwarnung in 24 Stunden erhält und wer das Aktualisierungsfenster jedes Standorts freigibt.
| Flottentopologie | Wer zwischen Hersteller und Endnutzer steht | Was sich im Dossier ändert |
|---|---|---|
| Einzelstandort-Betreiber, direkt vom Hersteller | Hersteller → Betreiber | Der Hinweis erreicht das Wartungsteam des Betreibers; ein Kanal kann ausreichen |
| Multi-Standort-Betreiber mit zentralem Engineering | Hersteller → Zentrales Engineering → Standorte | Das Dossier muss den zentralen Kontakt erfassen, damit der Hinweis nicht in einem lokalen Postfach verloren geht |
| Vom OEM verwaltete Flotte | Hersteller → OEM-Betrieb → Endbetreiber | Der OEM leitet Hinweise mit Maschinenauswirkung weiter, der Hersteller benötigt jedoch einen Weg zu betroffenen Nutzern |
| Vom Integrator verwaltete Flotte | Hersteller → Integrator → KMU-Nutzer | Der Hinweis des Herstellers speist den eigenen Prozess des Integrators, wenn dieser unter eigener Marke verkauft |
| Flotte von Flotten | Cloud des Herstellers ↔ OEM-Cloud ↔ Integrator-Cloud ↔ Betreiber | Dokumentieren Sie, welche Kette vertraglich ist und welche die regulatorische Meldung und Nutzer abdeckt |
Versionseintrag. Eine Karte der Flottencloud-Weiterleitung muss für jeden Integrator und Betreiber der Liste den 24-Stunden-Alarmkontakt, den Verantwortlichen für das Wartungsfenster, die Rollback-Autorität und die offenen verbleibenden Hinweise benennen.
Welche Validierungs-Gates schließen vor der Freigabe?
Vermeiden Sie ein generisches „Sicherheit geprüft”-Gate. Verwenden Sie ein Gate-Inventar mit Fehlermodus, Kontrolle und Nachweis für jede Entscheidung, die den Versand blockieren kann.
| Gate | Blockierender Fehler | Nachweis |
|---|---|---|
| Variantenschluss | Es ist unklar, was verkauft wird | Abgrenzungsmemo und Weg |
| Bewegungsautorität | Eine falsche Rolle kann Bahn oder Modus ändern | Negativtest und Audit |
| Sicherheits-Firmware | Ein Update verändert die Sicherheitslogik ohne Prüfung | Gemeinsame Prüfung und signierter Test |
| Feldbus | Anomale Frames beeinflussen Zyklus oder Verfügbarkeit | Bustest und Segmentierung |
| Cloud und OTA | Die Cloud behält unbegrenzte Autorität | Fenster, Zertifikate, Rollback |
| Dokumentation | Kontakt, Support oder Anweisungen fehlen | Dossierindex und Importeurpaket |
Wer trägt die Verantwortung für die Roboterentwicklung vom Konzept bis zum Support?
Verwenden Sie eine Verantwortungsspur. Jede Phase hat einen Hauptverantwortlichen, einen geführten Eintrag und ein Prüfgate. Die Version wird erst geschlossen, wenn jede Phase eine Spur hinterlässt.
Welche Nachweiseinträge gehören in das Dossier?
Die folgende Liste ist eine prüffähige Übersicht. Sie friert Produktidentität, Sicherheitskontrollen und Pflichten nach dem Verkauf ein. Jede Zeile muss auf einen geführten Eintrag verweisen, nicht auf einen Ordner mit losen Screenshots.
| Nachweiseintrag | Was er für einen Industrieroboter oder Cobot erfasst |
|---|---|
| Produktidentität | Armmodell, Traglast, Reichweite, Steuerschrank, Programmierhandgerät, Firmware-Zweig, Laufzeitumgebung, Bildsensor, Busoptionen, Hardware-Service |
| Verwendungszweck | Kollaborativer oder eingezäunter Betrieb, Traglast, Anwendung, Bedienermodus, Nutzungsmuster und Variante |
| Cyber-Resilienz-Dossier | Klassifizierungsweg, Grenzen, Bedrohungsliste, Vertrauenskontrollen und Restentscheidungen |
| Komponenteninventar | Bewegungs-CPU, Echtzeit-OS, Feldbus-Stack, EtherCAT-Slave-Stack, Sicherheits-Firmware, Laufzeitumgebung, Bibliotheken, Bildverarbeitungsmodul |
| Sichere Standardkonfiguration | Kein geteiltes Geheimnis, eindeutige Konten, Sperre älterer Versionen, OPC UA standardmäßig sicher, Service nach Inbetriebnahme |
| Aktualisierungsmechanismus | Signierte Firmware, Rollback, Karte der Maschinenauswirkungen, Kundenkontakt und Cloud-Nachweis |
| Verwaltung von Schwachstellen | Offenlegungsrichtlinie, einzelner Kontakt, Klassifizierungsablauf, Verfolgung von Komponenten- und Integratorhinweisen |
| Benutzeranweisungen | Sichere Inbetriebnahme, Rollenverwaltung, Stilllegung, Aktualisierungsfenster, Servicegrenzen |
| Rückverfolgbarkeit und Kontakt | Typ, Charge oder Seriennummer, Herstellerdaten, Datum des Supportendes und Schwachstellenkontakt |
Was gehört in eine SBOM eines Roboters?
Der CRA verlangt eine maschinenlesbare SBOM, die Komponenten identifiziert und mindestens Abhängigkeiten erster Ebene abdeckt, legt jedoch noch kein einheitliches Format fest. Bis die Kommission weitere Details konkretisiert, wählen Hersteller meist CycloneDX oder SPDX. Den übergreifenden Leitfaden finden Sie im SBOM-Leitfaden; dieser Abschnitt behandelt den eigenen Baum des Roboters.
Eine Roboterversion liefert meist mehrere digitale Elemente mit getrennten Aktualisierungszyklen, nicht ein einzelnes Binärpaket. Zwei Muster erfüllen das Minimum: eine Produkt-SBOM mit Abschnitten je Element oder eine SBOM je geliefertem digitalem Element, die mit jeder Version aktualisiert wird. Beide eignen sich, sofern die SBOM maschinenlesbar ist und Abhängigkeiten erster Ebene abdeckt.
SBOM-Eintrag: eine maschinenlesbare SBOM in CycloneDX oder SPDX, die mindestens Abhängigkeiten erster Ebene abdeckt. Bei Robotern ist dies meist eine Produkt-SBOM mit Abschnitten je Element oder eine SBOM je geliefertem digitalem Element. Tiefere transitive Abhängigkeiten sind empfehlenswert, wenn das Build-System sie liefern kann.
Was prüft die Versionssignatur?
Bevor der Roboter auf den EU-Markt gelangt, muss die Signatur dieselben vier Einträge der Fragen Q1 bis Q4 abschließen. Das Inventar liegt nicht im abstrakten Nachweis weiter oben. Diese Tabelle gilt nur für die vier Entscheidungen, die die Version blockieren.
Versionsfreigabe: vier Einträge, die die Auslieferung blockieren
- Q1 Klassifizierungsmemo. Warum das Produkt so klassifiziert ist: Verwendungszweck, Verkaufskontext, gelieferte digitale Elemente und gewählter Standardweg.
- Q2 Inventar der gelieferten Elemente. Was genau ausgeliefert wird: Arm, Steuerung, Programmierhandgerät, Bildverarbeitung, Firmware, Cloud, Bibliotheken, Handbücher und Varianten.
- Q3 Testpaket „sicher standardmäßig”. Geräteindividuelle Zugangsdaten, OPC UA-Profil, Ablehnung älterer Versionen, Debug-Sperre und Servicemodus.
- Q4 Prozess zur Verwaltung von Schwachstellen. Öffentlicher Kontakt, Offenlegungsrichtlinie, Klassifizierung, Verfolgung von Komponenten, Integratoren und Vorbereitung auf Meldungen.
Vorabprüfungen: Die vier Einträge müssen in weniger als einer Minute auffindbar sein; die Mappen müssen am Firmware-Zweig und an der Lieferanten-Baseline fixiert sein; es muss eine benannte verantwortliche Person für Meldungen innerhalb von 24 Stunden und 72 Stunden existieren.
Freigabe-Gate: Fehlt ein Eintrag, wird die Version nicht freigegeben.
Erklärungseintrag: Verwenden Sie den Hauptleitfaden zur EU-Konformitätserklärung für die Vorlage und die geforderten Felder. In einer Roboterversion muss die Produktidentität Arm, Steuerschrank, Programmierhandgerät, Firmware-Zweig, gelieferte Optionen und Verweis auf den Supportzeitraum festlegen. Deckt dieselbe Erklärung auch die Maschinenrechtsvorschriften ab, benennen Sie diesen Weg und halten Sie die technische Dokumentation des Roboters und das Maschinensicherheitsdossier abgestimmt.
Wie wird der Roboter an Importeur, Händler, Integrator und Betreiber übergeben?
Das Dossier muss die Übergabe vom Hersteller an Importeur, Händler, Integrator als Maschinenhersteller und Endnutzer überprüfbar machen. Bei Robotern und Cobots ist der Schwachpunkt meist nicht nur die CE-Kennzeichnung. Meist ist es die Frage, ob Versand, Handbuch, Flottencloud, OTA-Dienst und Übergabe an den Integrator weiterhin der bewerteten Version entsprechen.
Übergabe der Wirtschaftsakteure: Rollen, Prüfungen und benachbarte Regelwerke
- 01 Hersteller. Führt das Versionspaket: Erklärung, CE-Kennzeichnung, Dossierindex, Supportfenster und Schwachstellenkontakt.
- 02 Importeur. Prüft Paket, CE-Kennzeichnung, Index, Supportdatum und Kontakt. Pausiert den Versand bei Zweifeln an Rückverfolgbarkeit, Zugangsdaten, Cloud-Konto oder Aktualisierungskanal.
- 03 Händler. Prüft sichtbare CE-Kennzeichnung, gelieferte Unterlagen, Rückverfolgbarkeit des Betreibers, Support und Aktualisierungszusagen. Pausiert den Verkauf, wenn die Anzeige Akteure verbirgt, den Support übertreibt oder der Erklärung widerspricht.
- 04 Integrator. Kombiniert den Arm mit Sicherheit, Bildverarbeitung und Zelllogik. Liefert die Zelle unter seinem Namen, wird der Integrator zum Hersteller der Zelle.
- 05 Betreiber. Empfängt Hinweise, wendet Aktualisierungen in Wartungsfenstern an und meldet Probleme. Er ist kein Hersteller.
Prüfung A: Bevollmächtigter und Meldepflicht für Nicht-EU-Hersteller. Das Mandat eines Bevollmächtigten ist optional. Hersteller ohne Hauptniederlassung in der Union nutzen die Kaskade des Meldepunkts, um das koordinierende CSIRT zu wählen.
Prüfung B: neue Hersteller. Ein Importeur oder Händler, der unter eigenem Namen verkauft oder den Roboter wesentlich verändert, wird zum Hersteller dieses Angebots. Andere Dritte überschreiten diese Linie nur, wenn ihre Änderung wesentlich ist.
Benachbarte Regelwerke: Maschinenverordnung ab dem 20. Januar 2027, ISO 10218-1:2025, NIS2 für Betreiber kritischer Infrastrukturen und KI-Verordnung für KI-Anwendungen.
Die folgenden Zeilen sind die Kurzfassung: Was zu prüfen ist, wann zu pausieren ist und wann der Roboter eine neue Rollenanalyse benötigt. Die übergreifenden Details zu Rollen finden Sie unter Wer den CRA einhalten muss.
Annahme durch den Importeur
Prüfen Sie Erklärung, CE-Kontrolle, Dossierindex, Supportzeitraum, Schwachstellenkontakt, Identität des Importeurs und Handbuch in der Zielsprache. Pausieren Sie, wenn Paket, Rückverfolgbarkeit, Modell der Handgeräte-Zugangsdaten, Cloud-Konto oder Aktualisierungskanal Zweifel aufwerfen.
Sorgfaltspflicht des Händlers
Prüfen Sie sichtbare CE-Kennzeichnung, gelieferte Unterlagen, Rückverfolgbarkeit des Betreibers, Support und Aktualisierungszusagen. Pausieren Sie, wenn das Angebot Akteure verbirgt, den Support übertreibt, der Erklärung widerspricht oder nach einer bekannten Schwachstelle weiter verkauft wird.
Integrator als Maschinenhersteller
Ein Integrator, der den Arm mit Sicherheit, Bildverarbeitung und Zelllogik kombiniert, wird zum Hersteller der Maschine, sobald die Zelle unter seinem Namen ausgeliefert wird. Der Roboterhersteller bleibt Hersteller der Komponente für Arm, Steuerung und gelieferte Software.
Importeur oder Händler unter eigener Marke
Ein Importeur oder Händler, der den Roboter unter eigenem Namen oder eigener Marke auf dem Unionsmarkt bereitstellt, wird zum Hersteller dieses Angebots. Dasselbe gilt, wenn er einen bereits in Verkehr gebrachten Roboter wesentlich verändert: Firmware unter eigener Marke, neue Handgeräteidentität, neue Flottencloud, neuer Aktualisierungskanal, neue Sicherheitskonfiguration oder neuer Verwendungszweck.
Sonstiger Wiederverkäufer nach wesentlicher Änderung
Ein Dritter, der weder Hersteller, Importeur noch Händler ist, wird nur dann zum Hersteller, wenn er den Roboter vor der Bereitstellung wesentlich ändert. Die Rolle gilt für den betroffenen Teil oder für das gesamte Produkt, falls die Änderung die Gesamtcybersicherheit betrifft.
Bevollmächtigter und Meldepflicht für Nicht-EU-Hersteller
Der Hersteller kann durch schriftliches Mandat einen Bevollmächtigten benennen; das ist eine Option und keine Pflicht aufgrund des Sitzes außerhalb der EU. Die Auswahl des Meldepunkts wird durch einen anderen Umstand ausgelöst: das Fehlen einer Hauptniederlassung in der Union. Die CRA-Kaskade beginnt beim Bevollmächtigten, folgt mit dem Importeur, dann dem Händler und schließlich der größten Nutzerbasis.
Verwandte Regelwerke
Führen Sie getrennte Bewertungen für Maschinenverordnung, ISO 10218-1:2025, NIS2 und KI-Verordnung. Sie können Nachweise teilen, ersetzen das CRA-Dossier aber nicht.
Häufig gestellte Fragen
Sind Industrieroboter und Cobots wichtige oder kritische Produkte unter dem CRA?
Nicht aufgrund der Kategorie Roboter. Industrieroboter und Cobots stehen heute nicht auf den CRA-Listen wichtiger oder kritischer Produkte. Die Arbeitsannahme ist der Standardweg. Der Weg ändert sich nur, wenn eine gelistete Funktion dominiert, etwa ein Roboter, der hauptsächlich als Firewall, Netzwerkmanagementsystem oder manipulationssicherer Controller verkauft wird. Es gibt keine Kategorie „Roboter”, die automatisch zum kritischen Weg führt.
Benötigt ein 6-achsiger Roboterarm eine notifizierte Stelle?
Nicht weil es ein Roboterarm ist. Auf dem Standardweg kann der Hersteller interne Kontrolle, EU-Baumusterprüfung mit Konformität zum Baumuster, umfassende Qualitätssicherung oder ein anwendbares europäisches Zertifizierungsschema verwenden. Die notifizierte Stelle wird nur dort tätig, wo der Weg dies erfordert. Die Bedingung „Normen vollständig angewendet” gehört zum Rückfallweg für wichtige Produkte der Klasse I, nicht zum Standardweg.
Deckt die Maschinenverordnung den Cyberteil bereits ab?
Sie deckt einen Teil ab, aber nicht alles. Die Maschinenverordnung enthält Sicherheitsanforderungen zur Korruption von Steuerungssystemen und zur Zuverlässigkeit der Steuerung. Der CRA ergänzt die Cyber-Resilienz-Ebene: Sicherheitsstellung, Schwachstellenprozess, Support, SBOM und technische Dokumentation. Behandeln Sie sie als zwei verbundene Dossiers.
Wer ist Hersteller, wenn ein Integrator die Zelle aufbaut?
Verkauft der Integrator die fertige Zelle unter seinem Namen, ist der Integrator Hersteller dieser Zelle. Der Roboterhersteller führt sein Dossier weiter für Arm, Steuerung und gelieferte Software. Installiert der Integrator nur eine Zelle unter der Marke des Herstellers, dokumentieren Sie die Übergabe und die Grenzen, erfinden Sie aber keinen Rollenwechsel, den es nicht gibt.
Fällt ein Cobot für KMU-Werkstätten in dieselbe Kategorie wie ein eingezäunter Roboter?
Ja, sofern keine gelistete Funktion das Angebot dominiert. Der Unterschied liegt in der Risikobewertung, nicht in der initialen CRA-Kategorie. Der Cobot weist meist mehr menschliche Exposition, mehr geteilte Rollen und mehr Abhängigkeit vom Hersteller bei Hinweisen, Support und Aktualisierungen auf.
Was passiert, wenn der Roboter Bildverarbeitung, KI oder Teleoperation enthält?
Das ändert die CRA-Kategorie nicht automatisch. Es ändert jedoch die Grenze und die Bedrohungsliste. Bildverarbeitung fügt Kameras, SDK und Modelle hinzu; Teleoperation fügt entfernte Autorität hinzu; KI kann eine Analyse nach der KI-Verordnung auslösen, sofern deren Schwellen erreicht werden. Jedes Element muss im Abgrenzungsmemo und in der SBOM erscheinen.
Verändert die Flottencloud die Produktgrenze?
Ja, wenn die Cloud vom Hersteller bereitgestellt wird und für Hinweise, Aktualisierungen, Zertifikate, Telemetrie oder Tunnel erforderlich ist. In diesem Fall sind der Cloud-Konnektor und seine Autorität Teil des Herstellerdossiers. Gehört die Cloud dem Kunden oder dem Integrator, dokumentieren Sie die Übergabe und die Grenzen.
Was muss eine CRA-Risikobewertung eines Roboters enthalten?
Sie muss Bewegung, Sicherheits-Firmware, Programmierhandgerät, Engineering-Station, Feldbus, Cloud, lokalen Service, Lieferantenkomponenten, Stilllegung und Kommunikation zu Schwachstellen abdecken. Die Frage ist nicht nur, ob Verschlüsselung vorhanden ist. Die Frage ist, wer Bewegung, Sicherheitskonfiguration oder Verfügbarkeit ändern darf.
Wie viel Detail benötigt das Bedrohungsmodell?
So viel, dass Versionsentscheidungen begründet werden können. Ein generischer Satz zu „unbefugtem Zugriff” reicht nicht. Ein nützlicher Eintrag nennt Asset, Grenze, Fehlermodus, Kontrolle, Test und Restentscheidung: zum Beispiel „Ein altes Firmware-Paket wird während der Wiederherstellung akzeptiert; gemindert durch Signatur und Ablehnung älterer Versionen; getestet im Recovery-Modus”.
Welche Risiken werden zuerst bewertet?
Beginnen Sie mit den Risiken, die Bewegung oder Sicherheit verändern: Werks-Zugangsdaten, Firmware-Aktualisierungen, Cloud-Autorität, Programmladevorgänge, Rollen am Handgerät und Feldbus. Decken Sie anschließend Verfügbarkeit, Servicedaten, Lieferantenhinweise und Stilllegung ab.
Wie sieht ein guter Beispieleintrag für ein Risiko aus?
„Ein fehlerhaftes Roboterprojekt führt zu einem Parser-Fehler oder lädt eine nicht validierte Bahn von der Engineering-Station. Asset: Bewegungsautorität. Grenze: Engineering-Station an Steuerung. Kontrolle: Formatvalidierung, Projektsignatur, Engineering-Rolle und Negativtest. Nachweis: Parser-Bericht, Ablehnungsprotokoll und Sitzungsaudit.”
Wann ist die Risikobewertung zu aktualisieren?
Aktualisieren Sie sie, wenn sich der freigegebene Zustand ändert: neues Kontomodell am Handgerät, neuer Feldbus, Cloud-Wechsel, Sicherheits-Firmware, Laufzeitumgebung, Bildverarbeitungsmodul, Debugging oder Stilllegung. Das frühe Datum ist entscheidend: Die Meldepflichten beginnen am 11. September 2026, vor der vollständigen Anwendung des CRA am 11. Dezember 2027. Die Bewertung, die Offenlegungsrichtlinie und der einzelne Kontakt müssen vor diesem Datum funktionieren.
Welcher Nachweis ist der erste, den ein Roboterhersteller erstellen sollte?
Das Abgrenzungsmemo. Benennen Sie das genaue Produkt, was geliefert wird, was außen vor bleibt, was der Kunde integriert, was der Hersteller pflegt und welcher Konformitätsweg verwendet wird. Ohne diesen Eintrag schweben SBOM, Risikobewertung und Übergabe an den Integrator im Leeren.
Was passiert, wenn nach der Auslieferung eine Schwachstelle entdeckt wird?
Der Hersteller muss unverzüglich handeln, wenn Produkt oder Prozesse nicht entsprechen: Korrektur, Rücknahme oder Rückruf des Produkts, soweit angemessen. In der Praxis muss das Dossier auf die Meldesequenz vorbereitet sein: Frühwarnung innerhalb von 24 Stunden bei aktiv ausgenutzter Schwachstelle, Meldung innerhalb von 72 Stunden, Abschlussbericht, sobald die Korrektur- oder Minderungsmaßnahme verfügbar ist, sowie Benutzerhinweis. Bei Robotern ist die Korrektur meist eine signierte Aktualisierung mit Hinweis auf die Maschinenauswirkung und Vorschlag eines Wartungsfensters; der Rückruf bleibt Fällen vorbehalten, die nicht sicher im Feld aktualisiert werden können.