CRA für SPS, IPC und Industriesteuerungen

Industriesteuerungen und der CRA: Warum die Klassifizierung komplex ist

Speicherprogrammierbare Steuerungen (SPS), Industrie-PCs (IPC) und CNC-Steuerungen stehen im Mittelpunkt einer der komplexesten Klassifizierungsfragen des EU Cyber Resilience Act. Der Grund: Industrieautomatisierungsprodukte variieren enorm in ihrer Funktion — von einfachen Steuereinheiten ohne Netzwerkanschluss bis zu sicherheitskritischen Anlagen, die KRITIS-Infrastruktur steuern.

Was hier viele falsch verstehen: Der CRA sei hauptsächlich ein Problem für Consumer-Produkte oder reine Softwareunternehmen. Stimmt nicht. Jede SPS mit Netzwerkfunktion, die nach Dezember 2027 in Verkehr gebracht wird, ist CRA-pflichtig — egal ob sie eine Verpackungsmaschine, eine Wasseraufbereitung oder eine Produktionslinie steuert.

Grundfrage: Wann ist eine Industriesteuerung CRA-pflichtig?

Nach Art. 2 Abs. 1 CRA gilt die Verordnung für alle “Produkte mit digitalen Elementen” — Hardware und Software — die über eine direkte oder indirekte Netzwerkverbindung verfügen.¹ Für SPS und IPC bedeutet das konkret:

CRA-pflichtig (Netzwerkfähigkeit vorhanden):

• SPS mit Ethernet-Port (auch wenn nur für Programmierung genutzt)
• IPC mit WLAN, LTE oder Ethernet
• CNC-Steuerungen mit Remote-Zugang oder OPC-UA-Interface
• SCADA-Systeme mit Netzwerkkonnektivität
• Edge-Controller die Felddaten an Cloud oder SCADA weiterleiten

Nicht CRA-pflichtig (kein Netzwerk):

• Reine Offline-SPS ohne jede Netzwerkschnittstelle
• Serielle Punkt-zu-Punkt-Verbindungen ohne IP-Netzwerkfähigkeit (RS-232, Profibus ohne Gateway)

In der Praxis sind offline-only Industriesteuerungen selten geworden. Selbst einfache SPS haben heute typischerweise einen Ethernet-Port für Programmierung oder Diagnose. Und damit CRA-Relevanz.

Ein Hersteller von Verpackungsmaschinen — z.B. mit verbauter SPS und Ethernet-Diagnoseschnittstelle — ist betroffen, weil genau dieser Port eine “indirekte Netzwerkverbindung” im Sinne von Art. 2 Abs. 1 CRA begründet, auch wenn die Maschine nie ans Internet angeschlossen wird. Das überrascht viele Maschinenbauer. Ein Hersteller von industriellen MQTT-Gateways für die Lebensmittelindustrie trifft dasselbe zu: Sobald das Gateway Sensordaten per MQTT weiterleitet, greift die Verordnung — vollständig, ohne Ausnahme.

Risikoklassen für Industriesteuerungen

Default-Klasse: Die häufigste Einstufung

Die meisten Standard-SPS und IPC ohne explizite Sicherheitsfunktion fallen in die Default-Klasse. Das gilt für:

• SPS die Maschinensteuerung (Bewegung, Dosierung, Verpackung) übernehmen ohne Safety-Funktion
• IPC die als Prozessrechner oder HMI-Rechner eingesetzt werden
• CNC-Steuerungen für Fräs- und Drehmaschinen ohne Netzwerk-Sicherheitsmodul
• Edge-Controller und IoT-Gateways für Sensor-Aggregation

Default-Klasse bedeutet: Hersteller können die Konformität per Selbstbewertung nachweisen, ohne Notified Body.¹ Aber Default bedeutet nicht geringer Aufwand — alle inhaltlichen Anforderungen aus Anhang I CRA gelten vollständig:

• Risikoanalyse (Cyber Security Risk Assessment)
• SBOM für die gesamte eingebettete Software
• OTA-Update-Fähigkeit (soweit technisch umsetzbar)
• CVE-Monitoring für alle Softwarekomponenten
• Vulnerability Disclosure Policy

Das klingt nach bürokratischem Aufwand. Ist es auch. Gerade für kleinere Maschinenbau-Hersteller, die bisher keine strukturierte Software-Dokumentation gepflegt haben.

Important Class II: Wann wird eine Industriesteuerung “hochklassifiziert”?

Anhang III Klasse II des CRA enthält eine Kategorie die für Industrieautomatisierung relevant ist: “Industrielle Automatisierungs- und Steuerungssysteme” mit Safety-Funktion oder kritischer Infrastrukturanwendung.¹

Eine SPS oder ein IPC fällt in Important Class II, wenn:

1. Das Produkt Sicherheitsfunktionen im Sinne von IEC 61508 (Functional Safety) übernimmt — also Safety-PLCs, Safety-Controller oder sicherheitsgerichtete Antriebssteuerungen
2. Das Produkt in kritischen Infrastrukturen (KRITIS nach BSI) eingesetzt wird und explizit dafür ausgelegt ist
3. Das Produkt Netzwerk-Sicherheitsfunktionen integriert (Firewall, IDS/IPS, sichere Kommunikationsmodule)

Das ist der Punkt, den viele übersehen: “Explizit ausgelegt für KRITIS” klingt nach einer engen Ausnahme. In der Praxis vermarkten aber viele IPC-Hersteller ihre Produkte aktiv für Energieversorger oder Wasserwerke — und landen damit direkt in Important Class II. Mit der Konsequenz, dass ein Notified Body für die Konformitätsbewertung Pflicht wird — unabhängig davon, ob harmonisierte Normen angewendet werden.¹

Ein konkretes Beispiel: Ein Industrie-4.0-Anbieter entwickelt eine Safety-PLC für automatisierte Fertigungslinien in der Automobilindustrie. Sobald er dieses Produkt als “geeignet für sicherheitsgerichtete Steuerungsaufgaben nach IEC 61508” vermarktet, greift Important Class II — und damit die Notified-Body-Pflicht. Der Unterschied zu einem Standard-Zertifizierungsverfahren: Das kostet mehr Zeit und Geld, beides knapp bei KMUs.

IEC 62443 und der CRA: Wie verhält sich der Industriestandard zur Verordnung?

IEC 62443 ist der etablierte internationale Standard für industrielle Cybersicherheit (Industrial Automation and Control Systems Security). Er ist in der OT-Welt weitverbreitet und vielen Maschinenbauern bereits aus Kundenprojekten bekannt.

IEC 62443 als Vorbereitung auf den CRA

Die Anforderungen von IEC 62443 und CRA überlappen erheblich — aber sie sind nicht identisch:

Wichtig: Eine IEC-62443-Zertifizierung ersetzt die CRA-Konformitätsbewertung nicht automatisch. Bis harmonisierte Normen vorliegen, die explizit IEC 62443 als Grundlage für CRA-Konformität anerkennen, müssen Hersteller die CRA-Anforderungen separat nachweisen.

Die EU-Kommission arbeitet daran, harmonisierte Normen zu entwickeln die IEC 62443 einbeziehen — aber dieser Prozess ist 2026 noch nicht abgeschlossen. Maschinenbau-Hersteller, die IEC 62443 bereits umgesetzt haben, starten trotzdem mit einem erheblichen Vorsprung bei der CRA-Compliance.

In der Praxis erleben wir: Hersteller von embedded-Software für Antriebssteuerungen, die eine IEC-62443-Bewertung vorweisen können, unterschätzen den verbleibenden CRA-Gap — vor allem bei SBOM-Dokumentation und formaler Vulnerability Disclosure Policy. Beides verlangt der CRA explizit. IEC 62443 adressiert es nur indirekt.

OPC-UA: Kommunikationsprotokoll mit CRA-Konsequenzen

OPC Unified Architecture (OPC-UA) ist das Standardprotokoll für die Kommunikation zwischen Industriesteuerungen, HMIs und übergelagerten Systemen (SCADA, MES, ERP). Fast jede moderne SPS und jeder IPC unterstützt OPC-UA.

OPC-UA selbst ist ein sicherheitsbewusstes Protokoll — es enthält Transport-Verschlüsselung (TLS), Authentifizierung und Autorisierungskonzepte. Trotzdem entstehen durch OPC-UA konkrete CRA-Anforderungen:

Sichere OPC-UA-Konfiguration als Pflicht:

• OPC-UA Security Mode “None” (unverschlüsselt) darf nicht die Standard-Werkseinstellung sein (Secure by Default, Anhang I Nr. 2)¹
• Hersteller müssen das Zertifikatsmanagement dokumentieren und im Betrieb handhabbar gestalten
• Hersteller müssen OPC-UA-Server-Endpunkte in der Risikoanalyse als Angriffsfläche berücksichtigen
• Authentifizierung muss aktiviert und mit starken Credentials konfiguriert sein

Ein typisches Problem: Viele Hersteller von industriellen MQTT-Gateways und OPC-UA-fähigen Edge-Controllern liefern ihre Geräte mit Security Mode “None” aus, weil Integratoren die Inbetriebnahme sonst als zu aufwändig empfinden. Nach dem CRA ist das ein direktes Compliance-Problem — Anhang I Nr. 2 schreibt die sicherste Konfiguration als Standard vor. Hersteller müssen das ändern, bevor sie nach Dezember 2027 liefern.

Die wichtigsten Herausforderungen für Maschinenbau-Hersteller

1. SBOM für eingebettete Steuerungssoftware

Industriesteuerungen enthalten typischerweise: RTOS (VxWorks, QNX, FreeRTOS, Embedded Linux), Kommunikationsstacks (OPC-UA, Modbus, PROFINET), Sicherheitsbibliotheken (OpenSSL, mbedTLS), proprietäre Laufzeitumgebungen des SPS-Anbieters.

Die SBOM-Erstellung ist besonders dann schwierig, wenn Chiphersteller oder Laufzeitanbieter Teile der Software als Binärsoftware liefern. Hersteller müssen ihre Lieferanten aktiv um Komponentenlisten bitten — und vertraglich sicherstellen, dass diese CVE-relevante Informationen zeitnah melden.

Konkret bedeutet das: Ein IoT-Startup, das einen Edge-Controller auf Basis von Embedded Linux entwickelt, muss nicht nur die eigene Codebasis dokumentieren, sondern auch alle Open-Source-Komponenten im Linux-Image — inklusive Versionsstand und bekannter CVEs zum Zeitpunkt des Inverkehrbringens.

2. Lebensdauer-Unterstützung: 5 Jahre als Minimum

Industriesteuerungen haben typischerweise sehr lange Einsatzdauern — 10, 15 oder 20 Jahre sind keine Seltenheit. Anhang I Teil I Nr. 10 CRA fordert Sicherheitsupdates über die “erwartete Nutzungsdauer” des Produkts.¹

Was viele CRA-Berater nicht sagen: Für Maschinenbaukomponenten, die als “für 15 Jahre gewartet” vermarktet werden, ergibt sich daraus eine 15-jährige Sicherheitsupdate-Pflicht — weit über das gesetzliche Minimum von 5 Jahren hinaus. Hersteller müssen Produkt-Lebensdauer-Versprechen jetzt mit diesem Compliance-Aufwand abgleichen. Wer “Lifetime Support” verspricht, verpflichtet sich damit auch zur langfristigen CVE-Behebung.

3. Remote-Access und Fernwartung

Fernwartungszugänge für Maschinenbau-Produkte sind eine der kritischsten Angriffsflächen. Anforderungen aus Anhang I:¹

• Fernwartungs-Kanäle müssen verschlüsselt sein (keine Klartext-Remote-Access-Protokolle)
• Hersteller müssen starke Authentifizierung für Remote-Access sicherstellen (MFA empfohlen)
• Remote-Access muss standardmäßig deaktiviert oder auf das Notwendigste beschränkt sein
• Hersteller sollten alle Fernwartungssitzungen protokollieren

4. Lieferketten-Verantwortung

Maschinenbauer, die SPS-Komponenten, Kommunikationsmodule oder Feldgeräte von Drittherstellern verbauen, übernehmen Verantwortung für die Lieferkette. Ist ein verbautes Modul nicht CRA-konform, haftet der Maschinenbauer als Hersteller des Gesamtprodukts. Das gilt auch dann, wenn der Drittanbieter ein etablierter Komponentenlieferant ist, der die eigene CRA-Pflicht schlicht noch nicht erfüllt hat.

Was Maschinenbau-Hersteller jetzt tun sollten

1. Produktportfolio klassifizieren Für jede SPS, jeden IPC und jede CNC-Steuerung im Portfolio prüfen: Netzwerkfähig? Welche Klasse? Besonders bei Safety-PLCs die Important-Class-II-Frage frühzeitig klären — ein Notified-Body-Verfahren braucht Zeit.

2. IEC-62443-Implementierungsstand erfassen Welche Produkte haben bereits eine IEC-62443-Bewertung? Das ist eine gute Ausgangsbasis für CRA-Compliance — aber kein vollständiger Ersatz.

3. OPC-UA-Konfigurationen prüfen Liefern aktuelle Produkte OPC-UA mit Security Mode “None” als Werkseinstellung aus? Wenn ja: Konfigurationsänderung planen und in die Produkt-Roadmap aufnehmen. Deadline: Dezember 2027.

4. Lieferantenverträge auf CRA-Klauseln prüfen Besonders kritisch: alle Lieferanten von eingebetteten Software-Stacks, RTOS-Lizenzen und Kommunikationsmodulen. Wer hier keine vertraglichen Zusagen bekommt, trägt das Risiko allein.

5. Fernwartungs-Architektur bewerten Bestehende Remote-Access-Lösungen gegen die Anhang-I-Anforderungen prüfen und modernisieren — bevor die Marktaufsichtsbehörde das einfordert.

Weiterführende Themen

• Produktklassen im Überblick → CRA Risikoklassen: Default, Important, Critical
• Alle technischen Anforderungen → CRA Anhang I im Detail
• SBOM-Anforderungen → SBOM erstellen: Anforderungen nach CRA
• Lieferketten-Verantwortung → CRA und Lieferkette
• Schwachstellen melden → Schwachstellen-Meldepflicht nach Art. 14 CRA

Den kostenlosen CRA-Check können Sie nutzen um eine erste indikative Einschätzung Ihrer Industriesteuerung zu erhalten. Für Hersteller die CRA-Compliance systematisch angehen wollen, bietet das Evidence Pack strukturierte Vorlagen für Risikoanalyse, SBOM und technische Dokumentation nach CRA-Anforderungen.

Quellen

1. EU-Verordnung 2024/2847 des Europäischen Parlaments und des Rates vom 23. Oktober 2024 (Cyber Resilience Act), Artikel 2 (Anwendungsbereich), Anhang III Klasse II (Industriesteuerungen), Anhang I Teil I (Nr. 2, 10, technische Anforderungen), Anhang I Teil II (Schwachstellenpflichten): https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=OJ:L_202402847
2. IEC 62443 — Industrial Automation and Control Systems Security (Normenserie): https://www.iec.ch/homepage (Normenreihe IEC 62443-x-x)
3. OPC Foundation — OPC UA Security: https://opcfoundation.org/developer-tools/documents/view/158
4. BSI — ICS-Security: Empfehlungen für Betreiber und Hersteller industrieller Steuerungssysteme: https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Empfehlungen-nach-Angriffszielen/Industrielle-Steuerungs-und-Automatisierungssysteme/ISA.html
5. ENISA — Good Practices for Security of Internet of Things in the Context of Smart Manufacturing: https://www.enisa.europa.eu/publications/good-practices-for-security-of-iot

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 empfehlen wir rechtliche und technische Fachberatung.