„Der CRA ist heute schon Gesetz, europaweit“

Interview mit Boris Waldeck über den Cyber Resilience Act

Boris Waldeck (links) und Philip Bittermann
Das Interview zwischen Boris Waldeck (links) und Philip Bittermann entstand Ende September auf dem PLCnext Community Summit.

Boris Waldeck, Master Specialist für PLCnext Technology Industry Management and Automation bei Phoenix Contact, erklärt, warum der Cyber Resilience Act (CRA) für die Industrie zur Herausforderung und Chance zugleich wird, welche Rolle IEC 62443 spielt und warum KMU jetzt handeln müssen.

neue verpackung: Herr Waldeck, wir reden heute über Cybersecurity und vor allem auch über den Cyber Resilience Act. Wie bewertet Phoenix Contact den CRA eigentlich grundsätzlich – ist er eher eine zusätzliche regulatorische Herausforderung oder auch eine Chance für ein Unternehmen wie Ihres?
Boris Waldeck: Beides trifft zu. Wir bei Phoenix Contact sind seit mehr als zehn Jahren im Bereich Cybersecurity aktiv. Angefangen haben wir mit unserem
Mguard als Firewall und VPN für die Fernwartung, gefolgt von der IEC 62443-Zertifizierung der PLCnext-Technology. Der sichere Entwicklungsprozess ist dabei ein zentraler Bestandteil – und mittlerweile fest in unsere Abläufe integriert.

Seit Dezember 2024 sind bei uns sieben Business Units durch den TÜV Rheinland nach IEC 62443 4-1 (Secure Development Lifecycle) zertifiziert. Eine kleine zweistellige Zahl an Geräten trägt bereits das entsprechende Zertifikat. Das sehen wir als klare Differenzierung am Markt.

Die Herausforderung liegt jetzt in der Skalierung – also darin, die geforderten Prozesse und Funktionen auf eine große Zahl von Produkten zu übertragen. Es geht ja nicht mehr nur um zehn oder zwanzig Geräte, sondern um mehrere Hundert und darüber hinaus. Hier das richtige Verhältnis zwischen gesetzlicher Anforderung, Aufwand und tatsächlichem Sicherheitsnutzen zu finden, ist die eigentliche Aufgabe.

neue verpackung: Welche konkreten Maßnahmen haben Sie ergriffen, um den neuen Anforderungen gerecht zu werden?
Waldeck: Im Kern unserer CRA-Aktivitäten steht die IEC 62443-Zertifizierung. Denn diese Norm wird ja voraussichtlich die Basis für den harmonisierten Standard bilden, der 2026 verfügbar sein soll. Wir fühlen uns damit gut aufgestellt. Der CRA fordert zudem einen risikobasierten Ansatz – das heißt, man kann je nach Produktklasse nur ein Subset der Anforderungen anwenden.

Im Mittelpunkt steht aber immer der sichere Entwicklungsprozess (Security Development Lifecycle, kurz SDL). Ohne diese Prozesse ist ein verlässlicher Nachweis der Sicherheits-Härtung kaum möglich. Ohne SDL kann man den CRA aus meiner Sicht nicht erfüllen.

neue verpackung: Automatisierung ist ein breites Feld, viele Branchen und Produkte sind betroffen. Wo liegen nach Ihren bisherigen Erfahrungen denn eigentlich die größten Herausforderungen?
Waldeck: Der CRA gilt für Produkte mit digitalen Elementen, die physisch oder virtuell kommunizieren können – das betrifft viele unserer Produkte. Die eigentliche Herausforderung, auch aus Sicht der Gremien, liegt aber im Bereich Maschinenbau. Ich bin Mitglied im VDMA-Arbeitskreis Industrial Security, und dort wird deutlich: Der CRA für Maschinen ist die Herausforderung.

neue verpackung: Und gerade hier gilt: Ein Produkt CRA-konform zu entwickeln, ist das eine. Danach steht es im Feld – und muss mindestens fünf Jahre lang abgesichert bleiben. Wie lässt sich das gewährleisten?
Waldeck: Das ist tatsächlich eine große Herausforderung. Prozessual greifen hier Prinzipien wie Security by Design, Security by Default, Schwachstellenmanagement, das Product Security Incident Response Team (PSIRT) sowie daraus resultierende Advisorys und Updates.

Aber der Zeitraum ist kritisch: Fünf Jahre sind das Minimum – in unserem Markt wird das vermutlich nicht reichen. Der Markt wird letztlich entscheiden, wie lange kostenfreie Sicherheitsupdates erwartet werden. Und hier ist es dann auch nur fair zu sagen: Diese Verpflichtung wird sich zwangsläufig in den Produktkosten niederschlagen. Vielen ist noch gar nicht bewusst, dass man über Jahre hinweg kostenfreie Security-Updates liefern muss – wenn auch glücklicherweise nur für tatsächlich ausnutzbare Schwachstellen.

Wer jetzt etwas tun muss, kann sich nur an der IEC 62443 orientieren.

neue verpackung: Wäre für die Zeit danach ein kostenpflichtiges Modell denkbar, etwa ein Abo für Updates?
Waldeck: Das ist eine schwierige Frage. Alle im Markt wollen Security. Aber wenn man mit Kunden spricht, dann soll sie natürlich nicht mehr kosten als vorher. Wie wir das genau lösen, ist noch offen – eine abschließende Antwort gibt es also derzeit noch nicht. Glücklicherweise haben wir noch zwei Jahre Zeit, auch wenn zwei Jahre in diesem Kontext sehr wenig sind.
Fest steht: Wer 2027 CRA-konforme Maschinen anbieten will, muss spätestens im Laufe des nächsten Jahres Antworten auf diese Fragen haben.

neue verpackung: In der Prozessindustrie oder bei Verpackungsmaschinen stehen viele Anlagen jahrzehntelang im Einsatz. Wie verhält es sich also bei den sogenannten Legacy-Systemen? Werden auch solche bereits im Feld stehenden Systeme nachträglich gehärtet oder beginnt der CRA erst mit neuen Produkten?
Waldeck: Im ersten Entwurf des CRA vom September 2023 war das Thema Ersatzteile nicht berücksichtigt. Erst durch das Feedback der Verbände wurde der Begriff „Spare Parts“ ergänzt. Der CRA lässt hier jedoch Interpretationsspielraum. Nach meinem Verständnis bedeutet das: Ein heute in einer Maschine verbautes Produkt, das ersetzt werden muss, darf weiterhin ohne CRA-Konformität ausgetauscht werden – allerdings nur im Rahmen eines 1:1-Austauschs. Eine Erweiterung oder Modernisierung fällt nicht darunter.

Für Bestandsprodukte heißt das: Wir müssen sie bewerten. Aufgrund der Vielzahl an Produkten empfiehlt es sich, Produktklassen zu bilden und diese risikobasiert zu analysieren. So lässt sich das Thema schrittweise und systematisch angehen.

Worum geht es in der IEC 62443?

Die Normenreihe IEC 62443 definiert Anforderungen an die IT-Sicherheit industrieller Automatisierungssysteme. Sie umfasst technische Maßnahmen, Prozesse und Rollenmodelle für Hersteller, Integratoren und Betreiber. Besonders relevant ist Teil 4-1, der den sicheren Entwicklungsprozess (Secure Development Lifecycle) beschreibt – eine zentrale Grundlage für die CRA-Konformität. Ziel ist es, Cyberrisiken systematisch zu minimieren und die Resilienz vernetzter Systeme zu stärken.

Digital shield representing cybersecurity protection, with blue and red lights symbolizing data security, encryption, and firewall defense.
Betrifft alle Produkte mit digitalen Elementen, die kommunizieren können: der CRA.

neue verpackung: Ist das aktuell noch eine theoretische Überlegung, oder kommen solche Fragen bereits von Ihren Kunden?
Waldeck: Die Anfragen häufen sich tatsächlich. Aber es ist schwierig, heute schon verlässlich zu sagen, welche Produkte letztlich CRA-konform sein werden. Deshalb ist die Bildung von Klassen und die risikobasierte Bewertung so wichtig. Ein Beispiel: Ein I/O-Modul ohne Firmware-Update-Funktion wird auch künftig keines bekommen – das Risiko wäre sonst höher, weil man über Updates eine neue Angriffsfläche schaffen würde. Solche Überlegungen gehören zur Bewertung dazu.

neue verpackung: Von Seiten des VDMA höre ich immer, das Bewusstsein für den CRA sei im Maschinenbau noch gering. Wie schätzen Sie das ein?
Waldeck: Da tue ich mir ehrlich gesagt etwas schwer. Ich bewege mich durch meine Gremienarbeit seit 2015 in einer Art Blase – dort ist das Thema sehr präsent. Aber es sind vor allem die großen Unternehmen, die die Kapazität haben, sich damit zu beschäftigen. Bei den KMU hingegen ist das Thema an vielen Stellen noch nicht wirklich angekommen. Der CRA erkennt das an und enthält einen eigenen Artikel zur Förderung von KMU – allerdings sehe ich bisher keine konkreten Aktivitäten dazu.

neue verpackung: Könnte die Frist 2027 angesichts der Komplexität denn noch einmal verschoben werden?
Waldeck: Ich halte das für eher unwahrscheinlich. Angesichts der zunehmenden hybriden Bedrohungslage möchte sich in der Politik niemand dem Vorwurf aussetzen, das Thema nicht ernst genug genommen zu haben.

Fakt ist jedoch: Die harmonisierten Standards werden Ende 2026 vorliegen. Ihre Zuordnung zu Gerätekategorien wie Firewalls, Switches oder VPN-Systemen dürfte sich bis ins Frühjahr 2027 hinziehen. Wer jetzt handeln muss, kann sich daher nur an der IEC 62443 orientieren – mit einem risikobasierten Ansatz und Self-Assessment, um bis Ende 2027 CRA-konform zu sein.

Viele gehen davon aus, dass der CRA erst 2027 relevant wird. Deshalb möchte ich diesen Punkt nochmals betonen: Der CRA ist bereits heute geltendes EU-Recht. Wir befinden uns lediglich in einer Übergangsphase, in der die Details konkretisiert werden. Wer erst Mitte 2027 beginnt, Produkte sicher zu entwickeln, kommt zu spät – es sei denn, es geschieht noch ein kleines Wunder.

Besonders die Verbände beobachten mit Sorge die aktuelle Lage in den Lieferketten. Für eine durchgängige CRA-Konformität ist es vorteilhaft, dass alle Glieder der Kette – vom Halbleiter über das Betriebssystem bis zur Gerätesoftware – die Anforderungen erfüllen.

Gerade bei Halbleitern stellen die langen Entwicklungszyklen eine Herausforderung dar, da sie mit den vergleichsweise kurzen CRA-Umsetzungsfristen kollidieren. Aus diesem Grund gibt es bereits erste Anfragen zu Fristverlängerung.

neue verpackung: Wir beide sprechen uns gerade auf dem PLCnext Community Summit. Gibt es denn in dieser Community bereits Initiativen, die KMU beim Thema Cybersecurity zu unterstützen?
Waldeck: Ja, wir verfolgen aktuell zwei zentrale Ansätze. Zum einen nutzen wir unsere bestehende PLCnext Technology, die bereits prozessual und funktional gut aufgestellt ist, um CRA-konforme Komponenten zu entwickeln. Zum anderen setzen wir auf interne Wiederverwendung: Durch den Einsatz einer skalierbaren Software-Komponente in neuen Projekten wollen wir Synergien schaffen und Entwicklungsaufwände reduzieren.

Diese Komponente wird noch in diesem Jahr durch den TÜV Rheinland vorabgenommen. Dadurch entsteht eine portierbare Lösung, die bereits einen großen Teil der CRA-Konformität mitbringt – was die Arbeit für Produktentwickler deutlich erleichtert. Parallel dazu arbeitet die Community daran, Wege zu finden, wie CRA-konforme Apps über unseren Store entwickelt und bereitgestellt werden können. Dafür schaffen wir ein Security-Framework, das Apps in einer geschützten Umgebung ausführt. Wenn eine App die definierten Sicherheitsanforderungen erfüllt, wird der Nachweis der CRA-Konformität deutlich vereinfacht.

neue verpackung: Der CRA wurde in einer Zeit entworfen, als KI noch keine so große Rolle spielte. Welche Entwicklungen erwarten Sie künftig beim Thema Cybersecurity?
Waldeck: Security in der IT ist nichts Neues – aber in der OT stehen wir erst am Anfang einer großen Veränderung. Wir müssen zunächst zur IT aufschließen, und gleichzeitig kommen neue Themen wie KI hinzu. Das ist eine doppelte Herausforderung: Einerseits den CRA in zwei Jahren umzusetzen, andererseits danach auf diesem Niveau weiterzumachen.

neue verpackung: Was erwarten Sie von Verbänden und Politik bei der Umsetzung des CRA?
Waldeck: Ich sehe, dass die Verbände mit großer Ernsthaftigkeit und Kompetenz an der Interpretation und Umsetzung des CRA arbeiten – etwa mit den Papieren von VDMA und ZVEI zu Themen wie Schwachstellenmanagement oder SBOM.

Wichtig ist aber auch, dass das Feedback der Verbände in den politischen Gremien Gehör findet. Ich habe den Eindruck, dass das an manchen Stellen noch ausbaufähig ist. Gerade das anwendungsspezifische Feedback aus der OT sollte stärker berücksichtigt werden – auch wenn der CRA als übergreifende Regulierung natürlich immer ein gewisses Abstraktionsniveau behalten muss.

neue verpackung: Sie beschäftigen sich seit 2015 mit dem Thema Cybersecurity. Was war für Sie die wichtigste Erkenntnis in dieser Zeit?
Waldeck: Wir haben bei Phoenix Contact viel prozessuale Kompetenz aufgebaut und wissen, wie man Produkte sicher entwickelt. Was mich dennoch überrascht hat, ist die Auswirkung des CRA auf Softwarekomponenten und -werkzeuge. Außer in der Medizintechnik war mir bisher keine CE-Kennzeichnung für Software bekannt – das ist völlig neu und wird besonders für Apps eine große Rolle spielen.

Die Fragen stellte Philip Bittermann, Chefredakteur neue verpackung