CRA für Maschinenbauer: Wer haftet, wer prüft?

Warum Maschinenbau besonders betroffen ist

In der Öffentlichkeit gilt der Cyber Resilience Act als “IoT-Gesetz” oder “Software-Gesetz”. Das greift zu kurz. Der CRA (EU-Verordnung 2024/2847) erfasst alle Produkte mit digitalen Elementen, die direkt oder indirekt an ein Netz angebunden sind — und moderne Maschinen erfüllen dieses Kriterium fast ausnahmslos.

CNC-Fräsmaschinen mit Ferndiagnose, Schweißanlagen mit Cloud-Anbindung für Prozessdatenlogging, Fördersysteme mit OPC-UA-Schnittstelle, Prüfmaschinen die Messdaten per API exportieren: Das sind keine Ausnahmen im deutschen Maschinenbau — das ist die Regel. Wer heute als Maschinenbauer SCADA-Software von US-Anbietern integriert und die Gesamtanlage unter eigenem Namen in der EU verkauft, haftet morgen als Hersteller nach CRA. Keine Ausnahme, keine Grauzone.

Abgrenzung: CRA und Maschinenverordnung (EU 2023/1230)

“Wir sind schon nach Maschinenverordnung konform — gilt der CRA dann auch noch?” Das ist die häufigste Frage, die Maschinenbauer stellen. Und die Antwort ist eindeutig: Ja. Beide Verordnungen können gleichzeitig gelten, und sie schließen sich nicht aus. Die EU-Maschinenverordnung 2023/1230 regelt die funktionale Sicherheit von Maschinen (Schutz vor mechanischen Gefährdungen, Steuerungssicherheit nach Kategorie/PLr). Der CRA regelt die Cybersicherheit — also den Schutz vor Angriffen über digitale Schnittstellen.²

Überschneidung in der Praxis: Anhang I der Maschinenverordnung enthält in Nummer 1.2 Anforderungen an sicherheitsbezogene Steuerungssysteme. Sobald dieselbe SPS sowohl Sicherheitsfunktionen (z. B. Not-Aus-Logik) als auch eine Netzwerkschnittstelle hat, fällt sie unter beide Verordnungen gleichzeitig.

Was die Maschinenverordnung nicht abdeckt: CVE-Management, Software-Zulieferkette, SBOM, OTA-Updates, Schwachstellen-Meldepflicht. Das sind genuine CRA-Pflichten — dafür hat die Maschinenverordnung keine Entsprechung. Kein Overlap, keine Vereinfachung.

Welche Maschinentypen unter den CRA fallen

Nahezu alle modernen Maschinen mit netzwerkfähigen Steuerungskomponenten sind CRA-relevant. Das betrifft insbesondere:

CNC-Steuerungen (Siemens SINUMERIK, Fanuc, Heidenhain und ähnliche): Sobald die Steuerung über eine Ethernet-Schnittstelle für Ferndiagnose, Programm-Upload oder Datensynchronisation verfügt, ist sie CRA-relevant. Der Maschinenhersteller, der diese Steuerung verbaut und die Maschine unter eigenem Namen in Verkehr bringt, gilt als Hersteller nach CRA.

SPS mit Netzwerkfunktion (Siemens S7, Beckhoff TwinCAT, Allen Bradley und ähnliche): Kommuniziert eine SPS über OPC-UA, Profinet oder EtherNet/IP, ist sie ein vernetztes Produkt mit digitalen Elementen. In der Praxis sind das heute die allermeisten industriellen SPS.

Roboterzellen mit Remote-Access: Roboter-Controller, die Remote-Monitoring, vorausschauende Wartung oder Remote-Programmierung ermöglichen, sind besonders klar CRA-relevant.

Prüfmaschinen mit Cloud-Anbindung: Eine Koordinatenmessmaschine, die Messprotokolle per API in ein MES-System überträgt, enthält eine Netzwerkschnittstelle und fällt unter den CRA.

Transportanlagen und Fördersysteme: Lagerverwaltung mit WLAN-basierten Staplern, Förderbänder mit zentraler SPS-Steuerung — sofern netzwerkfähig, CRA-relevant.

Die Importeur-Falle im Maschinenbau

Was viele Maschinenbauer unterschätzen: die Rolle des Systemintegrators als Hersteller.

Wer eine US-amerikanische SCADA-Software — z. B. Ignition von Inductive Automation, Rockwell FactoryTalk oder Wonderware — in eine Anlage integriert und das Gesamtsystem unter eigenem Namen in der EU verkauft, gilt nach CRA als Hersteller der Gesamtanlage — nicht als Händler oder Importeur der SCADA-Software.¹ Das ist der Punkt, den Integratoren regelmäßig falsch einschätzen.

Selbst wenn der US-Hersteller der SCADA-Software keine eigene CRA-Konformitätsdokumentation vorweisen kann: Der deutsche Maschinenbauer muss sicherstellen, dass das Gesamtprodukt die Anforderungen des Anhang I erfüllt. Die Verantwortung ist nicht delegierbar.

Praktische Konsequenz: Jeder Maschinenbauer, der Drittkomponenten mit Netzwerkfunktion verbaut, muss:

Vertraglich sicherstellen, dass der Zulieferer CRA-konforme Komponenten liefert
Im Zweifel die CRA-Analyse für das Gesamtsystem selbst durchführen
Die SBOM alle eingebetteten Softwarekomponenten erfassen — einschließlich zugekaufter SCADA-Software

IEC 62443: Was hilft das für den CRA?

Viele Maschinenbauer und ihre Kunden kennen bereits die IEC 62443-Normenreihe für industrielle Cybersicherheit. Relevant für Produkthersteller sind IEC 62443-4-1 (Entwicklungsprozess) und IEC 62443-4-2 (technische Anforderungen an Komponenten).³

Was IEC 62443 für den CRA leistet: Konzeptionell sind viele CRA-Anforderungen mit der Normenreihe kompatibel. Wer IEC 62443-4-1 bereits anwendet, hat:

Einen strukturierten Secure Development Lifecycle (SDL) — deckt Teile von Anhang I Teil II ab
Risikoanalysen nach TARA — deckt Risikoanalyse-Anforderungen des CRA ab
Security-Requirements-Management — hilfreich für die technische Dokumentation

Was IEC 62443 nicht abdeckt: Die Normen entstanden vor dem CRA. Nicht erfasst sind insbesondere die 24-Stunden-Meldepflicht bei aktiv ausgenutzten Schwachstellen (Artikel 14 CRA¹), die SBOM-Pflicht im CycloneDX/SPDX-Format und die CE-Kennzeichnungspflicht. Das sind Lücken, die eine reine IEC-62443-Konformität nicht schließt.

Wer bereits nach IEC 62443 arbeitet, kommt mit einer Gap-Analyse zum CRA deutlich schneller ans Ziel — die vorhandene Basis ist wertvoll, aber nicht ausreichend. Wer noch gar nicht nach IEC 62443 arbeitet, kann CRA-Compliance und IEC-Konformität gemeinsam angehen, da sich der Aufwand überlappt.

Lieferketten-Realität: Wer haftet bei Steuerungskomponenten?

Im deutschen Maschinenbau kaufen OEMs regelmäßig fertige Steuerungsmodule, Antriebssysteme und Kommunikationskomponenten von Zulieferern. Die CRA-Frage lautet dann: Wer trägt die Verantwortung für die Cybersicherheit dieser Komponenten?

Die rechtliche Antwort: Der Maschinenhersteller, der das Gesamtprodukt in Verkehr bringt, trägt die Primärverantwortung. Verbaut er eine fertige SPS eines deutschen Herstellers, die ihrerseits CRA-konform ist und als eigenständiges Produkt mit eigener CE-Kennzeichnung geliefert wird, kann er sich auf die Konformität dieser Komponente verlassen — muss das aber dokumentieren.

Wenn der Komponentenhersteller nicht liefern kann: Ein Maschinenkomponenten-Hersteller aus Fernost, der keine SBOM, keine Risikoanalyse und keine CVE-Meldeprozesse vorweisen kann, liefert keine CRA-konforme Komponente. Der Maschinenbauer, der diese Komponente verbaut, kann die Pflichten nicht einfach auf den Zulieferer abwälzen. Punkt.

Was viele hier übersehen: Lieferantenaudits für CRA-Compliance werden bereits 2026 als Standardanforderung in Lieferantenverträge geschrieben — im deutschen Maschinenbau ist das keine Prognose mehr, das ist heute schon Realität. Wer als Komponentenzulieferer keine CRA-Dokumentation vorweisen kann, verliert Aufträge.

Konkrete Szenarien und ihre Klassifizierung

Szenario 1: SPS mit OPC-UA-Schnittstelle

Eine Siemens S7-1500 mit aktivierter OPC-UA-Schnittstelle, die in eine Verpackungsmaschine integriert wird. Der Maschinenhersteller bringt die Gesamtmaschine unter eigenem Namen in Verkehr.

Einschätzung (nicht rechtsverbindlich): Wahrscheinlich Default-Klasse. Die SPS selbst hat keine Sicherheitsfunktion im CRA-Sinne (also keine Firewall, kein Zugangsmanagement für andere Systeme). Die Pflichten umfassen: Risikoanalyse für die OPC-UA-Schnittstelle, SBOM für die eingebettete Firmware, Schwachstellenmanagement für die Lebensdauer der Maschine.

Szenario 2: Roboterzelle mit Remote-Monitoring und Cloud-Anbindung

Eine Schweißroboteranlage mit eigenem Controller-System, Remote-Monitoring-Zugang für den Hersteller und Cloud-basiertem Prozessdaten-Dashboard.

Einschätzung (nicht rechtsverbindlich): Wahrscheinlich Default-Klasse. Ist die Remote-Access-Komponente eine eigenständige Netzwerkeinheit mit Sicherheitsfunktion (VPN-Gateway, Firewall-Modul), könnte die Anlage in Teilen Important Class I eingestuft werden. Die Gesamtbewertung hängt davon ab, ob sicherheitsrelevante Funktionen netzwerkseitig exponiert sind.

Was Maschinenbauer jetzt tun sollten

1. Produktportfolio auf CRA-Relevanz prüfen Für jede Maschinen-Baureihe: Gibt es Netzwerkschnittstellen? OPC-UA, Profinet, EtherNet/IP, WLAN, Mobilfunk? Wenn ja, ist die Baureihe CRA-relevant. Diese Analyse gehört ins Produktmanagement, nicht in die IT-Abteilung.

2. Rolle als Hersteller klären Wer integrierte Drittsoftware als Teil des Gesamtprodukts verkauft, ist Hersteller — unabhängig davon, ob er die Software selbst entwickelt hat. Diese Rollenklärung hat direkte Konsequenzen für Haftung und Compliance-Aufwand.

3. Lieferantenverträge anpassen Softwarekomponenten- und Steuerungslieferanten müssen vertraglich CRA-Konformität zusichern. Bestehende Rahmenverträge müssen Unternehmen jetzt überprüfen.

4. Gap-Analyse zum CRA (ggf. aufbauend auf IEC 62443) Welche Anforderungen aus Anhang I CRA decken bereits bestehende Prozesse ab — IEC 62443, ISO 27001, internes QM? Was fehlt noch? Diese Gap-Analyse ist der effizienteste Einstiegspunkt.

5. Technische Dokumentation aufbauen Die technische Dokumentation nach CRA Anhang VII umfasst Risikoanalyse, SBOM, Beschreibung des Schwachstellenmanagements und Nachweise zur Umsetzung der Anhang-I-Anforderungen. Hersteller müssen diese Dokumente 10 Jahre aufbewahren und Marktaufsichtsbehörden auf Anforderung vorlegen können.

Weiterführende Themen

Welche Rolle haben Sie als Hersteller, Importeur oder Händler? → CRA: Hersteller, Importeur oder Händler?
Welche Risikoklasse trifft auf Ihre Maschine zu? → CRA Risikoklassen: Default, Important, Critical
Wann muss eine Schwachstelle gemeldet werden? → CRA Schwachstellen-Meldepflicht

Den kostenlosen CRA-Check können Sie für eine erste indikative Einschätzung Ihrer Maschinenkategorien nutzen. Für Maschinenbauer die bereits wissen, dass CRA-Compliance ansteht, bietet das Evidence Pack strukturierte Templates für Risikoanalyse, technische Dokumentation und SBOM nach CRA-Standard.

Quellen

EU-Verordnung 2024/2847 des Europäischen Parlaments und des Rates vom 23. Oktober 2024 (Cyber Resilience Act), Artikel 2, Artikel 3 (Nummer 13–17), Artikel 13–14, Anhang I, Anhang VII: https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=OJ:L_202402847
EU-Verordnung 2023/1230 des Europäischen Parlaments und des Rates vom 14. Juni 2023 über Maschinen (Maschinenverordnung), Anhang I: https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=OJ:L_202301230
IEC 62443-3-2: Security risk assessment for system design; IEC 62443-4-1: Secure product development lifecycle requirements; IEC 62443-4-2: Technical security requirements for IACS components: https://www.iec.ch/dyn/www/f?p=103:23:0::::FSP_ORG_ID:1253
BSI — CRA und IEC 62443 im industriellen Umfeld: https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Cyber_Resilience_Act/
VDMA — Leitfaden Cyber Resilience Act für Maschinenbauer: https://www.vdma.org/

Hinweis: Dieser Artikel dient der allgemeinen Information und stellt keine Rechtsberatung dar. Die Einschätzungen basieren auf dem Stand der EU-Verordnung 2024/2847 und öffentlich verfügbaren Auslegungshilfen. Für eine verbindliche Klassifizierung Ihres Produkts und die Abgrenzung zur Maschinenverordnung empfehlen wir rechtliche und technische Fachberatung.