Risikobeurteilung der Cybersicherheit für Anlagen: was Maschinenverordnung und CRA daraus brauchen, mit STRIDE-Beispiel

Die Risikobeurteilung ist das vertrauteste Dokument im Maschinenbau. Für jede Maschine existiert eine nach EN ISO 12100, und die Systematik beherrscht jede Konstruktionsabteilung: Gefährdung ermitteln, Risiko bewerten, Maßnahme festlegen, Restrisiko begründen. Das Verfahren bleibt dasselbe. Hinzu kommt eine zweite Ursachenkategorie, der gezielte Eingriff, und zwei Verordnungen verlangen die Beurteilung dafür. Wie CRA und Maschinenverordnung zusammenspielen und was bis zu welchem Stichtag stehen muss, behandeln eigene Beiträge. Hier geht es um das Dokument selbst: Was braucht die Maschinenverordnung daraus, was braucht der CRA, und wie sieht die Beurteilung an einer konkreten Maschine aus?

Die Maschinenverordnung fragt nach der Gefährdung, der CRA nach der Absicherung

Die Maschinenverordnung (EU) 2023/1230 fragt: Kann ein Angriff Menschen gefährden? Anhang III verlangt Schutz gegen Korrumpierung (1.1.9): Die Verbindung mit anderen Geräten darf keine gefährliche Situation auslösen, sicherheitsrelevante Software und Daten müssen gegen Manipulation geschützt sein, und Eingriffe müssen nachweisbar sein. Dazu kommen Steuerungen, die auch böswilligen Beeinflussungsversuchen standhalten (1.2.1). Das ist die bekannte 12100-Logik, erweitert um den Angriff als Ursache einer Gefährdung.

Der CRA fragt breiter: Ist das Produkt seinen Risiken angemessen abgesichert? Das gilt auch dort, wo keine Safety-Folge droht: Rezepturdaten, die im Klartext ins Kundennetz gehen, ein Fernwartungszugang als Sprungbrett, ein Produktionsausfall durch gestörte Kommunikation. Art. 13 Abs. 2 und 3 verlangen, die Risiken zu beurteilen, das Ergebnis in Planung, Konstruktion, Entwicklung und Wartung einfließen zu lassen und die Beurteilung über den Unterstützungszeitraum aktuell zu halten; nach Art. 13 Abs. 4 gehört sie in die technische Dokumentation (Anhang VII). Die wesentlichen Anforderungen aus Anhang I gelten dabei ausdrücklich „auf der Grundlage der Risiken". Welche Anforderung wie umgesetzt oder begründet ausgeschlossen wird, entscheidet genau diese Beurteilung.

Der safety-relevante Teil ist eine Teilmenge des CRA-Blickwinkels. Die Kommission lässt ausdrücklich zu, dass ein Hersteller eine einzige Risikobeurteilung für mehrere Rechtsakte führt, solange er die Konformität mit jedem einzeln belegen kann (Kommissions-FAQ v1.4, Nr. 4.1.1). Praktisch heißt das: eine Bedrohungsanalyse je Anlagentyp, aus der beide Nachweise ausgeleitet werden. Die MVO-Seite wandert in die bestehende Risikobeurteilung der Maschine, die CRA-Seite in die technische Dokumentation. Zwei getrennte Dokumente von Grund auf zu schreiben verdoppelt die Arbeit und erzeugt Widersprüche.

Die Maschinenverordnung braucht den Safety-Ausschnitt der Analyse

Aus der Bedrohungsanalyse nimmt die Maschinenverordnung genau die Zeilen, die eine Sicherheitsfunktion erreichen oder eine Gefährdung auslösen können. Für die Risikobeurteilung nach EN ISO 12100 werden daraus vier Dinge gebraucht:

• die Liste der Schnittstellen, über die ein Eingriff die Steuerung erreicht,
• die Szenarien, in denen ein Eingriff eine Sicherheitsfunktion aushebelt oder eine Bewegung freigibt,
• die Maßnahmen, die sicherheitsrelevante Software und Daten gegen Manipulation schützen,
• der Nachweis, dass Eingriffe protokolliert werden (1.1.9).

Die Annahmen über die Einsatzumgebung, etwa ein vom Betreiber freigeschalteter Fernwartungszugang, gehören in die Betriebsanleitung, sonst sind sie im Prüffall nicht belegt. Für Maschinen, die ab dem 20. Januar 2027 in Verkehr gehen, muss die Beurteilung zu diesem Zeitpunkt vorliegen; wer dann liefert, führt sie im laufenden Auftragsbestand ein.

Die technische Konkretisierung liefert der Normentwurf prEN 50742 „Schutz gegen Korrumpierung", der als harmonisierte Norm zu 1.1.9 und 1.2.1 vorgesehen ist. Der Entwurf verlangt eine Cyber-Risikobeurteilung in drei Schritten (kritische Assets bestimmen, Bedrohungen analysieren, erforderliches Schutzniveau festlegen) und führt dafür vier sicherheitsbezogene Security-Level ein, SRSL 0 für vollständig isolierte Netze bis SRSL 3. Für Hersteller mit etablierten Industrial-Security-Prozessen sieht der Entwurf als Alternative den Weg über die IEC 62443 vor. Die Schlussabstimmung war für September 2026 angesetzt, die Veröffentlichung wird für Ende 2026 erwartet; bis zur Listung im Amtsblatt bleibt der Entwurf eine Orientierung ohne Konformitätsvermutung.

Der CRA braucht die Zuordnung jeder Zeile zu Anhang I und die Begründung der Restrisiken

Der CRA nimmt jede Zeile der Bedrohungsanalyse, auch die ohne Safety-Folge. Aus dem Dokument braucht er nach Art. 13 Abs. 3 und 4:

• die Aussage, welche Anforderungen aus Anhang I Teil I Nr. 2 für die Anlage gelten und wie sie umgesetzt sind,
• für jede Anforderung, die nicht zutrifft, eine Begründung (Kommissions-FAQ v1.4, Nr. 4.1.3),
• die Restrisiken mit Begründung,
• die Ablage in der technischen Dokumentation nach Anhang VII.

Für die Zeile „OPC UA unverschlüsselt" heißt das: Zuordnung zur Anforderung Vertraulichkeit in Anhang I Teil I Nr. 2, Maßnahme, Restrisiko.

Bei den Restrisiken legt die Kommission den Maßstab an. Nach den Leitlinien zu Art. 26 (C(2026) 5252, Rn. 157 bis 159) wird ein Restrisiko nicht am eigenen Risikoappetit gemessen, sondern daran, ob das Produkt für seine Zweckbestimmung angemessen abgesichert ist; Kostengründe rechtfertigen ein unbehandeltes Risiko nicht (Rn. 158 und 163). Die Betriebsanleitung darf Annahmen tragen, etwa den Betrieb nur in einer vertrauenswürdigen Umgebung oder hinter einem Netzübergang (Rn. 162); eine Lücke im Design ersetzt sie nicht, die Verantwortung bleibt beim Hersteller (Rn. 161). Dazu kommen der Unterstützungszeitraum, den die Analyse nach Art. 13 Abs. 8 berücksichtigt, und die Hinweise für den Betreiber nach Anhang II. Die Leitlinien sind nicht rechtsverbindlich, aber die Lesart, auf die sich eine Marktüberwachungsbehörde stützen wird.

Die Beurteilung entsteht je Anlagentyp, nicht je Auftrag

Der häufigste Einwand lautet: „Jede unserer Anlagen ist ein Unikat." Für die Cyber-Bedrohungslage stimmt das selten. Ob die Maschine Kartons faltet oder Flaschen füllt, die Angriffsfläche bestimmen Steuerungsplattform, Bedienebene, Fernwartungsweg und die Anbindung ans Kundennetz, und die wiederholen sich über das Portfolio. Die Kommission sieht das genauso: Für Produktvarianten mit gleicher Architektur, gleichem sicherheitsrelevanten Design und gleichen Risiken genügt eine Risikobeurteilung und eine technische Dokumentation; nur Unterschiede, die die Cybersicherheit berühren, etwa andere Schnittstellen oder ein anderer Fernzugang, müssen in der Beurteilung abgebildet werden (C(2026) 5252, Rn. 174 bis 176). Deshalb wird die Beurteilung je Anlagentyp oder Steuerungsplattform einmal erstellt. Im einzelnen Auftrag wird nur das Delta geprüft und festgehalten: zusätzliche Schnittstellen, die konkrete MES-Anbindung, abweichende Komponenten. Das hält den Aufwand je Projekt bei Stunden statt Tagen und ist zugleich die Form, die ein Prüfer erwartet: Basisbeurteilung plus projektspezifische Ergänzung.

STRIDE ist die übliche Methode für die Bedrohungsliste

Eine Methode schreibt keine der beiden Verordnungen vor. Die Kommissions-FAQ zum CRA (v1.4, Nr. 4.1.2) verlangt nur, dass die Bedrohungsmodellierung zur Zweckbestimmung des Produkts passt und die Behörde nachvollziehen kann, wie Risiken ermittelt, bewertet und behandelt wurden. Die Maschinenverordnung nennt keine Methode, und auch prEN 50742 fordert nur eine Bedrohungsanalyse. Am nächsten an einer Empfehlung ist die IEC 62443-4-1: Sie führt STRIDE im Abkürzungsverzeichnis und nutzt es in Abschnitt 9.3.2 als Beispiel dafür, wie die Wirksamkeit von Gegenmaßnahmen geprüft wird.

STRIDE sortiert Bedrohungen in sechs Kategorien: Spoofing (Vortäuschen einer Identität), Tampering (Manipulation), Repudiation (Abstreitbarkeit), Information Disclosure (Offenlegung), Denial of Service (Störung) und Elevation of Privilege (Rechteausweitung). Der Wert liegt in der Systematik: Die sechs Fragen werden je Schnittstelle gestellt, dort, wo Daten die Anlage betreten oder verlassen. Bei einer typischen Maschine sind das eine Handvoll Punkte:

• der Engineering-Zugang zur Steuerung,
• die Bedienebene (HMI, lokale Bedienpanels),
• der Fernwartungszugang,
• das Anlagennetz selbst (Feldbus, PROFINET/EtherCAT),
• die Schnittstelle zum Kundennetz (MES/ERP, meist OPC UA),
• USB-Ports und Wechseldatenträger.

Sechs Schnittstellen mal sechs Fragen ergeben eine Tabelle von überschaubarem Umfang. Vollständigkeit entlang der Schnittstellen zählt mehr als Tiefe an der einzelnen Komponente: Was in der Firmware einer zugekauften SPS steckt, bewertet deren Hersteller; auf dessen Advisories darf sich der Anlagenbauer stützen.

Am Beispiel einer Verpackungsmaschine mit Fernwartungszugang

Konkret an einer typischen Maschine: SPS und Safety-Steuerung, HMI-Panel, Servoantriebe über PROFINET, ein Fernwartungsrouter mit VPN und eine OPC-UA-Verbindung ans MES des Betreibers. Die Tabelle zeigt je STRIDE-Kategorie ein Szenario. In der echten Beurteilung stehen je Schnittstelle mehrere Zeilen, die Struktur bleibt dieselbe:

Die Spalte „Trifft" ist die Weiche zwischen den Verordnungen: Führt das Szenario zu einer Gefährdung von Personen oder hebelt es eine Sicherheitsfunktion aus, gehört die Zeile zusätzlich in die MVO-Risikobeurteilung. CRA-relevant ist jede Zeile.

Die IEC 62443 stützt die Beurteilung als Prüfliste und Maßnahmenkatalog

Die Normenreihe ersetzt die Risikobeurteilung nicht; sie stützt sie an drei Stellen. Teil 4-1 (Anforderung SR-2) listet, was ein Bedrohungsmodell enthalten muss: Datenflüsse, Vertrauensgrenzen, Schnittstellen zu externen Systemen, implementierte Protokolle, von außen zugängliche physische Anschlüsse, mögliche Angriffsvektoren, Gegenmaßnahmen und äußere Abhängigkeiten wie Fremdsoftware. Diese Liste taugt als Vollständigkeitsprüfung für die STRIDE-Tabelle; die Norm verlangt außerdem, das Modell mindestens jährlich durchzusehen. Teil 3-2 ist die Systemsicht des Integrators: Die Anlage wird in Zonen und Conduits zerlegt, je Zone wird ein Ziel-Security-Level festgelegt. Das ist die Struktur, in der die Netzsegmentierung aus der Tabelle oben begründet wird. Die Teile 3-3 und 4-2 liefern schließlich den Maßnahmenkatalog, aus dem die Spalte „Maßnahme" ihre Referenzen zieht.

Für den CRA ist die IEC 62443 keine harmonisierte Norm und gibt darum keine Konformitätsvermutung; als anerkannter Stand der Technik bleibt sie der übliche Beleg, bis die CRA-Normen im Amtsblatt stehen. Für die Maschinenverordnung sieht prEN 50742 den Weg über die IEC 62443 als gleichwertige Alternative vor. Wer die Beurteilung an der 62443 ausrichtet, bedient damit beide Verordnungen mit derselben Struktur.

Im Prüffall scheitert die Begründung, nicht die Methode

Die typischen Schwachpunkte sind die Begründungen: ein akzeptiertes Restrisiko ohne dokumentierten Grund, Anforderungen aus CRA Anhang I, die pauschal statt risikobasiert abgehakt sind, Annahmen über die Einsatzumgebung, die nie in die Betriebsanleitung übernommen wurden. Solche Lücken zeigen sich erst beim Lesen: im Audit, im Schadensfall, bei der Nachfrage eines Endkunden.

Unter dem Dokument steht am Ende eine Unterschrift. Die Safety-Risikobeurteilung unterschreibt jemand, der das Verfahren hunderte Male angewendet hat; die Cyber-Risikobeurteilung unterschreibt derselbe Konstruktions- oder Projektleiter zum ersten Mal. Deshalb sollte die erste Beurteilung je Anlagentyp nicht allein entstehen: Sie muss einer Prüfung standhalten, wenn es darauf ankommt.

Die fertige Beurteilung besteht aus sechs Bestandteilen

Systembeschreibung mit Netzbild, Einsatzumgebung und Annahmen; Bedrohungsanalyse je Schnittstelle; Risikobewertung mit Maßnahmen; Zuordnung jeder Zeile zu Anhang I des CRA und, wo eine Sicherheitsfunktion betroffen ist, zu Anhang III der Maschinenverordnung; Restrisiken mit Begründung; Pflegeregel. Jedes Kapitel liefert die Grundlage für das folgende, und die beiden Zuordnungen sind die Ausleitungen, die in die technische Dokumentation und in die 12100-Beurteilung wandern.

Das Angebot: eine Basisbeurteilung je Anlagentyp, unterschriftsreif in zwei Wochen

Werkspilot erstellt die Basisbeurteilung für einen Anlagentyp in zwei Terminen: Systemaufnahme mit Netzbild und Schnittstellen, dann Durchsprache der Ergebnisse mit der Konstruktion. Dazwischen entsteht die STRIDE-Analyse. Nach zwei Wochen liegt eine unterschriftsreife Beurteilung vor, mit beiden Ausleitungen (MVO-Teil für die Risikobeurteilung der Maschine, CRA-Teil für die technische Dokumentation) und der Pflegeregel für die Deltas je Auftrag. Unterschrieben wird sie von der Konstruktion; der zweite Termin ist dafür da, dass sie weiß, was sie unterschreibt.

Erstgespräch anfragen →

Die Vorlage mit der beschriebenen Struktur schicken wir auf Anfrage zu, mit Angabe von Name, Firma und Anlagentyp, zusammen mit einem Terminvorschlag für die Durchsprache am eigenen Anlagentyp: Vorlage anfordern.

Die Beurteilung wird einmal erstellt und anlassbezogen fortgeschrieben

Die Beurteilung entsteht einmal je Anlagentyp und wird anlassbezogen angefasst: bei einer wesentlichen Änderung, einer neuen Schnittstelle, einer veränderten Bedrohungslage. Der CRA verlangt die Aktualisierung für den gesamten Unterstützungszeitraum (Art. 13 Abs. 3), die IEC 62443-4-1 eine Durchsicht mindestens einmal im Jahr. Davon zu trennen ist die laufende Arbeit: neue Lieferanten-Advisories gegen die ausgelieferten Anlagen abgleichen und im Ernstfall fristgerecht melden. Die Risikobeurteilung ist der einmalige Teil der CRA-Arbeit, das Monitoring der tägliche, und genau den automatisiert Werkspilot.

Werkspilot erstellt STRIDE-Bedrohungsanalysen als Teil der Risikobeurteilung und automatisiert das laufende Schwachstellenmanagement über die Feldbasis von Anlagenbauern und Integratoren. Dieser Beitrag gibt die Einschätzung von Werkspilot wieder und ersetzt keine Rechtsberatung; maßgeblich sind die Verordnungstexte selbst. Kommissions-FAQ und Leitlinien sind nicht rechtsverbindlich; prEN 50742 ist zitiert nach dem Entwurfsstand.