Cyber Resilience Act: Vernetzte Maschinen fallen darunter

Der Cyber Resilience Act (CRA) ist eine EU-Verordnung, die jedes digitale Produkt betrifft, das mit einem anderen Gerät oder einem Netz interagieren kann. Für Maschinenbauer bedeutet das: Konnektivität wie Remote-Support, Cloud-Anbindung oder Bluetooth-Schnittstellen lösen Pflichten aus, darunter Cyber-Risk-Assessments, ein Incident-Response-Team und eine CE-Konformitätserklärung.

Das Wichtigste in Kürze

• Der Cyber Resilience Act betrifft jedes digitale Produkt, das die Möglichkeit hat, mit einem anderen Gerät oder Netz zu interagieren, also nicht erst wenn es tatsächlich verbunden ist, sondern sobald diese Fähigkeit besteht.
• Wer frühzeitig externe Consultants und CISOs einbindet, sichert sich günstigere Konditionen, denn steigende Nachfrage durch viele betroffene Unternehmen treibt die Marktpreise für Security-Experten nach oben.
• Maschinenbauer, die Remote-Support, Cloud-Anbindung oder Over-the-Air-Updates einsetzen, sind vom CRA genauso betroffen wie reine Softwareunternehmen, weil die Konnektivität der Maschine den Ausschlag gibt.
• Das größte Hindernis bei der CRA-Umsetzung liegt nicht im Entwicklungsteam, das das Thema trägt, sondern im Management, das keine Mehrkosten akzeptiert, obwohl eine fehlende CE-Konformitätserklärung den Verkauf im europäischen Markt blockiert.
• Ein gepflegter Security-Backlog mit bekannten Schwachstellen hilft beim Einstieg ins Cyber Risk Assessment, weil das Team sofort beurteilen kann, welche Schwachstellen bei einer gemeldeten Vulnerability tatsächlich relevant sind.

Wen der Cyber Resilience Act betrifft

Der Cyber Resilience Act betrifft jedes digitale Produkt, das mit einem anderen Gerät oder einem Netzwerk interagieren kann. Entscheidend ist nicht, ob ein Produkt tatsächlich kommuniziert, sondern ob es die Möglichkeit dazu hat.

Damit fällt fast alles unter die Verordnung, was Software enthält: von der smarten Kaffeemaschine über die Waschmaschine mit App bis zur vernetzten Industriemaschine. Eine Holzbearbeitungsmaschine, die am Kundennetzwerk oder am Internet hängt, gehört genauso dazu wie ein Bluetooth-Messschieber oder ein Barcode-Scanner mit Wireless-Verbindung.

Es gibt Ausnahmen, doch sie sind enger, als sie wirken. Reine Web-Services und Websites, die nicht in eine App eingebettet sind, bleiben außen vor. Open Source ist teilweise ausgenommen. Sobald du Open-Source-Software aber in deinem Unternehmen einsetzt, trägst du wieder Verantwortung dafür. Auch hier sind langfristig Änderungen zu erwarten.

Warum Konnektivität den Maschinenbau zum Software-Thema macht

Sobald eine Maschine ans Netz geht, wird Security zur Pflicht. Das gilt selbst dort, wo Software lange als Randerscheinung galt.

Im klassischen Maschinenbau war Software oft das notwendige Übel. Genau das verschiebt sich. Vernetzte Maschinen, Cloud-Datenerhebung und Remote-Support verändern das Bild grundlegend. Bei manchen Maschinen läuft der Support inzwischen ausschließlich über Remote-Lösungen, niemand muss mehr hinfahren. Das spart Aufwand, bedeutet aber: Die Maschine steckt dauerhaft am Internet.

Aus dieser dauerhaften Verbindung folgen konkrete Angriffsflächen. Betriebssystem, Firewall, Antivirus-Software, all das muss mitgedacht werden. Christoph Ranalter, in einem Tiroler Maschinenbauunternehmen für Qualität zuständig, beschreibt die Triebfeder nüchtern über die Bequemlichkeit der Nutzer:

Warum kann ich meinen Kühlschrank fern bedienen? Das ist eine Bequemlichkeit. Und genauso ist es bei uns dann auch bei den Maschinen.

Für den kleinen Tischler steckt der Nutzen weniger in der Produktivität als in der Information: sehen, wie weit die Maschine ist, mitbekommen, dass Material ausgeht, und beides auf dem Weg zur Maschine schon einplanen.

Wie du herausfindest, ob dich die Verordnung betrifft

Der erste Schritt ist ein Screening, idealerweise mit einer Beratung an der Seite. Bei Gesetzgebung und einem späteren Self-Assessment oder Audit muss die Einordnung sitzen.

Das Screening beantwortet zwei Fragen: Trifft uns die Verordnung? Und wie viel Zeit haben wir? Bei einem Hersteller vernetzter Maschinen fällt die erste Antwort fast immer auf “ja”. Die zweite Antwort hat sich im Verlauf des Gesetzgebungsprozesses verschoben. Ursprünglich standen nach Verabschiedung zwölf Monate im Raum, um das Incident-Response-Team zu bilden und die Meldepflicht gegenüber der ENISA zu erfüllen. In der verabschiedeten Verordnung sind daraus 21 Monate geworden: Der Cyber Resilience Act ist seit Dezember 2024 in Kraft, die Meldepflichten gelten ab September 2026, die übrigen Pflichten ab Dezember 2027.

Mehr Zeit heißt aber nicht weniger Druck. Viele Unternehmen werden gleichzeitig Maßnahmen setzen, und die Zahl der Security-Experten am Markt ist begrenzt. Wer früh mit Partnern und externer Unterstützung klärt, sichert sich Kapazität, bevor steigende Nachfrage die Tagessätze nach oben treibt.

CRA und NIS2 kommen oft im Doppelpack

Wer sich mit dem Cyber Resilience Act beschäftigt, stößt schnell auf NIS2. Beide Themen tauchen häufig parallel auf, auch in Unternehmen, die sich zunächst nicht betroffen wähnen.

Der gängige Reflex lautet: Wir sind keine kritische Infrastruktur, also betrifft uns NIS2 nicht. Die Erweiterung auf “wichtige” beziehungsweise notwendige Einrichtungen zieht den Kreis aber weiter. Verarbeitendes Gewerbe fällt breit darunter. Selbst Lieferbeziehungen können relevant werden: Liefert ein Betrieb an ein Krankenhaus und arbeitet dort softwareseitig zusammen, kann NIS2 greifen.

In der Praxis lassen sich beide Themen bündeln. Ein externer CISO als Service kann zunächst NIS2 vorantreiben und dieselbe Person zugleich die CRA-Beratung übernehmen.

So sieht eine pragmatische Roadmap aus

Eine sinnvolle Reihenfolge beginnt beim Training und führt über das Cyber-Risk-Assessment zum Incident-Response-Team. Diese Abfolge hat einen klaren Grund.

Erst wenn das Risk-Assessment für alle Maschinen steht, lässt sich eine gemeldete Schwachstelle überhaupt bewerten. Ohne diese Grundlage kannst du nicht beurteilen, ob eine Vulnerability dringend ist oder ignoriert werden kann.

Die grobe Staffelung sieht so aus:

Beim Incident-Response-Team stellt sich die Personalfrage: neue Kräfte holen oder bestehende ausbilden. Da gute Security-Experten am Markt rar und teuer sind, läuft es oft auf interne Ausbildung hinaus. Der Preis dafür ist Tempo. Wer Entwickler in Trainings und neue Aufgaben steckt, verliert spürbar Geschwindigkeit bei Features.

Das Mindset der Entwickler ist meist schon da

Die größere Hürde sitzt selten im Entwicklungsteam, sondern im Management. Bei den Entwicklern stößt Security oft auf Zustimmung statt Widerstand.

Viele bringen Vorerfahrung und Vorbildung aus dem Studium mit. Aussagen wie “hartcodierte Passwörter sind uncool” sind kein neuer Lernstoff, sondern bereits akzeptierte Haltung. Was fehlt, ist die Routine: Ein Risk-Assessment hat in solchen Teams meist noch niemand selbst durchgeführt. Das Mindset stimmt, der Prozess muss sich erst verfestigen.

Im Management dreht sich die Diskussion ums Geld. Mehr Aufwand bei gleichem Maschinenpreis ist unbeliebt. Hier hilft eine ehrliche Rechnung: Ohne CRA-Konformität lassen sich erste Maschinen womöglich nicht verkaufen, weil sie an Förderrichtlinien hängen, die diese Norm voraussetzen. Weil am Ende eine CE-Konformitätserklärung steht, geht es im Extremfall um den gesamten europäischen Markt.

Security-Backlog statt Feueralarm

Sinnvoller als auf den ersten Penetrationstest zu warten ist ein laufender Security-Backlog. Dort landen Schwachstellen, die während der Entwicklung auffallen, samt der Frage nach dem erwarteten Schaden.

Ein Beispiel ist die Inter-Process Communication zwischen der PC-Software und der Maschinensteuerung. Diese Kommunikation sollte verschlüsselt sein, um die Integrität zu sichern. Die Konsequenz einer fehlenden Verschlüsselung, etwa eine Man-in-the-Middle-Attacke, ist technisch denkbar, beim Endkunden aber unwahrscheinlich. Ein Angreifer müsste erst Zugang erlangen und dann viel Zeit investieren.

Genau diese Risikobewertung ist der Punkt. Ein Backlog hält solche Themen sichtbar, ohne dass jede theoretische Schwachstelle sofort einen Sprint sprengt. Wenn die Verordnung den Aufwand erzwingt, lässt sich der Backlog gezielt abarbeiten, mit der nötigen zusätzlichen Zeit.

Welche Tools beim sicheren Entwickeln helfen

Statische Code-Analyse ist ein realistischer Einstieg, weil viele Hersteller solcher Tools inzwischen Security-Guidelines integrieren. Die Tendenz geht klar dahin, diese Prüfungen weiter auszubauen.

Daneben gibt es Werkzeuge, die direkt in der IDE warnen, etwa wenn ein verwendetes Package eine Vulnerability hat, und gleich auf die fixende Version verweisen. Solche Tools setzen früh an, schon beim Programmieren.

Ein Vorbehalt bleibt: Nicht jedes Werkzeug deckt jede Umgebung ab. In einem Haus mit großer Windows- und großer Linux-Welt funktionieren manche Tools nur für eine Seite. Wer mehrere Plattformen bedient, sollte die Abdeckung vor der Auswahl prüfen, statt sich vom Funktionsumfang blenden zu lassen.

Software wird zum Unterscheidungsmerkmal

Im Maschinenbau verschiebt sich der Wettbewerb von der Mechanik zur Software. Blechschweißen beherrschen viele Anbieter, auch im Niedrigpreissegment. Über den Preis lässt sich an einem Hochpreisstandort wie Tirol nicht gewinnen.

Bleiben Qualität und Innovation. Und ein Großteil neuer Features ist heute entweder direkt Software oder braucht Software, um zu funktionieren. Damit steigt auch die Wertschätzung für das Software-Thema in Branchen, in denen es lange nebensächlich war.

Der Rat an alle, die mit dem Thema in Berührung kommen, ist deshalb unmissverständlich: Beschäftige dich frühzeitig damit, denn es kommt ohnehin. Ob der CRA ähnlich wie die DSGVO mit der Zeit an Aufregung verliert, ist offen. Die Cyber-Schäden tun das nicht, und mit besseren Werkzeugen werden auch Angreifer leistungsfähiger.

Häufig gestellte Fragen

Fällt eine Maschine schon unter den Cyber Resilience Act, wenn ihre Netzwerkfunktion gar nicht genutzt wird?

Ja. Maßgeblich ist die Möglichkeit, mit einem anderen Gerät oder einem Netz zu interagieren, nicht die tatsächliche Verbindung. Damit fällt fast alles unter die Verordnung, was Software enthält: die vernetzte Industriemaschine ebenso wie ein Bluetooth-Messschieber oder ein Barcode-Scanner mit Wireless-Verbindung. Für Maschinenbauer genügt bereits Remote-Support oder eine Cloud-Anbindung, um die Pflichten auszulösen.

Welche digitalen Produkte sind vom Cyber Resilience Act ausgenommen?

Die Ausnahmen sind enger, als sie wirken. Reine Web-Services und Websites, die nicht in eine App eingebettet sind, bleiben außen vor. Open Source ist teilweise ausgenommen, doch wer Open-Source-Software im eigenen Unternehmen einsetzt, trägt dafür wieder Verantwortung. Langfristig sind an diesen Abgrenzungen Änderungen zu erwarten, eine dauerhafte Entlastung sollte niemand einplanen.

Wie viel Zeit bleibt Unternehmen für den Aufbau eines Incident-Response-Teams?

Ursprünglich standen zwölf Monate nach Verabschiedung im Raum, um das Incident-Response-Team zu bilden und die Meldepflicht gegenüber der ENISA zu erfüllen. In der verabschiedeten Verordnung sind daraus 21 Monate geworden, die Meldepflichten gelten ab September 2026. Weniger Druck bedeutet das nicht: Viele betroffene Unternehmen setzen gleichzeitig Maßnahmen um, und die Zahl verfügbarer Security-Experten am Markt ist begrenzt.

Betrifft NIS2 auch Betriebe, die keine kritische Infrastruktur sind?

Häufig ja. Der Reflex, sich mangels kritischer Infrastruktur nicht betroffen zu fühlen, greift zu kurz, weil die Erweiterung auf wichtige beziehungsweise notwendige Einrichtungen den Kreis deutlich weiter zieht. Verarbeitendes Gewerbe fällt breit darunter. Auch Lieferbeziehungen können relevant werden: Wer an ein Krankenhaus liefert und dort softwareseitig zusammenarbeitet, kann unter NIS2 fallen.

In welcher Reihenfolge sollten die CRA-Maßnahmen angegangen werden?

Sinnvoll ist der Start mit Training für Entwickler und Softwarearchitekten, danach das Cyber-Risk-Assessment für alle Maschinen, im Folgejahr der Aufbau des Incident-Response-Teams. Der Grund für diese Abfolge: Erst wenn das Risk-Assessment steht, lässt sich eine gemeldete Schwachstelle überhaupt bewerten. Ohne diese Grundlage bleibt offen, ob eine Vulnerability dringend ist oder ignoriert werden kann.

Woran scheitert die Umsetzung von Security-Anforderungen in Unternehmen meistens?

Selten am Entwicklungsteam, meist am Management. Entwickler bringen Vorbildung mit, hartcodierte Passwörter gelten dort längst als inakzeptabel; was fehlt, ist die Routine, denn ein Risk-Assessment hat oft noch niemand selbst durchgeführt. Im Management dreht sich die Diskussion um Mehraufwand bei gleichem Maschinenpreis. Dagegen steht: Ohne CE-Konformitätserklärung ist im Extremfall der gesamte europäische Markt blockiert.

Was bringt ein laufender Security-Backlog gegenüber einem Penetrationstest?

Der Backlog hält Schwachstellen sichtbar, die während der Entwicklung auffallen, jeweils mit der Frage nach dem erwarteten Schaden. Beispiel: unverschlüsselte Inter-Process Communication zwischen PC-Software und Maschinensteuerung. Eine Man-in-the-Middle-Attacke ist technisch denkbar, beim Endkunden aber unwahrscheinlich, weil ein Angreifer erst Zugang braucht und viel Zeit investieren muss. So sprengt nicht jede theoretische Lücke einen Sprint.

Welche Werkzeuge helfen beim sicheren Entwickeln, und wo stoßen sie an Grenzen?

Statische Code-Analyse ist ein realistischer Einstieg, weil viele Hersteller solcher Tools Security-Guidelines integriert haben. Daneben gibt es Werkzeuge, die direkt in der IDE warnen, wenn ein verwendetes Package eine Vulnerability hat, und gleich die fixende Version nennen. Die Grenze liegt in der Abdeckung: In Häusern mit großer Windows- und großer Linux-Welt funktionieren manche Tools nur für eine Seite.