CRA für Automatisierungskomponenten: SPS, HMI, Feldgeräte und Industrie-Switches

Ihre Komponente ist ein eigenes Produkt

Wer speicherprogrammierbare Steuerungen (SPS), Bediengeräte (HMI), Feldgeräte oder Industrie-Switches an Maschinen- und Anlagenbauer liefert, ist nach dem Cyber Resilience Act (Verordnung (EU) 2024/2847, CRA) selbst Hersteller. Ein Produkt mit digitalen Elementen ist „ein Software- oder Hardwareprodukt und dessen Datenfernverarbeitungslösungen, einschließlich Software- oder Hardwarekomponenten, die getrennt in den Verkehr gebracht werden“ (Art. 3 Nr. 1). Eine CPU-Baugruppe, ein Panel oder ein Switch, den Sie unter Ihrem Namen oder Ihrer Marke vermarkten, ist damit ein eigenes Produkt (Hersteller: Art. 3 Nr. 13), auch wenn es beim Kunden nur ein Teil der Maschine ist.

Voraussetzung ist eine Datenverbindung: Der CRA gilt für Produkte, deren bestimmungsgemäßer Zweck oder vernünftigerweise vorhersehbare Verwendung „eine direkte oder indirekte logische oder physische Datenverbindung mit einem Gerät oder Netz einschließt“ (Art. 2 Abs. 1). Bei einfachen Feldgeräten lohnt der genaue Blick, denn die Verordnung definiert den Begriff nicht. Nach dem Entwurf der Leitlinie der Kommission zur Anwendung des CRA, dessen Inhalt die Kommission am 27.07.2026 gebilligt hat (C(2026) 5252, bisher nur englisch; die förmliche Annahme steht aus) müssen Zustände bewusst als Information kodiert und am Ziel als Information dekodierbar sein; ein Signal, das nur eine Funktion auslöst oder versorgt, genügt danach nicht (Rn. 28). Ein Sensor mit IO-Link überträgt kodierte Daten, ein reiner Schaltausgang ist im Einzelfall zu prüfen.

Zum Status des Entwurfs: Nach der Begleitmitteilung der Kommission wird die Leitlinie förmlich angenommen, wenn alle Sprachfassungen vorliegen, und gilt erst ab dann. Auch dann ist sie nicht verbindlich; eine verbindliche Auslegung kann nur der Gerichtshof der Europäischen Union geben (Rn. 8). Wir nennen den Entwurf nur ergänzend, maßgeblich bleibt der Verordnungstext.

Die Sicht des Maschinenbauers behandelt der Beitrag Cyber Resilience Act im Maschinenbau, Controller der Gebäudeautomation die Seite Gebäudetechnik und GLT, Firewalls und VPN-Appliances die Seite Netzwerk- und Security-Hardware. (Dieser Text ordnet technisch ein und ist keine Rechtsberatung.)

Warum Ihre Kunden Nachweise anfordern

Der Maschinenbauer muss als Hersteller seines Produkts „die gebotene Sorgfalt walten“ lassen, wenn er „von Dritten bezogene Komponenten“ integriert (Art. 13 Abs. 5). Erwägungsgrund 34 nennt dafür, je nach Risiko, unter anderem die Prüfung, ob die Komponente mit der CE-Kennzeichnung versehen ist, ob regelmäßig Sicherheitsaktualisierungen erscheinen und ob sie in öffentlich zugänglichen Schwachstellendatenbanken auffällt. Nach dem Leitlinien-Entwurf stützt sich der Integrator dabei auch auf Unterlagen des Komponentenherstellers wie technische Spezifikationen oder Sicherheitsdokumentation (Rn. 171). Daraus entstehen die Fragen in Lieferantenfragebögen:

• Software-Stückliste (SBOM): Sie erstellen eine SBOM „in einem gängigen maschinenlesbaren Format“, aus der zumindest die obersten Abhängigkeiten hervorgehen (Anhang I Teil II Nr. 1), und führen sie in der technischen Dokumentation (Anhang VII Nr. 2 Buchst. b). Eine ausdrückliche Pflicht zur Herausgabe an Abnehmer enthält der CRA nicht; Anhang II Nr. 9 regelt nur den Fall, dass Sie sie dem Nutzer zur Verfügung stellen. Die Weitergabe regelt deshalb Ihr Liefervertrag.
• Unterstützungszeitraum: Er spiegelt die voraussichtliche Nutzungsdauer wider und beträgt mindestens fünf Jahre, kürzer nur bei kürzerer erwarteter Nutzung (Art. 13 Abs. 8); das Enddatum ist beim Kauf mindestens mit Monat und Jahr anzugeben (Art. 13 Abs. 19). Ihr Kunde kann bei seinem eigenen Zeitraum die Unterstützungszeiträume integrierter Komponenten berücksichtigen, die Kernfunktionen erbringen (Art. 13 Abs. 8 Unterabs. 2).
• Schwachstelleninformation: Nach einer Sicherheitsaktualisierung veröffentlichen Sie Informationen über behobene Schwachstellen (Anhang I Teil II Nr. 4) und nennen eine Kontaktadresse für Meldungen (Nr. 6). Über sie erreicht Sie auch Ihr Kunde, der Schwachstellen in Ihrer Komponente an Sie melden muss (Art. 13 Abs. 6).
• Integrationshinweise: Ist Ihr Produkt für den Einbau bestimmt, gehört in die Nutzerinformation, wie der Integrator die Anforderungen aus Anhang I und Anhang VII erfüllen kann (Anhang II Nr. 8 Buchst. f).

Typische Produkte und ihre wahrscheinliche Einordnung

Ob ein Produkt in Anhang III (wichtig, Klasse I oder II) oder Anhang IV (kritisch) fällt, richtet sich nach seiner Kernfunktion (Art. 7 Abs. 1, Art. 8 Abs. 1); die technischen Beschreibungen legt die Durchführungsverordnung (EU) 2025/2392 (DVO) fest. Die Tabelle ist eine technische Ersteinschätzung und ersetzt keine verbindliche Einordnung Ihres Produkts.

Der Einbau einer Komponente mit Anhang-III-Kernfunktion macht das Gesamtprodukt nicht für sich genommen zum wichtigen Produkt (Art. 7 Abs. 1 Satz 2). Bieten Sie ein Kommunikationsmodul aber auch einzeln an, ist es als getrennt in Verkehr gebrachte Komponente ein eigenes Produkt (Art. 3 Nr. 1) mit eigener Kernfunktion; so sieht es auch der Leitlinien-Entwurf (Rn. 145). Datenblatt, Anleitung und technische Dokumentation sollten dieselbe Zweckbestimmung beschreiben (Anhang VII Nr. 1 Buchst. a); eine SPS, die im Prospekt als „Security-Router“ auftritt, verdient einen zweiten Blick. Ein unmanaged Switch ohne Managementebene entspricht der DVO-Beschreibung nicht ohne Weiteres und ist im Einzelfall zu prüfen.

Standardprodukte bewerten Sie selbst (Modul A, Art. 32 Abs. 1). In Klasse I ist Modul A nur möglich, wenn harmonisierte Normen, gemeinsame Spezifikationen oder ein europäisches Schema mindestens der Stufe „mittel“ vollständig angewandt werden, sonst Modul B+C oder H (Art. 32 Abs. 2); Klasse II verlangt Modul B+C, H oder ein solches Schema (Art. 32 Abs. 3). Mehr im Beitrag CRA-Produktklassen.

IEC 62443-4-1 und -4-2: Praxisrahmen ohne Vermutungswirkung

In der Automatisierung ist IEC 62443 eingeführt: Teil 4-1 regelt den sicheren Entwicklungsprozess, Teil 4-2 technische Sicherheitsanforderungen an Komponenten von Automatisierungssystemen. Eine Konformitätsvermutung entsteht aus Normen aber nur bei harmonisierten Normen, deren Fundstellen im Amtsblatt der EU veröffentlicht sind, und nur soweit sie die Anforderungen abdecken (Art. 27 Abs. 1). Am 01.11.2026 war im Amtsblatt keine harmonisierte Norm zum CRA veröffentlicht; IEC 62443 begründet derzeit also keine Vermutungswirkung. Nützlich bleibt ein gelebter 62443-Prozess trotzdem: Ohne harmonisierte Normen beschreibt die technische Dokumentation die gewählten Lösungen (Anhang VII Nr. 5), und dort lassen sich die Nachweise einordnen. Gleichen Sie Ihre 62443-Nachweise Anforderung für Anforderung mit Anhang I und den übrigen Pflichten ab und ergänzen Sie, was sie nicht abdecken. Dazu gehören jedenfalls die Meldungen nach Art. 14 über die einheitliche Meldeplattform; ob Ihre Risikobewertung den Vorgaben von Art. 13 Abs. 2 und 3 entspricht, gehört ebenfalls in diesen Abgleich. Mehr auf der Seite IEC 62443-4-1 und CRA.

Komplexe Systeme, ältere Protokolle und Bestandskomponenten

Der CRA setzt bei der Risikobewertung an: Die Anforderungen aus Anhang I Teil I Nr. 2 gelten auf ihrer Grundlage „soweit zutreffend“, und ist eine Anforderung nicht anwendbar, gehört eine klare Begründung in die technische Dokumentation (Art. 13 Abs. 3 und 4). Der Leitlinien-Entwurf wendet das auf komplexe Systeme an, die aus mehreren Elementen bestehen und als ein Produkt in Verkehr gebracht werden (Rn. 29 bis 32): Lange Entwicklungszyklen, ältere Komponenten und Interoperabilitätsstandards nehmen sie nicht aus dem Anwendungsbereich; Einschränkungen sind zu dokumentieren, mit ausgleichenden Maßnahmen zu behandeln und im Unterstützungszeitraum neu zu bewerten. Für Feldbusprotokolle ohne eingebaute Sicherheit passt Beispiel 10: Das ältere Protokoll ist zulässig, soweit die Interoperabilität es erfordert und die Risiken anders gemindert werden; ist beides machbar, wird das sichere Protokoll umgesetzt und standardmäßig aktiviert.

Beispiel 11 des Entwurfs betrifft Ihre Kunden: Ein Hersteller eines industriellen Automatisierungssystems baut vor Geltungsbeginn gekaufte Mikrocontroller ein, nachdem seine Risikobewertung keine besonderen Risiken daraus ergeben hat, und stellt sicher, dass das System als Ganzes die Anforderungen erfüllt. Für Ihre eigenen Produkte zählt das Inverkehrbringen, also die erstmalige Bereitstellung eines Produkts (Art. 3 Nr. 21), nach dem Entwurf je Stück (Rn. 11). Stücke, die vor dem 11.12.2027 in Verkehr gebracht wurden, unterliegen den Anforderungen nur bei einer späteren wesentlichen Änderung (Art. 69 Abs. 2). Stücke einer älteren Baureihe, die Sie danach erstmals ausliefern, brauchen Konformitätsbewertung, EU-Konformitätserklärung und CE-Kennzeichnung (Art. 13 Abs. 12); welche Maßnahmen dafür nötig sind, ergibt die Risikobewertung (Art. 13 Abs. 2).

Identische Ersatzteile nach denselben Spezifikationen nimmt Art. 2 Abs. 6 aus; nach Beispiel 39 des Entwurfs kann das auch eine komplette Ersatz-SPS für ein bestimmtes Automatisierungssystem sein, ein Nachfolge-Chip mit anderer Kryptografie dagegen nicht (Beispiel 37). Die Anforderungen an automatische Aktualisierungen gelten nach Erwägungsgrund 56 nicht für Produkte, die in erster Linie zum Einbau bestimmt sind, und nicht für industrielle Umgebungen, in denen automatische Updates den Betrieb stören könnten. Sicherheitsaktualisierungen stellen Sie trotzdem bereit (Anhang I Teil II Nr. 2 und 8).

Fristen, Datenfernverarbeitung und Maschinenverordnung

Seit dem 11.09.2026 gelten die Meldepflichten nach Art. 14 (Art. 71 Abs. 2), auch für Produkte, die vor dem 11.12.2027 in Verkehr gebracht wurden (Art. 69 Abs. 3): aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle über die einheitliche Meldeplattform, mit einer Frühwarnung unverzüglich, in jedem Fall innerhalb von 24 Stunden nach Kenntnis (Art. 14 Abs. 1 bis 4). Alle übrigen Pflichten gelten ab dem 11.12.2027 (Art. 71 Abs. 2). Mehr auf der Seite Meldeprozess und PSIRT.

Betreiben Sie ein Portal für Fernzugriff, Konfiguration oder Update-Verteilung, prüfen Sie die Datenfernverarbeitung: Software, die Sie selbst oder unter Ihrer Verantwortung entwickeln und ohne die das Produkt eine seiner Funktionen nicht erfüllen könnte, gehört zum Produkt (Art. 3 Nr. 1 und 2). Sicherheitssteuerungen können zusätzlich unter die Maschinenverordnung (EU) 2023/1230 fallen, die „Logikeinheiten zur Gewährleistung von Sicherheitsfunktionen“ als Sicherheitsbauteile listet (Anhang II Nr. 4); „Logikeinheiten für Sicherheitsfunktionen“ stehen zudem in Anhang I Teil B Nr. 17, für den Art. 25 Abs. 3 der Maschinenverordnung spezifische Konformitätsbewertungsverfahren vorsieht. Der CRA nimmt sie nicht aus; seine Ausnahmen in Art. 2 Abs. 2 bis 4 betreffen Medizinprodukte, In-vitro-Diagnostika, Fahrzeug-Typgenehmigung, Luftfahrt und Schiffsausrüstung.

Ein konstruiertes Beispiel

Ein mittelständischer Hersteller liefert Kompaktsteuerungen, Touch-Panels, einen Managed Switch und ein auch einzeln bestellbares PROFINET-Modul. Ein Maschinenbauer fragt nach SBOM je Firmware-Stand, Ende des Unterstützungszeitraums, Veröffentlichung von Schwachstellen und Stand zu IEC 62443-4-2. Der Hersteller schätzt technisch ein: Steuerungen und Panels voraussichtlich Standard, Switch und Modul voraussichtlich Klasse I. Weil er weder harmonisierte Normen noch gemeinsame Spezifikationen oder ein europäisches Schema anwenden kann, plant er für beide eine notifizierte Stelle ein. Er legt Enddaten je Produktlinie fest, erzeugt die SBOM aus dem Firmware-Build, veröffentlicht Sicherheitshinweise mit einer Richtlinie zur koordinierten Offenlegung, schreibt Integrationshinweise und beantwortet daraus den Fragebogen. Wer Hersteller ist, wenn ein Kunde Panels unter eigener Marke weiterverkauft, markiert er zur Prüfung durch seine Rechtsabteilung.

Nächste Schritte

1. Produktliste mit Varianten anlegen und je Produkt die Kernfunktion festhalten, auch für einzeln verkaufte Module.
2. Den Meldeprozess nach Art. 14 prüfen, denn er gilt bereits.
3. Unterstützungszeiträume festlegen und die SBOM je Release aus dem Build erzeugen.
4. Kundenunterlagen vorbereiten: Integrationshinweise, Sicherheitshinweise, Kontaktadresse für Schwachstellen.
5. Den Konformitätsweg je Produkt planen, für Klasse I mit früher Einbindung einer notifizierten Stelle.

Blackfort Technology schätzt in der CRA-Gap-Analyse die Einordnung Ihrer Komponenten technisch ein, nimmt Fragebögen Ihrer Abnehmer auf und markiert rechtlich offene Fragen, etwa zu Rolle oder Produktklasse, zur Prüfung durch Ihre Rechtsabteilung. SBOM und Schwachstellenbehandlung führen wir mit Ihren Teams in der SBOM-Beratung ein. Ein erster Schritt ist der Betroffenheits-Check; für ein Gespräch: Kontakt aufnehmen.