Risikobeurteilung der Cybersicherheit: was CRA und Maschinenverordnung verlangen – mit Beispiel
Kurz gefasst · Stand: Juli 2026
Zwei Verordnungen verlangen eine dokumentierte Risikobeurteilung der Cybersicherheit: der CRA für das Produkt insgesamt (Art. 13, Teil der technischen Dokumentation nach Anhang VII), die Maschinenverordnung für die safety-relevante Seite (Anhang III, 1.1.9 und 1.2.1). In der Praxis entstehen beide Nachweise aus einer Bedrohungsanalyse je Anlagentyp – das übliche Werkzeug ist STRIDE entlang der Schnittstellen der Anlage. Die Beurteilung ist eine einmalige Aufgabe je Typ, im Auftrag wird nur das Delta dokumentiert; der laufende Teil ist das Schwachstellenmanagement.
Die Risikobeurteilung ist das vertrauteste Dokument im Maschinenbau: Für jede Maschine existiert eine nach EN ISO 12100, und die Systematik – Gefährdung ermitteln, Risiko bewerten, Maßnahme festlegen, Restrisiko begründen – beherrscht jede Konstruktionsabteilung. 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 gehört in die Cyber-Risikobeurteilung, wie wird sie zugeschnitten, und wie sieht sie an einer konkreten Maschine aus?
Die Maschinenverordnung fragt nach Gefährdung, der CRA nach 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 – sowie 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? – 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 als Teil der technischen Dokumentation (Anhang VII) aktuell zu halten. 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.
| Maschinenverordnung | CRA | |
|---|---|---|
| Schutzgut | Sicherheit und Gesundheit von Personen | Cybersicherheit des Produkts insgesamt |
| Grundlage | Anhang III, insb. 1.1.9 und 1.2.1 | Art. 13 Abs. 2–3, Anhang I, Anhang VII |
| Typische Frage | Löst der Angriff eine Gefährdung aus? | Ist das Risiko angemessen behandelt? |
| Verpflichtend ab | 20.01.2027 | 11.12.2027 (voll anwendbar) |
Der safety-relevante Teil ist damit eine Teilmenge des CRA-Blickwinkels. 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.
Der Zuschnitt: 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. 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.
Das Werkzeug: STRIDE entlang der Schnittstellen
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 nicht in den Begriffen, sondern in der Systematik: Die sechs Fragen werden nicht je Komponente gestellt, sondern je Schnittstelle – 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 schlägt Tiefe an der einzelnen Komponente: Was in der Firmware einer zugekauften SPS steckt, bewertet deren Hersteller; auf dessen Advisories dürfen Sie sich stützen.
Beispiel: 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:
| Bedrohung | Szenario und Folge | Maßnahme | Trifft |
|---|---|---|---|
| Spoofing | Ein Gerät im Anlagennetz gibt sich als Engineering-Station aus und verbindet sich mit der ungeschützten SPS – fremde Programmänderung möglich. | Zugriffsschutz der Steuerung aktivieren (Schutzstufen, Passwörter), Anlagennetz segmentieren. | CRA + MVO |
| Tampering | Manipulation von SPS-Programm oder Antriebsparametern; eine veränderte Drehzahlgrenze wird zur mechanischen Gefährdung. | Schreibschutz und Integritätsprüfung, Safety-Funktionen auf getrennter F-CPU bzw. hartverdrahtet. | CRA + MVO |
| Repudiation | Nach einem Vorfall lässt sich nicht nachvollziehen, wer wann über die Fernwartung zugegriffen hat – die MVO verlangt diesen Nachweis ausdrücklich (1.1.9). | Protokollierung am Fernwartungsrouter, individuelle Konten statt Sammelzugang. | CRA + MVO |
| Information Disclosure | Die OPC-UA-Schnittstelle überträgt Rezeptur- und Produktionsdaten unverschlüsselt ins Kundennetz – keine Gefährdung, aber ein Vertraulichkeitsrisiko. | OPC-UA-Security-Policy aktivieren (signiert und verschlüsselt), Zertifikate verwalten. | nur CRA |
| Denial of Service | Ein Broadcast-Sturm aus dem Kundennetz stört die PROFINET-Kommunikation; die Anlage geht in Störung, die Linie steht. | Netzübergang nur über Router/Firewall mit definierten Verbindungen, keine flache Kopplung. | nur CRA |
| Elevation of Privilege | Der Fernwartungszugang nutzt ein Sammelpasswort und steht dauerhaft offen – wer es kennt, hat Vollzugriff bis auf die Steuerung. | Individuelle Zugänge mit Zwei-Faktor-Anmeldung, Zugang vom Betreiber schaltbar (Schlüsselschalter). | CRA + MVO |
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.
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: sechs Bestandteile
Systembeschreibung mit Netzbild, Einsatzumgebung und Annahmen, Bedrohungsanalyse je Schnittstelle, Risikobewertung mit Maßnahmen und Zuordnung zu den Anforderungen, Restrisiken mit Begründung, Pflegeregel. Jedes Kapitel liefert die Grundlage für das folgende.
Das Angebot: Basisbeurteilung je Anlagentyp
Werkspilot erstellt die Basisbeurteilung für einen Anlagentyp in zwei Terminen: Systemaufnahme mit Netzbild und Schnittstellen, dann Durchsprache der Ergebnisse mit Ihrer 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, mit der Ihr Team die Deltas je Auftrag selbst führt.
Die Vorlage mit der beschriebenen Struktur gibt es auf Anfrage – mit kurzer Angabe von Name, Firma und Anlagentyp. Wir schicken sie zu und fragen nach zwei Wochen nach, wie weit Sie damit gekommen sind: Vorlage anfordern.
Aktualisierung: einmalige Aufgabe, anlassbezogen gepflegt
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 ausdrücklich für den gesamten Support-Zeitraum (Art. 13 Abs. 3). Davon zu trennen ist die laufende Arbeit: neue Lieferanten-Advisories kontinuierlich 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.
Fragen aus der Praxis
Reicht die bestehende Risikobeurteilung nach EN ISO 12100?
Nein. Das bestehende Dokument bleibt gültig und wird um die Bedrohungsanalyse ergänzt; ersetzt wird es nicht.
Braucht jede Anlage eine eigene Cyber-Risikobeurteilung?
Nein. Der Zuschnitt richtet sich nach Steuerungsplattform und Schnittstellen, nicht nach dem einzelnen Auftrag.
Welche Methode verlangt der Gesetzgeber?
Keine. CRA und MVO sind methodenneutral; gefordert ist Nachvollziehbarkeit. Üblich sind STRIDE für die Bedrohungen, ein einfaches Bewertungsraster aus Eintrittswahrscheinlichkeit und Schadensausmaß und die IEC 62443 als Referenzrahmen für Maßnahmen.
Ist die Risikobeurteilung einmalig oder laufend?
Das Dokument ist der einmalige Teil. Laufend ist das Schwachstellenmanagement über die ausgelieferte Feldbasis – der Teil, an dem manuelle Prozesse an der 24-Stunden-Frist scheitern.
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.