NIS2 und Robotik: Pflichten für Betreiber vernetzter Roboter

Vernetzte Roboter können Unternehmen unter dem deutschen NIS2-Regime vor neue Anforderungen an IT-Sicherheit, Risikomanagement und Meldeprozesse stellen. Ist ein Unternehmen als besonders wichtige Einrichtung vom BSIG erfasst, müssen auch Robotersysteme, Flottenserver und Fernwartungszugänge in das Cyber-Risikomanagement einbezogen werden. Bei einem erheblichen Sicherheitsvorfall können zudem Meldepflichten greifen – parallel zu den Pflichten des Herstellers nach dem Cyber Resilience Act (CRA). Für Unternehmen kommt es deshalb darauf an, NIS2 und CRA organisatorisch und vertraglich zusammenzudenken und Incident-Response-Prozesse auf beide Meldeketten auszurichten.

Dies ist der zweite Teil zum Thema IT-Sicherheit und Verkörperte KI innerhalb unserer Serie „Robotics und Physical AI“. Während Teil 1 die Herstellerperspektive unter dem Cyber Resilience Act behandelt, stehen nun das NIS2-Regime und die Betreiberperspektive sowie konkrete Handlungsempfehlungen für Hersteller und Betreiber im Mittelpunkt.

Robotik und verkörperte KI

Topic Deutschland

Robotik und verkörperte KI

CRA und NIS2: Ein Cybervorfall, zwei Meldeketten

Im ersten Beitrag zum Thema IT-Sicherheit und Verkörperte KI haben wir die Pflichten des Herstellers nach dem Cyber Resilience Act beleuchtet, die ihn treffen, wenn eine Schwachstelle seines Produkts aktiv ausgenutzt wird. In diesem Beitrag wechseln wir auf die Betreiberseite und betrachten die Pflichten nach dem deutschen NIS2-Regime. Mit „Betreiber“ ist im Folgenden eine nach § 28 BSIG erfasste besonders wichtige Einrichtung gemeint, die die Robotersysteme für ihre Tätigkeit einsetzt. Abschließend leiten wir aus beiden Rechtsregimen konkrete Handlungsempfehlungen für Hersteller und Betreiber ab. 

Zurück zum Freitagabend-Szenario des ersten Beitrags: 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. Damit ist der Vorfall auch ein Fall für die zweite Meldekette: Der Betreiber prüft, ob ein erheblicher Sicherheitsvorfall im Sinne des NIS2-Regimes vorliegt und meldet ihn gegebenenfalls an die gemeinsame Meldestelle von BSI und BBK. Ein Sicherheitsvorfall ist erheblich, wenn er schwerwiegende Betriebsstörungen oder finanzielle Verluste für die Einrichtung verursacht oder verursachen kann oder andere Personen erheblich schädigt (§ 2 Nr. 11 BSIG). Im Beispielsfall ist der Stillstand der gesamten Intralogistik deshalb ein starkes Indiz, aber noch kein Automatismus. Entscheidend sind insbesondere Dauer, Umfang und wirtschaftliche Auswirkungen der Störung. Legt der Ausfall die Produktion wesentlich lahm oder drohen erhebliche Verluste, spricht viel für einen meldepflichtigen, erheblichen Sicherheitsvorfall. 

Liegt ein solcher Vorfall vor, erfolgt eine erste Meldung unverzüglich, spätestens binnen 24 Stunden nach Kenntniserlangung, eine weitere Meldung binnen 72 Stunden und die Abschlussmeldung grundsätzlich binnen eines Monats. Im Szenario greifen damit zwei Regime mit unterschiedlichen Meldepflichtigen und Meldegegenständen: Der Hersteller meldet die aktiv ausgenutzte Schwachstelle seines Produkts nach dem CRA, der Betreiber den erheblichen Sicherheitsvorfall und seine Auswirkungen auf den Betrieb nach dem BSIG. Die Fristen ähneln sich, die Adressaten und Inhalte nicht – wer beide Ketten im selben Incident-Response-Plan abbildet und die gegenseitige Information vertraglich absichert, meldet schneller und widerspruchsfrei. Je nach Sachverhalt können weitere Meldepflichten hinzutreten. Führt der Cybervorfall etwa zu einer Verletzung des Schutzes personenbezogener Daten, ist zusätzlich eine Meldung nach Art. 33 DSGVO zu prüfen.

NIS2: Sicherheit als Organisationspflicht des Betreibers

Die NIS2-Richtlinie ist in Deutschland seit dem 6. Dezember 2025 umgesetzt (BSIG n.F.). Erfasst sind – neben Sektoren wie Energie, Verkehr und Gesundheit – ausdrücklich auch weite Teile des verarbeitenden Gewerbes: Unternehmen etwa aus dem Maschinenbau, der Herstellung elektronischer Erzeugnisse, von Kraftwagen und Kraftwagenteilen sowie von Medizinprodukten sind bei Erreichen der gesetzlichen Schwellenwerte grundsätzlich wichtige Einrichtungen. Das trifft die Robotik doppelt: Der Roboterhersteller kann je nach Tätigkeit selbst als Einrichtung im Sinne des Gesetzes erfasst sein – und sein Kunde, der Automobilzulieferer aus unserem Szenario, ebenfalls. Wer betroffen ist, muss sich registrieren, geeignete, verhältnismäßige und wirksame Risikomanagementmaßnahmen ergreifen, die den Stand der Technik einhalten und Vorfälle melden.

Für den Robotik-Einsatz heißt Risikomanagement vor allem; dass die Flotte in die Risikobetrachtung miteinbezogen werden muss. Roboter, Flottenserver, Ladeinfrastruktur und Fernwartungszugänge sind Betriebstechnik („OT“) und müssen im Risikomanagement berücksichtigt werden, praktisch etwa im Asset-Register, in der Netzsegmentierung, im Berechtigungskonzept und im Incident-Response-Plan. Der Rollout nach dem Motto „die Roboter macht der Hersteller schon sicher“ verfehlt die Rechtslage, denn die NIS2-Pflichten treffen den Betreiber, unabhängig davon, wie gut der Hersteller seine CRA-Hausaufgaben macht. Der Fernwartungszugang aus unserem Szenario ist dabei der Klassiker unter den Einfallsvektoren: Er verlangt ein eigenes Zugriffs- und Protokollierungskonzept, und er ist Lieferkettenthema.

Denn die zweite Stoßrichtung des NIS2-Regimes ist die Lieferkette: Einrichtungen müssen die Sicherheit ihrer Zulieferbeziehungen berücksichtigen. Praktisch übersetzt sich das in Beschaffungsanforderungen an den Roboterlieferanten – CRA-Readiness bzw. -Konformität (soweit bereits anwendbar), Update- und Supportzusagen über die reale Nutzungsdauer, definierte Meldewege binnen Stunden, Zutritts- und Zugriffsregeln für die Fernwartung. Dieselbe Logik, mit der sich der Hersteller nach den Leitlinien vom Cloud-Anbieter NIS2-Nachweise geben lassen soll, setzt sich entlang der Lieferkette fort: Der Betreiber lässt sich vom Hersteller dessen CRA-Compliance-Status und – sobald anwendbar – die CRA-Konformität nachweisen. Sicherheit wird zur Vertragskette.

Schließlich die persönliche Ebene: Die Geschäftsleitung muss die Risikomanagement-Maßnahmen umsetzen, ihre Umsetzung überwachen und sich regelmäßig schulen lassen (§ 38 BSIG n.F.); verletzt sie diese Pflichten schuldhaft, haftet sie ihrer Einrichtung nach den für die jeweilige Rechtsform geltenden gesellschaftsrechtlichen Regeln. Die Leitungs- und Überwachungsverantwortung lässt sich hierbei nicht vollständig delegieren. Flankiert wird das von Bußgeldrahmen bis zu 10 Mio. € für besonders wichtige Einrichtungen und bis zu 7 Mio. € für wichtige Einrichtungen; bei einem weltweiten Gesamtumsatz von mehr als 500 Mio. € können stattdessen bis zu 2 % bzw. 1,4 % des Gesamtumsatzes maßgeblich sein. Wer als Geschäftsführer eines NIS2-erfassten Zulieferers vierzig vernetzte Roboter einsetzen lässt, ohne dass die Flotte im Risikomanagement auftaucht, hat damit ein sehr persönliches Thema.

CRA und NIS2 in der Robotik: Handlungsempfehlungen für Unternehmen

Im Folgenden sollen die für CRA und NIS2 festgestellten Pflichten in konkrete Handlungsempfehlungen übersetzt werden. Dieser Katalog ist exemplarisch zu verstehen, nicht abschließend.

Für Hersteller:

• Meldefähigkeit bis zum 11. September herstellen. Praktisch schon jetzt Aufnahmewege für Schwachstellenhinweise („Coordinated Vulnerability Disclosure“-Policy, Kontaktstelle), Triage mit Erstbewertung binnen Stunden, Zuständigkeiten zwischen Produktsicherheit, IT und Recht klären; Registrierung für die Single Reporting Platform vorbereiten und den internen Meldeprozess anhand der ENISA-Vorgaben testen. Die Pflicht erfasst auch die Bestandsflotte im Feld.
• Das Produkt bis in die Cloud abgrenzen und dokumentieren. Mit dem Drei-Fragen-Test der Leitlinien festhalten, welche Backend-Dienste Fernverarbeitung sind (samt SBOM und Risikobewertung) und welche Drittleistungen als Komponente oder Abhängigkeit laufen – einschließlich der erforderlichen Nachweise für Komponenten und Cloud-Abhängigkeiten.
• Änderungs-Governance aufsetzen. Jedes Update und jedes Modell-Retraining gegen das bewertete Risikoprofil prüfen und die Einstufung dokumentieren; ab 2027 die zweite Prüfung nach der Maschinenverordnung mitdenken und eine gegebenenfalls erforderliche Baumusterprüfung so aufsetzen, dass sich die Cyber-Nachweise für die jeweils abgedeckten Risiken auch unter dem CRA nutzen lassen (Art. 69 Abs. 1 CRA).
• Support-Zeitraum ehrlich kalkulieren. Erwartete Nutzungsdauer statt pauschaler fünf Jahre; Enddatum transparent machen; eine etwaige Lücke zwischen regulatorischem Support-Zeitraum und tatsächlicher Roboterlebensdauer vertraglich regeln.

Für Betreiber:

• Betroffenheit klären und die Flotte in den Geltungsbereich nehmen. NIS2-Scope-Check; Roboter, Flottenserver und Fernwartungszugänge im Risikomanagement berücksichtigen – praktisch etwa im Asset-Register, Netzsegmentierung und Incident-Response; erforderliche Registrierung im BSI-Portal vornehmen bzw. aktuell halten und den Meldeprozess zur gemeinsamen Meldestelle von BSI und BBK technisch und organisatorisch testen.
• Beide Meldeketten in einem Plan abbilden. Wer meldet was an wen und in welcher Frist – und wie erfahren Hersteller und Betreiber voneinander? Informationspflichten in Service- und Wartungsverträge aufnehmen.
• Beschaffung als Sicherheitsinstrument nutzen. CRA-Compliance-Status und (soweit bereits anwendbar) CRA-Konformität, Update-Zusagen über die Nutzungsdauer, Meldefristen und Fernwartungsregeln als Vertragsanforderungen; bei Retrofits vorab prüfen, ob nach CRA oder Maschinenverordnung Herstellerpflichten ausgelöst werden.
• Die Geschäftsleitung einbinden. Umsetzung und Überwachung der Maßnahmen dokumentieren, Schulungen nachweisen – operative Aufgaben können delegiert werden, die Leitungs- und Überwachungsverantwortung bleibt bei der Geschäftsleitung.

Ausblick: Sicherheit wird Lebenszyklus, nicht Feature

Der 11. September 2026 ist erst der Auftakt. Zum 20. Januar 2027 folgt die Maschinenverordnung mit ihren Cyber-Anforderungen an Maschinen, zum 11. Dezember 2027 das volle CRA-Pflichtenprogramm. Für Hochrisiko-KI in Maschinen hat der Digital Omnibus inzwischen einen sektoralen Weg eingeschlagen: Die einschlägigen KI-Anforderungen sollen in die Maschinenverordnung integriert werden; die hierfür vorgesehenen delegierten Rechtsakte sollen ab dem 2. August 2028 gelten. Bis dahin ist der CRA ein zentraler horizontaler Cybersecurity-Sockel des Robotik-Stacks; zum Zusammenspiel von CRA und KI-VO sowie weiteren einschlägigen Produktrechtsakten hat die Kommission weitere Leitlinien angekündigt. Die Richtung ist klar: Sicherheit ist bei verkörperter KI keine Produkteigenschaft, die mit der CE-Kennzeichnung feststeht, sondern ein Lebenszyklus aus Risikobewertung, Updates, Meldungen und Support – beim Hersteller wie beim Betreiber. CMS begleitet Hersteller, Integratoren und Betreiber an genau dieser Naht: von der Produktarchitektur über Beschaffungs- und Serviceverträge bis zum Incident-Response- und Meldeprozess.

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.