CRA für Maschinenhersteller nach den Leitlinien der Kommission vom 27. Juli 2026. Was muss tatsächlich umgesetzt werden?

Über Jahre ließ sich die Cybersicherheit einer Maschine in drei Schritten beschreiben: Marken-SPS, VPN „weil man das eben so macht“ und das klassische „der Kunde sichert das Netzwerk ab“. Wenn dann noch jemand eine Firewall in den Schaltschrank eingebaut hat, galt das Thema oft als erledigt — zumindest so lange, bis jemand prüfen wollte, was bei einem echten Angriff passiert und nicht nur in einer Präsentation.

Nur: Cybersicherheit läuft nicht über PROFINET. Komponenten können Zertifikate, Erklärungen und „secure by design“ im Marketingprospekt haben, aber die Maschine als Ganzes kann trotzdem auf eine Weise vorhersehbar sein, die mit Sicherheit nichts zu tun hat. So wie ein Sicherheitsrelais ein System nicht sicher macht, wenn die Steuerungslogik seine Umgehung zulässt, löst auch ein „sicheres“ HMI nicht die Probleme der Architektur, Integration, Berechtigungen, Updates und dessen, was passiert, wenn jemand aufhört, um Erlaubnis zu fragen.

CRA (Cyber Resilience Act, Verordnung des Europäischen Parlaments und des Rates (EU) 2024/2847) ist kein Zusatz für die IT. Es ist eine Produktregulierung, die ohne Rückfrage bei der Automatisierungsabteilung in den Lebenszyklus der Maschine eingreift. Sie umfasst den Entwurf der Steuerung, die Risikobeurteilung, die Lieferkette, die Konfiguration, Updates sowie die Produktpflege noch lange nachdem das FAT unterzeichnet wurde und die Maschine die Halle verlassen hat. Und nein: Das Argument „wir hängen sie nicht ans Internet“ erledigt das Thema nicht. In der Praxis reichen schon ein Service-Laptop, ein USB-Stick, eine Fernwartung „nur kurz“ oder die Integration in ein Werksystem, damit die Grenze zwischen Isolation und Exposition verschwindet.

Die Leitlinien der Kommission vom 27. Juli 2026 haben die Verordnung selbst nicht geändert, den Interpretationsspielraum aber wirksam eingegrenzt, der es zuvor erlaubte, Cybersicherheit als optionale Schicht zu behandeln. Präzisiert wurden unter anderem die Produktgrenze, die Rolle der Fernverarbeitung, die Verantwortung für Änderungen nach der Lieferung sowie der Umstand, dass „nach dem FAT ist das nicht mehr unser Problem“ keine belastbare Annahme mehr ist.

Die wichtigste Änderung ist jedoch grundlegender: Ein Cyberangriff ist nicht mehr nur ein IT-Ereignis, sondern wird zu einem Szenario, das die funktionale Sicherheit der Maschine beeinflusst. Wenn eine unbefugte Programmänderung eine Achsbewegung auslösen, eine Verriegelung umgehen, Prozessparameter verändern oder zum Verlust von Sicherheitsfunktionen führen kann, sprechen wir nicht mehr von einem „Netzwerkvorfall“. Wir sprechen von einem potenziell unkontrollierten Verhalten der Maschine — unabhängig davon, ob die Ursache ein Konfigurationsfehler, eine Software-Schwachstelle oder ein gezielter Eingriff war.

In diesem Kontext ist ein einmaliger Penetrationstest vor dem FAT kein Nachweis der Konformität mehr, sondern nur noch eine Momentaufnahme des Systemzustands zu einem bestimmten Zeitpunkt. CRA erfordert einen kontinuierlichen Ansatz: vom Entwurf über Produktion und Inbetriebnahme bis hin zu Updates, Schwachstellenmanagement, Reaktion auf Vorfälle und Instandhaltung über den erklärten Supportzeitraum.

In der Praxis bedeutet das eine Abkehr vom Denken „erledigt = sicher“ hin zu „aufrechterhalten = kontrolliert“. Ohne die Illusion, dass eine Firewall im Schaltschrank, ein VPN und das Zertifikat einer Komponente das Thema abschließen. Und ohne die Annahme, dass Cybersicherheit mit der Unterzeichnung des Abnahmeprotokolls endet.

In diesem Artikel zeigen wir, was die CRA-Leitlinien für Hersteller, Integratoren und Modernisierer von Maschinen tatsächlich ändern — ohne das ganze Thema auf die Parole „Passwort ändern und ein Cybersecurity-Kontrollkästchen hinzufügen“ zu reduzieren.

1. Damit eine Maschine nicht unter den CRA fällt, müsste sie fast nur aus Schützen bestehen

In vielen Projekten wird der Anwendungsbereich des CRA mit einer einzigen Frage geprüft:

Wird die Maschine mit dem Internet verbunden sein?

Nein.

Also ist das Thema erledigt.

Im Schaltplan stehen eine SPS, ein HMI, mehrere Antriebe, dezentrale Ein- und Ausgänge, eine Ventilinsel, ein Sicherheitsscanner sowie ein Port zum Aufspielen des Programms. Die Steuerung kommuniziert mit dem Panel über PROFINET, tauscht mit den Antrieben Steuer- und Statuswörter aus, und die Sensoren übertragen Daten über IO-Link.

Aber einen Router mit SIM-Karte gibt es nicht.

Wie allgemein bekannt, werden Daten erst dann zu Daten, wenn sie die Produktionshalle verlassen.

Nur fragt der CRA nicht, ob die Maschine Zugang zum Internet hat.

Er fragt, ob ihre Zweckbestimmung oder vernünftigerweise vorhersehbare Verwendung eine direkte oder indirekte, logische oder physische Datenverbindung mit einem Gerät oder Netzwerk umfasst. Das muss keine Verbindung zur Cloud, zu einem Server des Herstellers oder zum öffentlichen Internet sein. Sie kann über ein Kabel, per Funk, über eine Programmierschnittstelle oder als Teil eines größeren Systems bestehen.

Und jetzt die entscheidende Frage: Was in einer typischen Maschine überträgt tatsächlich Daten?

Liest das HMI Zustände aus der SPS aus und schreibt Sollwerte?

Sendet die SPS an den Antrieb ein Steuerwort und erhält im Gegenzug Geschwindigkeit, Status und Fehlercode?

Überträgt die Ein-/Ausgangsinsel das Prozessabbild?

Sendet der IO-Link-Sensor einen Messwert, eine Gerätekennung und Diagnosedaten?

Kommuniziert die Safety-SPS mit Modulen über PROFIsafe?

Werden Programm, Hardwarekonfiguration oder Firmware von einem Service-Laptop aufgespielt?

Lassen sich Rezepte, Berichte oder Updates per USB übertragen?

Wenn die Antwort auch nur einmal „ja“ lautet, liegt sehr wahrscheinlich eine Datenverbindung vor.

Und daran ändert auch die Tatsache nichts, dass:

• die Maschine arbeitet in einem lokalen Netzwerk,
• sie hat keine öffentliche IP-Adresse,
• der Ethernet-Port wird nur bei der Inbetriebnahme genutzt,
• ein Laptop wird ausschließlich vom Service angeschlossen,
• die Kommunikation findet nur innerhalb der Steuerung statt,
• der Kunde hat zugesagt, die Maschine niemals mit dem Internet zu verbinden.

Der CRA erfasst nicht nur die in der Anleitung als bestimmungsgemäß beschriebene Verwendung, sondern auch die vernünftigerweise vorhersehbare Verwendung. Ein Service-Port hört also nicht allein deshalb auf, Daten zu übertragen, weil im Schaltplan daneben „SERVICE ONLY” steht.

Die Leitlinien der Kommission vom 27. Juli 2026 führen jedoch eine wichtige Unterscheidung ein.

Nicht jede Leitung und nicht jedes elektrische Signal ist eine Datenverbindung.

Wenn ein Signal ausschließlich dazu dient, eine bestimmte Funktion ein- oder auszuschalten oder zu versorgen, und dabei keine digital codierte Information überträgt, reicht das bloße Vorhandensein von zwei elektrischen Zuständen noch nicht aus, um es als Datenverbindung einzustufen.

Ein Taster, der Spannung auf die Spule eines Schützes gibt, wird nicht schon deshalb zu einer digitalen Schnittstelle, weil sich sein Zustand als Null oder Eins beschreiben lässt.

Ebenso kann ein klassischer Endschalter, der in einen Relais-Schütz-Kreis eingebunden ist, lediglich den Stromkreis öffnen oder schließen. Er überträgt weder eine Gerätenummer noch einen Prozesswert, einen Diagnosecode, eine Firmware-Version oder ein Telegramm mit mehreren Informationen.

Wenn derselbe Zustand jedoch in ein intelligentes Gerät gelangt, dort codiert, über einen Bus übertragen, mit Diagnosedaten verknüpft und vom Empfänger als Information interpretiert wird, stellt sich die Lage anders dar.

Die Grenze verläuft also nicht zwischen einer „online” und einer „offline” betriebenen Maschine.

Sie verläuft zwischen einem einfachen Steuersignal und dem Austausch digital codierter Informationen.

Deshalb müsste eine Maschine, die allein wegen des Fehlens einer Datenverbindung außerhalb des CRA bleiben soll, in der Praxis eher einem klassischen Aufbau mit Tastern, Endschaltern, Relais und Schützen ähneln als einem modernen Projekt, das in TIA Portal geöffnet wird.

Das ist selbstverständlich keine gesetzliche Ausnahme für Schütze.

Man kann eine einfache Maschine mit SPS bauen, die nach eingehender Analyse das Kriterium des Anwendungsbereichs nicht erfüllt. Man kann aber auch einen digitalen Regler, eine Service-Schnittstelle oder ein Kommunikationsmodul zu einer Schützschaltung hinzufügen und sich damit genau auf der anderen Seite dieser Grenze wiederfinden.

Die Bezeichnung eines Bauteils entscheidet den Fall nicht.

Entscheidend ist, was das Produkt tatsächlich tut und womit es Daten austauscht.

Bevor man also die Frage beantwortet, ob eine bestimmte Maschine dem CRA unterliegt, muss geklärt werden:

• wo die Grenze des bewerteten Produkts verläuft,
• welche Geräte und Softwareelemente dazu gehören,
• über welche physischen und logischen Schnittstellen es verfügt,
• welche Informationen darüber übertragen werden,
• welche Verbindungen direkt sind und welche über ein größeres System laufen,
• welche davon im Normalbetrieb, bei der Inbetriebnahme, bei der Diagnose, bei Updates oder im Service auftreten,
• welche Nutzungsarten vernünftigerweise vorhersehbar sind, auch wenn der Hersteller sie lieber nicht vorhersehen würde.

Solange diese Fragen nicht beantwortet sind, wissen wir nicht, ob die Maschine außerhalb des CRA-Anwendungsbereichs bleibt.

Dann haben wir allenfalls einen bequemen Satz:

„Die Maschine ist nicht mit dem Internet verbunden.”

Nur ist das eine Antwort auf eine Frage, die der CRA gar nicht stellt.

PROFINET ist nicht das Internet. Für den CRA muss es das auch gar nicht sein.

2. Cybersicherheit verteilt sich nicht über PROFINET

In vielen Projekten beginnt das Thema Maschinenkonformität bereits in der Beschaffungsphase.

SPS von einem anerkannten Hersteller.
HMI mit aktueller Firmware.
Managebarer Switch.
Industrierouter mit VPN.
Antriebe mit Sicherheitsfunktionen.
Safety-SPS mit passendem Zertifikat.

Zu jedem Gerät gibt es eine Konformitätserklärung, eine Anleitung und mehrere Dokumente mit Schlagwörtern wie „secure”, „encrypted” und „defence in depth”.

Im Schaltplan sieht alles professionell aus.

Trotzdem ist damit noch nicht geklärt, ob die vollständige Maschine cyber­sicher ist.

Denn Cybersicherheit wird nicht über PROFINET „weitergereicht”.

Das ist ein wenig wie bei einem Türschloss:
Sie können in jedem Raum ein sehr gutes Schloss haben, zertifiziert, geprüft, mit hervorragender Dokumentation und einem „secure”-Hologramm versehen – und trotzdem ist das noch keine Garantie für Sicherheit, wenn jemand die Eingangstür weit offen gelassen hat, „weil es bei der Inbetriebnahme so schneller ging”.

Und genau so ist es auch hier: Die Komponenten können vorbildlich sein, und das System kann trotzdem … auf kreative Weise offen sein.

Die SPS „überträgt” Sicherheit nicht an das HMI.
Eine Firewall „repariert” nicht die Applikationslogik.
Ein Switch „ordnet” keine Benutzerzugriffe.
Und die Tatsache, dass jedes einzelne Element ein Zertifikat hat, bedeutet noch lange nicht, dass die gesamte Maschine nicht eine einzige große, höflich dokumentierte Schwachstelle ist.

PROFINET überträgt Daten.

Es überträgt keine Verantwortung.
Und leider überträgt es auch keinen gesunden Menschenverstand.

Der CRA erfasst sowohl vollständige Produkte als auch Komponenten, die separat in Verkehr gebracht werden. Das bedeutet, dass eine Steuerung, ein Bedienpanel oder ein Kommunikationsmodul gesondert bewertet werden können. Der Maschinenhersteller muss aber weiterhin nachweisen, dass das Gesamtsystem in der realen Konfiguration beim Kunden sicher funktioniert – also genau in der Version, bei der „ganz sicher niemand mehr etwas geändert hat … oder?”.

Und genau hier liegt der häufigste Fehler.

Das ist exakt derselbe Mechanismus, den wir aus der Risikobeurteilung nach DIN EN ISO 12100 seit Jahren kennen.

Der Lichtvorhang hat PL e.
Die Safety-PLC hat SIL 3.
Der Antrieb verfügt über STO.

Heißt das, dass die gesamte Maschine automatisch dieses Niveau erreicht?

Es ist wie beim Gerüstbau: Dass jedes einzelne Bauteil die Sicherheitsnormen erfüllt, garantiert noch nicht, dass die gesamte Konstruktion stabil ist.

Nein.

Denn es muss weiterhin geprüft werden, wie alles zusammenwirkt — also genau dieser wenig beliebte Schritt des „systemischen Denkens“, für den es leider keinen „Auto-Zertifizieren“-Knopf gibt.

In der Cybersicherheit ist es genau dasselbe.

Sie können „sichere“ Komponenten haben, aber in der Praxis gilt:

• Der Bediener sieht und verändert mehr Daten, als er tatsächlich benötigt, weil es „so bequemer war“,
• ein einziges Service-Passwort funktioniert auf allen Maschinen, weil „der Service ohnehin weiß, was er tut“,
• der Service-Port ist „für alle Fälle“ zugänglich — also wirklich für jeden Fall,
• der Fernzugriff umfasst das gesamte Netzwerk, weil irgendwann jemand sagte: „Das ist doch nur für die Diagnose“,
• Updates lassen sich ohne Kontrolle einspielen, weil „noch nie etwas schiefgegangen ist“,
• Geräte „vertrauen einander“ ohne Einschränkungen, weil Vertrauen billiger ist als Segmentierung,
• und die Integration setzt voraus, dass niemals jemand einen Fehler macht — was, wie die Geschichte zeigt, die wohl optimistischste Annahme im Engineering ist.

Jede einzelne Komponente kann für sich genommen korrekt sein.

Aber das System als Ganzes kann aus diesen korrekten Komponenten etwas bauen, das funktioniert … nur eben nicht unbedingt so, wie es vorgesehen war.

Und genau das ist entscheidend: Das Risiko steckt nicht in den Geräten selbst, sondern in ihrer Verbindung, ihrer Konfiguration und in dem legendären „nur vorübergehend offengelassenen“ Zugang.

Der CRA verlangt vom Maschinenhersteller mehr, als nur Erklärungen wie Trophäen zu sammeln. Er verlangt die Prüfung, ob das aus Komponenten zusammengesetzte Ergebnis als Ganzes weiterhin sicher ist — und nicht nur „in der Konformitätstabelle gut aussieht“.

In der Praxis bedeutet das einfache, geschäftsrelevante Fragen:

• hat jeder Benutzer nur genau den Zugriff, den er tatsächlich braucht, und nicht „weil es irgendwann vielleicht nützlich sein könnte“,
• ist der Fernzugriff auf das Minimum begrenzt oder eher auf das Maximum an Komfort ausgelegt,
• hat der Service nicht „überall Vollzugriff“, weil jemand meinte, das mache das Leben einfacher,
• ist das Netzwerk nicht eine einzige gemeinsame Fläche, weil Segmentierung „das Projekt kompliziert“,
• sind Updates kontrolliert oder eher nach dem Prinzip „einspielen und hoffen“,
• lässt sich schnell erkennen, welche Maschinen betroffen sind, oder heißt es eher „das prüfen wir nach dem Vorfall“,
• öffnet der Ausfall eines einzelnen Elements nicht gleich das gesamte System, weil „es sich in der Integration eben so ergeben hat“.

Das sind keine technischen Fragen „für Ingenieure für die schwierigen Dinge“.

Das sind Fragen des Geschäftsrisikos: Stillstände, Kosten, Verantwortung und dieses kleine Detail, dass die Produktion schließlich laufen muss.

Deshalb reicht es nicht zu sagen:

„alle Komponenten sind konform“

Denn das beantwortet noch immer nicht die Frage:

Ist die gesamte Maschine im realen Einsatz sicher — oder nur in der PowerPoint aus dem Projekt-Review?

Die Erklärung des Lieferanten ist wichtig.

Sie bezieht sich jedoch nur auf ein einzelnes Element — nämlich auf das, das gerade unter Laborbedingungen geprüft wurde, und nicht in einer Umgebung „irgendwo in der Halle, mit VPN, USB und Zeitdruck“.

Sie umfasst nicht, wie es eingesetzt wurde.
Sie umfasst nicht die Konfiguration.
Sie umfasst nicht die Integration.
Sie umfasst nicht die Entscheidungen, die „schnell während der Inbetriebnahme getroffen wurden, weil der Kunde wartete“.
Sie umfasst nicht, was nach Jahren des Betriebs passiert, wenn sich niemand mehr daran erinnert, warum etwas „vorübergehend offen“ war.

Deshalb darf die Bewertung nicht bei einer Geräteliste enden.

Man muss das System als Ganzes betrachten:

• wer Zugriff hat und warum (und nicht „weil er ihn schon immer hatte“),
• was wirklich erforderlich ist und was nur „drin geblieben ist, weil es nicht gestört hat“,
• wo Daten außerhalb der Kontrolle abfließen können, weil jemand meinte, „das ist doch nur Diagnose“,
• was passiert, wenn jemand einen legitimen Zugriff auf unzulässige Weise nutzt (also genau so, wie Angriffe es tun),
• wie schnell reagiert werden kann, wenn ein Problem auftritt — und nicht erst „nach der vierteljährlichen Überprüfung“.

Solange es auf diese Fragen keine Antworten gibt, haben wir nur einen Satz sehr ordentlicher Komponenten.

Eine sichere Maschine haben wir dann noch nicht.

Die Konformität von Komponenten erzeugt nicht automatisch die Konformität des Systems. Die Konformität der Maschine muss geplant, geprüft und — am schwierigsten — trotz der Versuchung aufrechterhalten werden, „nichts mehr anzufassen, weil es funktioniert“.

3. Ergänzen Sie die Gefährdungsliste nicht einfach um einen Cyberangriff. Verbinden Sie beide Analysen an der richtigen Stelle

Im Maschinenmarkt ist eine formale Cybersicherheits-Risikobeurteilung nach wie vor eher die Ausnahme als ein Standardbestandteil des Projekts.

Meist gibt es einen Industrierouter.

Es gibt ein VPN.

Es gibt ein Passwort für die PLC.

Manchmal gibt es einen managebaren Switch, den später niemand mehr verwaltet.

In der ambitionierteren Variante erhält der Hersteller vom Lieferanten eine Präsentation über „defence in depth“ und kommt zu dem Schluss, damit sei die Cybersicherheits-Risikoanalyse der gesamten Maschine abgeschlossen.

Ist sie nicht.

Er hat ein paar technische Maßnahmen gekauft.

Das ist noch keine Analyse.

Deshalb ergibt es keinen Sinn, das Problem so zu beschreiben, als würden in jedem Projekt zwei professionelle Bewertungen entstehen — eine nach ISO 12100, die andere zur Cybersicherheit — die nur zufällig nicht miteinander verknüpft wurden.

Meist entsteht nur eine.

Risikobeurteilung der Maschine.

Und eine Cybersecurity-Analyse des Produkts entsteht gar nicht erst.

Eine Risikobeurteilung der Maschine nach ISO 12100 besteht nicht darin, in eine Tabelle einfach Folgendes einzutragen:

Ausfall eines Sensors → unerwartete Bewegung → Quetschung.

Das kann ein Ausschnitt eines konkreten Szenarios sein, aber nicht der Ausgangspunkt.

Zunächst müssen die Grenzen der Maschine festgelegt werden.

Wofür ist sie bestimmt?

Welche Lebensphasen gibt es?

Wer wird sie benutzen?

Welche Tätigkeiten werden beim Transport, bei der Montage, Inbetriebnahme, Produktion, Einstellung, Reinigung, Beseitigung von Störungen, Wartung, Diagnose und Demontage ausgeführt?

In welchen Betriebsarten kann die Maschine arbeiten?

Wo befindet sich der Mensch bei jeder dieser Tätigkeiten?

Welche Teile der Maschine stehen dabei weiterhin unter Spannung, Druck oder Last oder bleiben in Bewegung?

Welche Verwendung entspricht zwar nicht der Betriebsanleitung, ist aber dennoch vernünftigerweise vorhersehbar?

Erst danach werden für die konkrete Aufgabe oder Tätigkeit unter anderem folgende Punkte identifiziert:

• die Gefährdungsquelle,
• die Art der Gefährdung,
• der Gefährdungsbereich,
• die exponierte Person,
• die Gefährdungssituation,
• das gefährliche Ereignis, sofern es im jeweiligen Szenario auftritt,
• mögliche Folgen und die Art des Schadens.

So sieht eine Risikobeurteilung der Maschine aus.

Wir beginnen nicht beim Bauteil.

Wir beginnen beim Menschen, der an einer Maschine in einem bestimmten Zustand eine konkrete Aufgabe ausführt. Genau diese Methodik zur Identifizierung von Gefährdungen sowie zur Risikoschätzung und Risikobewertung in den jeweiligen Lebensphasen der Maschine legt ISO 12100 fest.

Nehmen wir ein einfaches Beispiel.

Ein Bediener entfernt ein verklemmtes Teil aus dem Inneren einer Palettierzelle.

Wir haben also:

Aufgabe: Beseitigung einer Störung.

Nutzungsphase: Betrieb, Eingriff nach dem Stillstand des Prozesses.

Betriebsart: manuell oder Servicebetrieb.

Exponierte Person: Bediener oder Mitarbeiter der Instandhaltung.

Gefährdungsbereich: Innenraum der Zelle, insbesondere der Bereich zwischen Greifer, Werkstück und Maschinenkonstruktion.

Gefährdungsquelle: mechanische Energie des Roboters, der Linearachse oder des pneumatischen Greifers.

Gefährdungssituation: Eine Person befindet sich im Gefährdungsbereich, während eine Bewegung weiterhin möglich ist.

Gefährliches Ereignis: unerwartete Bewegung einer Achse, Schließen des Greifers oder Freisetzung gespeicherter Energie.

Mögliche Folge: Anprall, Quetschung, Fraktur oder Amputation.

Erst jetzt kann das Risiko bewertet und können Maßnahmen zu seiner Minderung festgelegt werden.

Möglicherweise ist eine Verriegelung der Schutzeinrichtung erforderlich.

Möglicherweise ist ein sicherer Halt erforderlich.

Es kann notwendig sein, ein unerwartetes Anlaufen zu verhindern.

Unter Umständen muss pneumatische Energie abgebaut werden.

Unter Umständen darf eine Bewegung im Handbetrieb nur mit Zustimmeinrichtung und sicher begrenzter Geschwindigkeit erfolgen.

Das ist nach wie vor eine klassische Risikobeurteilung der Maschine.

Wo kommt Cybersecurity ins Spiel?

Nicht als neuer Eintrag neben mechanischer, elektrischer und thermischer Gefährdung.

„Hacker“ ist keine Quelle mechanischer Gefährdung

Wenn man in die ISO-12100-Tabelle einfach den Eintrag ergänzt:

Gefährdung: Cyberangriff

bringt das nur wenig.

Ein Cyberangriff ist weder eine rotierende Welle noch eine scharfe Kante, hohe Temperatur oder pneumatische Energie.

Er ist auch kein eigener Gefährdungsbereich.

Der Bediener erleidet keine Quetschung durch eine CVE-Schwachstelle.

Er erleidet sie durch ein Maschinenelement, das eine Bewegung ausgeführt hat, während sich der Mensch am falschen Ort befand.

Ein Cyberangriff kann jedoch den Zustand des Steuerungssystems, Daten, das Programm, die Konfiguration oder die Wirkungsweise einer Schutzmaßnahme verändern.

Er kann also werden zu:

• einer Ursache eines gefährlichen Ereignisses,
• einem zusätzlichen Weg, der zu einer Gefährdungssituation führt,
• einer Ursache für den Verlust der Wirksamkeit einer Maßnahme zur Risikominderung,
• oder einer Möglichkeit, die bei der Auslegung der Sicherheitsfunktion getroffenen Annahmen zu umgehen.

Genau dort liegt die richtige Schnittstelle.

Nicht in der Gefährdungsliste.

Sondern im Verhalten der Maschine.

Die Cybersecurity-Analyse sollte separat erstellt werden

Für eine Maschine oder ein Automatisierungssystem hat die Cybersecurity-Analyse eine andere Struktur als die Risikobeurteilung nach ISO 12100.

Die naheliegendste Struktur für ein industrielles Automatisierungssystem liefert IEC 62443-3-2.

Die Norm verlangt unter anderem:

• die Definition des zu analysierenden Systems, also des SUC,
• die Aufteilung des Systems in Zonen und Kommunikationskanäle,
• die Risikobewertung für die einzelnen Zonen und Kanäle,
• die Festlegung der Ziel-Sicherheitsniveaus SL-T,
• die Dokumentation der Sicherheitsanforderungen.

Das ist ein völlig anderer Ausgangspunkt als in ISO 12100.

In IEC 62443 fragen wir unter anderem:

Was gehört genau zu dem analysierten System?

Welche Assets müssen geschützt werden?

Welche Geräte, Anwendungen und Schnittstellen befinden sich im System?

Welche Elemente sollten derselben Zone zugeordnet werden?

Wie verläuft die Kommunikation zwischen den Zonen?

Wer kann Zugriff erhalten?

Von welchem Ort aus?

Über welche Schnittstelle?

Welche Schwachstellen können ausgenutzt werden?

Welche Daten, Funktionen oder Komponenten können verändert werden?

Über welchen Pfad kann ein Angreifer vom Servicerouter zum PLC, HMI, Antrieb oder zur Engineering-Station gelangen?

Welche Folgen hat der Verlust von Vertraulichkeit, Integrität oder Verfügbarkeit?

Welche Schutzmaßnahmen sind erforderlich?

Für den sicheren Produktentwicklungsprozess und die Anforderungen an die Komponenten selbst sind auch andere Teile der Reihe relevant, insbesondere IEC 62443-4-1 und IEC 62443-4-2. IEC 62443-3-3 strukturiert dagegen die technischen Sicherheitsanforderungen auf Systemebene.

Der CRA verpflichtet den Hersteller heute nicht dazu, auf den Umschlag der Analyse zu schreiben: „erstellt gemäß IEC 62443“.

IEC 62443 ersetzt auch nicht den Nachweis der Konformität mit den Anforderungen des CRA.

Für ein industrielles Automatisierungssystem ist sie jedoch ein deutlich sinnvollerer Bezugspunkt, als zu versuchen, einige Hacking-Szenarien in eine ISO-12100-Tabelle hineinzuschreiben.

Denn beide Methoden beantworten unterschiedliche Fragen.

ISO 12100:

Bei welcher Aufgabe, an welchem Ort, ausgehend von welcher Quelle und infolge welches Ereignisses kann ein Mensch zu Schaden kommen?

IEC 62443:

Wer kann über welchen Weg und unter Ausnutzung welcher Schwachstelle Einfluss auf das System, seine Daten oder seine Funktionen nehmen?

Erst danach ist zu prüfen, ob die Antwort aus der zweiten Analyse das Szenario aus der ersten verändert.

Dasselbe Szenario, zwei unterschiedliche Analysen

Kehren wir zum Bediener zurück, der ein verklemmtes Teil entfernt.

Die Analyse nach ISO 12100 hat gezeigt, dass sich die Person in einen Bereich begibt, in dem sie durch die Bewegung des Roboters oder Greifers gequetscht werden kann.

Die Maßnahme zur Risikominderung ist eine verriegelte Schutzeinrichtung, eine sichere Stoppfunktion sowie ein lokaler Reset außerhalb des Gefahrenbereichs.

Nun führen wir die Cybersicherheitsanalyse des Systems durch.

Wir identifizieren:

• den für den Fernservice verwendeten Router,
• das Servicekonto,
• den Engineering-Laptop,
• das HMI,
• das Standard-PLC,
• das Safety-PLC,
• die Antriebe,
• die Programmierschnittstelle,
• das PROFINET-Netzwerk und die PROFIsafe-Kommunikation,
• die Mechanismen zum Aufspielen des Programms und der Konfiguration.

Wir betrachten folgendes Szenario:

Die Übernahme des Servicekontos ermöglicht den Fernzugriff auf das Standard-PLC und das Senden eines Fahrbefehls, während sich eine Person in der Zelle befindet.

Führt dieses Szenario zu einem gefährlichen Ereignis?

Das lässt sich nicht allein aus der Tatsache ableiten, dass das PLC übernommen wurde.

Dazu muss die Architektur der Sicherheitsfunktionen geprüft werden.

Wenn das Öffnen der Schutzeinrichtung durch das Safety-PLC überwacht wird, die Funktion das Drehmoment der Antriebe sicher abschaltet, der Reset ausschließlich lokal erfolgt und das Standard-PLC die Bewegung unabhängig vom Zustand der Sicherheitsfunktion nicht wieder freigeben kann, dann kann die Übernahme der Standardsteuerung die Produktion anhalten oder den Prozess beschädigen.

Sie sollte jedoch keine Bewegung bei geöffneter Schutzeinrichtung auslösen.

Dann weist die Cyberanalyse einen Angriff nach.

Die Risikobeurteilung der Maschine weist eine mechanische Gefährdung nach.

Eine korrekt ausgelegte Sicherheitsfunktion unterbricht jedoch den Weg zwischen beiden.

Und nun die zweite Variante.

Der Servicemodus wird über ein gewöhnliches HMI ausgewählt.

Der Wert der begrenzten Geschwindigkeit kommt aus dem Standard-PLC.

Der Remote-Service kann einen Reset ausführen.

Dasselbe Engineering-Konto ermöglicht Änderungen am Standardprogramm und an der Safety-Konfiguration.

Die Sicherungskopie des Safety-Programms ist keiner konkreten Maschinenversion zugeordnet.

Niemand prüft nach dem Eingriff die Prüfsumme.

Die Antriebsparameter können aus der Ferne geändert werden.

In dieser Architektur bedeutet die Übernahme des Kontos nicht mehr nur den Verlust von Vertraulichkeit oder einen kurzen Stillstand.

Sie kann die Bedingungen verändern, auf denen die Risikominderung beruhte.

Sie kann führen zu:

• der Auswahl des falschen Modus,
• der Änderung eines Parameters der sicheren Bewegung,
• einem unbefugten Reset,
• dem Aufspielen einer nicht freigegebenen Konfiguration
• oder der Schwächung einer Funktion, die ein unerwartetes Anlaufen verhindern sollte.

Dann muss das Cyber-Szenario mit einem konkreten Szenario der Maschinensicherheit verknüpft werden:

Aufgabe „Verklemmung beseitigen“ → Person im Gefahrenbereich → unbefugte Änderung der Steuerungsarchitektur oder der Schutzfunktion → unerwartete Bewegung → Quetschung.

Die Gefährdungsquelle hat sich nicht verändert.

Sie ist weiterhin die mechanische Energie der Maschine.

Der Gefahrenbereich hat sich nicht verändert.

Er befindet sich weiterhin innerhalb der Zelle.

Auch die mögliche Folge hat sich nicht verändert.

Es bleibt die Verletzung des Bedieners.

Verändert hat sich der Weg, der zum gefährlichen Ereignis führt.

Nicht jede Schwachstelle gehört in die ISO 12100

Diese Unterscheidung ist ebenso wichtig.

Nehmen wir an, eine Schwachstelle im HMI ermöglicht das Auslesen historischer Produktionsdaten.

Das kann aus Sicht des CRA ein relevantes Problem sein.

Sie kann die Vertraulichkeit der Daten verletzen.

Sie kann ein Update, eine Bewertung der Auswirkungen, Maßnahmen gegenüber den Nutzern und unter bestimmten Umständen auch eine Meldung erfordern.

Wenn sie jedoch das Verhalten der Maschine nicht beeinflusst, keine Schutzmaßnahme verändert und nicht zu einer Gefährdungssituation führen kann, ergibt es keinen Sinn, sie in die Risikobeurteilung nach ISO 12100 hineinzuzwingen.

Ebenso kann ein Angriff, der ausschließlich die Verfügbarkeit von Produktionsberichten beeinträchtigt, ein geschäftliches Problem und ein Problem im Hinblick auf die CRA-Compliance darstellen.

Für den Bediener muss daraus jedoch kein Risiko entstehen.

Umgekehrt kann die auf den ersten Blick harmlose Möglichkeit, einen einzelnen Sollwert zu verändern, für die Vertraulichkeit von Daten nur geringe Bedeutung haben, für die physische Sicherheit jedoch von enormer Tragweite sein.

Zum Beispiel dann, wenn dieser Wert Folgendes festlegt:

• die maximale Achsgeschwindigkeit,
• die Anpresskraft,
• die Prozesstemperatur,
• den Druck,
• die Stopp-Position,
• die Öffnungszeit eines Ventils
• oder den zulässigen Grenzwert beim Betrieb mit geöffneter Schutzeinrichtung.

Wir klassifizieren Cyberbedrohungen daher nicht danach, wie technisch sie klingen.

Entscheidend ist, was sie tatsächlich mit der Maschine bewirken können.

Die Maschinenverordnung erzwingt diese Brücke

Diese Verknüpfung ist nicht nur gute Ingenieurpraxis.

Punkt 1.2.1 des Anhangs III der Maschinenverordnung verlangt, dass Steuerungen so entworfen und gebaut werden, dass Gefahrensituationen verhindert werden, auch infolge vernünftigerweise vorhersehbarer böswilliger Handlungen Dritter.

Die CRA weist wiederum darauf hin, dass ihre grundlegenden Cybersicherheitsanforderungen unter anderem den Nachweis der Konformität mit den Anforderungen 1.1.9 und 1.2.1 der Maschinenverordnung unterstützen können.

Das geschieht jedoch nicht automatisch.

Der Hersteller muss diesen Zusammenhang auf Grundlage der Risikobeurteilung nachweisen. Die Konformitätsbewertung nach CRA und die Konformitätsbewertung nach der Maschinenverordnung bleiben weiterhin getrennte Prozesse.

Das heißt: Es reicht nicht aus,

• eine Risikobeurteilung nach ISO 12100 zu erstellen,
• eine Analyse nach IEC 62443 durchzuführen,
• zwei separate Berichte zu verfassen
• und darauf zu hoffen, dass die Ähnlichkeit der Normnummern zwischen ihnen einen Audit-Trail erzeugt.

Erforderlich ist eine Verknüpfung.

Für jedes wesentliche Cyber-Szenario ist festzulegen:

1. welches Element oder welche Funktion übernommen oder verändert werden kann,
2. welches Maschinenverhalten dadurch ausgelöst werden kann,
3. ob dieses Verhalten zu einer Gefahrensituation oder zu einem gefährlichen Ereignis führt,
4. welche Aufgabe und welcher Gefahrenbereich betroffen sind,
5. welche mögliche Folge in der ISO-12100-Bewertung benannt wurde,
6. welche Maßnahme zur Risikominderung die Entwicklung des Szenarios unterbrechen soll,
7. ob diese Maßnahme nach der Übernahme des angegriffenen Elements weiterhin wirksam bleibt.

Der letzte Punkt ist der wichtigste.

Denn wenn Angriff und Schutz abhängen von:

• derselben Steuerung,
• demselben Konto,
• demselben Netzwerk,
• derselben Engineering-Station
• oder demselben Programm,

dann haben wir möglicherweise keine zwei unabhängigen Schutzebenen.

Dann haben wir eine Schutzebene, die in zwei Dokumenten beschrieben ist.

Wir brauchen also keine riesige Tabelle mit dem Titel:

„Risikobeurteilung Safety & Cybersecurity“.

Wir brauchen zwei korrekte Analysen, die mit den jeweils passenden Methoden durchgeführt werden, sowie einen kontrollierten Berührungspunkt zwischen ihnen.

ISO 12100 soll Mensch, Aufgabe, Gefährdungsquelle, Bereich, Gefahrensituation, gefährliches Ereignis und möglichen Schaden beschreiben.

IEC 62443 soll dabei helfen, das System, seine Zonen, Kommunikationskanäle, Assets, Bedrohungen, Schwachstellen, Angriffspfade und erforderlichen Schutzmaßnahmen zu beschreiben.

Und der Hersteller muss nachweisen, ob ein Szenario aus der zweiten Analyse ein Szenario aus der ersten auslösen oder einer Maßnahme, die es stoppen sollte, ihre Wirksamkeit nehmen kann.

Ein Cyberangriff muss keine neue Gefährdung schaffen. Es reicht, wenn er einen neuen Weg zu einem alten Unfall eröffnet.

4. Ein Pentest vor dem FAT ist ein Foto. Die CRA verlangt einen Film

In vielen Projekten taucht Cybersicherheit erst zwei Wochen vor dem FAT auf.

Dann wird ein Pentest beauftragt.

Es entsteht ein Bericht.

Kritische Schwachstellen werden behoben, mittlere akzeptiert, und das Dokument landet im Projektordner.

Die Maschine ist cybersicher.

Bis zum nächsten Dienstag.

Ein Pentest kann ein sehr wertvoller Bestandteil der Verifikation sein. Er zeigt jedoch den Zustand einer konkreten Produktversion, in einer konkreten Konfiguration und unter Verwendung bestimmter Testszenarien.

Er beantwortet nicht die Frage, was der Hersteller später tun wird.

Die CRA betrifft jedoch den gesamten Produktlebenszyklus. Die Bewertung der Cybersicherheitsrisiken soll Planung, Entwurf, Entwicklung, Produktion, Lieferung und Instandhaltung des Produkts beeinflussen. Nach dem Inverkehrbringen muss der Hersteller Schwachstellen über den erklärten Supportzeitraum hinweg behandeln.

Kehren wir zur Gemüseverpackungsmaschine zurück.

Die Maschine hat den FAT bestanden.

Der Pentest hat keine kritischen Schwachstellen aufgezeigt.

Acht Monate später veröffentlicht der Hersteller des Service-Routers eine Information über eine Schwachstelle, die die Übernahme des Geräts ermöglicht.

Und jetzt beginnt die eigentliche Arbeit.

Welche ausgelieferten Maschinen haben dieses Routermodell?

Welche Firmware-Version wurde in jedem einzelnen Exemplar installiert?

Ist der Fernzugriff aktiv?

Kann die Schwachstelle in der realen Konfiguration ausgenutzt werden?

Ermöglicht die Übernahme des Routers ausschließlich den Zugriff auf die Diagnose oder auch auf HMI, PLC, Antriebe und Safety PLC?

Ist nur das Auslesen von Daten möglich oder auch die Änderung des Programms oder von Parametern?

Kann der Angriff eine Sicherheitsfunktion beeinflussen?

Hat der Lieferant einen Patch bereitgestellt?

Verändert das Router-Update Zertifikate, Kommunikationsregeln oder die Art, wie der Tunnel aufgebaut wird?

Muss nach einem Update der Fernservice, die Kommunikation und ein Teil der Sicherheitsfunktionen erneut geprüft werden?

Welche Kunden müssen informiert werden?

Und erfüllt die Situation die Kriterien für die Meldung einer aktiv ausgenutzten Schwachstelle oder eines schwerwiegenden Sicherheitsvorfalls?

Ein vor dem FAT durchgeführter Pentest beantwortet keine dieser Fragen.

Er beschreibt eine Maschine, die so nicht mehr existiert.

Denn seit der Prüfung haben sich Softwareversionen, Konfigurationen, die Einsatzumgebung und der Kenntnisstand zu Schwachstellen verändert.

Deshalb braucht der Hersteller nicht nur einen Test, sondern einen Prozess:

• zur Identifizierung der Hardware-, Firmware- und Softwareversionen in jedem ausgelieferten Exemplar,
• zur Überwachung von Informationen über Schwachstellen,
• zur Bewertung ihrer Ausnutzbarkeit in der tatsächlichen Architektur,
• zur Prüfung möglicher Auswirkungen auf den Prozess und die Sicherheit der Maschine,
• zur Vorbereitung und zum Testen von Updates,
• zur Information der Nutzer,
• zur Dokumentation der getroffenen Entscheidungen,
• zur Bearbeitung der erforderlichen Meldungen.

Ab dem 11. September 2026 sind Hersteller verpflichtet, aktiv ausgenutzte Schwachstellen sowie schwerwiegende Sicherheitsvorfälle zu melden, die die Sicherheit von Produkten mit digitalen Elementen beeinträchtigen. Eine erste Warnmeldung ist innerhalb von 24 Stunden zu übermitteln, die vollständige Meldung innerhalb von 72 Stunden.

Das bedeutet: Nach Entdeckung eines Problems bleibt keine Zeit mehr, erst dann mit der Suche zu beginnen:

„Wer hat diesen Router eigentlich gebaut, und wo haben wir die Liste der Maschinen, in die wir ihn eingebaut haben?“

Die Verordnung (EU) 2024/2847 – Cyberresilienzgesetz (CRA) zeigt sehr deutlich den Unterschied zwischen einer einmaligen Absicherung eines Produkts und einem sicheren Produktentwicklungszyklus. Sie umfasst nicht nur Entwicklung und Verifizierung, sondern auch das Management von Fehlern, Korrekturen und dem Produktlebensende.

Das FAT kann also eine Projektphase abschließen.

Den Produktlebenszyklus schließt es nicht ab.

Den Supportzeitraum beendet es nicht.

Die Überwachung von Schwachstellen endet dadurch nicht.

Und es bedeutet auch nicht, dass die Konfiguration vom Tag der Abnahme für die nächsten fünfzehn Jahre eingefroren bleibt.

Die Maschine kann über lange Zeit Gemüse für Supermärkte verpacken.

Der Hersteller kann ihre Cybersicherheit jedoch nicht zusammen mit der Anleitung verpacken, in Folie einschweißen und davon ausgehen, dass sie damit ein für alle Mal geliefert ist.

Ein Pentest kann einen Punkt auf der FAT-Liste abschließen. Der CRA eröffnet einen Prozess, der bis zum Ende des Supportzeitraums des Produkts andauert.