Cybersecurity-Anforderungen der Maschinenverordnung: Schutz gegen Korrumpierung und sichere Steuerungen

Problem in der Praxis

Maschinenbau-Organisationen trennen traditionell zwischen funktionaler Sicherheit (Safety) und Informationssicherheit (Security). Die Risikobeurteilung nach der alten Maschinenrichtlinie kannte Verschleiß, Fehlbedienung und technische Defekte, aber keinen Angreifer. Gleichzeitig sind moderne Maschinen vernetzt: Fernwartungszugänge, Cloud-Anbindungen, Feldbusse und nachladbare Software gehören zum Standard. Genau diese Verbindungen adressiert die Verordnung.

In der Praxis fehlen dafür meist drei Dinge: ein belastbares Inventar der sicherheitsrelevanten Software, das die Maschine selbst auskunftsfähig macht; Mechanismen, die Eingriffe in sicherheitsrelevante Hardware, Software oder Konfiguration erkennen und nachweisbar machen; und ein Logging-Konzept, das die neuen Fristen trägt, denn Protokolldaten zu Eingriffen und nachgeladenen Sicherheitssoftware-Versionen müssen bis zu fünf Jahre nach dem Hochladen für Behörden zugänglich sein, Entscheidungsdaten selbstentwickelnder Steuerungen ein Jahr. Wer das erst im Zulassungsprojekt entdeckt, baut Architektur unter Zeitdruck um.

CISO-Einordnung

Abschnitt 1.1.9 "Schutz gegen Korrumpierung" lässt sich in fünf Anforderungslinien übersetzen (Wortlaute nach der berichtigten deutschen Fassung vom 01.04.2025):

• Sichere Anbindung: Der Anschluss einer anderen Einrichtung, auch über eine entfernte Fernzugriffseinrichtung, darf nicht zu einer gefährlichen Situation führen. Jede Schnittstelle der Maschine ist damit eine Safety-Frage.
• Hardware-Schutz: Hardware-Bauteile, die Signale oder Daten für die Verbindung mit oder den Zugriff auf konformitätsrelevante Software übertragen, müssen angemessen gegen unbeabsichtigte oder vorsätzliche Korrumpierung geschützt sein; Eingriffe in solche Bauteile muss die Maschine nachweisbar machen.
• Software- und Datenschutz: Software und Daten, die für die Konformität von entscheidender Bedeutung sind, sind als solche kenntlich zu machen und angemessen gegen Korrumpierung zu schützen.
• Software-Identifikation: Die Maschine muss die installierte, für den sicheren Betrieb erforderliche Software identifizieren und diese Information jederzeit in leicht zugänglicher Form bereitstellen können.
• Eingriffsnachweise: Die Maschine muss Nachweise über rechtmäßiges oder unrechtmäßiges Eingreifen in die Software oder über Veränderungen der installierten Software oder ihrer Konfiguration sammeln.

Abschnitt 1.2.1 "Sicherheit und Zuverlässigkeit von Steuerungen" verankert Security direkt in der Steuerungstechnik. Steuerungen müssen so ausgelegt sein, dass es nicht zu Gefährdungssituationen kommt; dazu gehört ausdrücklich das Standhalten gegenüber beabsichtigten und unbeabsichtigten Fremdeinflüssen "einschließlich vernünftigerweise vorhersehbare böswillige Versuche Dritter". Hardware- oder Software-Defekte und Fehler in der Logik des Steuerkreises dürfen nicht zu Gefährdungssituationen führen. Die Grenzen der Sicherheitsfunktionen folgen aus der Risikobeurteilung des Herstellers; gefährliche Änderungen von Einstellungen oder Regeln sind zu verhindern, auch während einer Lernphase. Hinzu kommt ein Rückverfolgungsprotokoll: Daten, die im Zusammenhang mit einem Eingreifen generiert wurden, und die Versionen der nach dem Inverkehrbringen hochgeladenen Sicherheitssoftware müssen bis zu fünf Jahre nach dem Hochladen auf begründete Anforderung einer Behörde zugänglich sein, ausschließlich zum Konformitätsnachweis.

Für Steuerungssysteme mit vollständig oder teilweise selbstentwickelndem Verhalten gelten Zusatzanforderungen: keine Handlungen über die festgelegte Aufgabe und den festgelegten Bewegungsbereich hinaus, aktivierte Aufzeichnung der Daten über den sicherheitsrelevanten Entscheidungsprozess mit einjähriger Speicherung für den behördlichen Konformitätsnachweis sowie jederzeitige Korrigierbarkeit der Maschine zur Wahrung ihrer inhärenten Sicherheit. Für kabellose Steuerungen gilt: Ein Ausfall der Kommunikation oder Verbindung oder eine fehlerhafte Verbindung darf nicht zu einer Gefährdungssituation führen.

Den Rahmen setzen die Allgemeinen Grundsätze des Anhangs III: Risikobeurteilung und Risikominderung müssen Gefährdungen über den Lebenszyklus einschließen, auch solche aus der bestimmungsgemäßen Veränderung selbstentwickelnden Verhaltens, soweit beim Inverkehrbringen vorhersehbar. Security-Bedrohungen gehören damit in dieselbe iterative Risikobeurteilung wie klassische mechanische Gefährdungen.

Umsetzungsperspektive

Für den Nachweis kennt die Verordnung mehrere Vermutungswege, die alle auch die Abschnitte 1.1.9 und 1.2.1 abdecken können:

• Harmonisierte Normen (Art. 20 Abs. 1): Übereinstimmung mit im Amtsblatt gelisteten harmonisierten Normen begründet die Konformitätsvermutung für die abgedeckten Anforderungen. Welche Normen mit Security-Bezug zur Maschinenverordnung gelistet sind, war am Redaktionsstand nicht verifiziert; der Listungsstand ist vor Projektentscheidungen zu prüfen.
• Gemeinsame Spezifikationen (Art. 20 Abs. 3 und 6): Die Kommission kann sie per Durchführungsrechtsakt festlegen, wenn der Normungsweg scheitert oder nicht rechtzeitig liefert; auch sie tragen eine Konformitätsvermutung.
• Cybersicherheitszertifizierung (Art. 20 Abs. 9): Für Maschinen, die im Rahmen eines Schemas nach der Verordnung (EU) 2019/881 (Cybersecurity Act) zertifiziert sind oder eine Konformitätserklärung in einem solchen Schema tragen, wird die Konformität mit 1.1.9 und 1.2.1 vermutet, soweit Zertifikat oder Erklärung diese Anforderungen abdecken. Ob ein nutzbares Schema mit veröffentlichter Amtsblatt-Fundstelle bereits zur Verfügung steht, ist eine Tatsachenfrage und vor einer Entscheidung zu prüfen.
• Übergangsweg für Hochrisiko-KI (Art. 20 Abs. 10, eingefügt durch die Verordnung (EU) 2026/1744; die Änderungsverordnung ist seit dem 27.07.2026 in Kraft, der geänderte Art. 20 wird nach der Staffel des Art. 54 aber erst ab dem 20.01.2027 anwendbar; Rechtsstand 01.08.2026): Bis eigene harmonisierte Normen oder gemeinsame Spezifikationen der Maschinenverordnung für Hochrisiko-KI-Systeme vorliegen, begründet Konformität mit einschlägigen AI-Act-Normen oder AI-Act-Spezifikationen die Vermutung für die betreffenden Anhang-III-Anforderungen in Bezug auf Hochrisiko-KI-Systeme.

Wichtig ist, was es nicht gibt: eine gegenseitige Vermutungswirkung zwischen Maschinenverordnung und Cyber Resilience Act. Der CRA hält in seinen Erwägungsgründen lediglich fest, dass beide Anforderungskataloge ähnliche Risiken adressieren und CRA-Konformität die MVO-Konformität erleichtern kann; solche Synergien muss der Hersteller nachweisen, und beide Konformitätsverfahren sind zu durchlaufen. Das Zusammenspiel mit CRA und RED behandelt ein eigener Beitrag dieses Themenbereichs.

Ingenieurpraktisch übersetzen sich die Anforderungen in bekannte Bausteine der Produkt- und OT-Security: gehärtete Fernzugriffs- und Schnittstellenarchitektur, Integritätsschutz und Signierung sicherheitsrelevanter Software und Parameter, Manipulationserkennung an Hardware und Software, ein maschinenlesbares Inventar der sicherheitsrelevanten Softwarestände, ein Update-Prozess mit Versionsprotokollierung sowie ein Logging-Konzept, das Aufbewahrung und Zweckbindung (bis zu fünf Jahre beziehungsweise ein Jahr, Zugriff nur auf begründete Behördenanforderung) technisch und organisatorisch trägt. Als Referenz für das industrielle Sicherheitsniveau kann die Normenreihe IEC 62443 als Stand der Technik dienen; sie ist lizenzpflichtig und wird hier nur referenziert, die Einordnung in Zonen, Conduits und Security Level trägt der OT-Bereich dieses Korpus.

Typische Fehler

1. Security wird als IT-Projekt neben dem Safety-Engineering geführt, statt Angreifer als Gefährdungsquelle in die Risikobeurteilung nach Anhang III zu integrieren.
2. Die Maschine kann ihre sicherheitsrelevante Software nicht selbst identifizieren; das Inventar existiert nur in Projektdokumenten.
3. Eingriffs- und Versionsprotokolle fehlen oder ignorieren Fristen (bis zu fünf Jahre, ein Jahr) und Zweckbindung.
4. Fernwartungs- und Cloud-Schnittstellen werden nicht als konformitätsrelevante Anschlusswege nach Abschnitt 1.1.9 behandelt.
5. Es wird angenommen, CRA-Konformität erledige die Maschinenverordnung mit; eine solche Vermutungswirkung existiert nicht.
6. Art. 20 Abs. 9 wird als einziger Nachweisweg missverstanden, obwohl harmonisierte Normen und gemeinsame Spezifikationen gleichwertige Vermutungswege sind.
7. Kabellose Steuerungen werden ohne definiertes sicheres Verhalten bei Verbindungsverlust ausgelegt.

Risiken und Trade-offs

Die Aufzeichnungspflichten erzeugen ein Spannungsfeld: Eingriffs- und Entscheidungsprotokolle sind sicherheitlich gewollt, können aber personenbeziehbare Daten enthalten und wecken Begehrlichkeiten über den Konformitätsnachweis hinaus. Die Verordnung bindet den Behördenzugriff an begründete Anforderungen und den Zweck des Konformitätsnachweises; interne Zugriffs- und Löschkonzepte müssen diese Zweckbindung nachbilden.

Manipulationsschutz und Wartbarkeit stehen in Konkurrenz: Wer sicherheitsrelevante Software strikt versiegelt, erschwert legitime Anpassungen durch Service und Betreiber; wer Eingriffe zu leicht macht, verliert den Schutz gegen Korrumpierung. Die Grenze verläuft über kenntlich gemachte, geschützte und protokollierte Änderungswege. Dazu kommt ein Planungsrisiko: Der Bestand harmonisierter Normen und nutzbarer Zertifizierungsschemata entwickelt sich noch. Wer früh auf einen Vermutungsweg setzt, gewinnt Struktur, muss aber mit Nachschärfungen rechnen; wer nur auf eigene technische Spezifikationen baut, trägt die volle Argumentationslast in der technischen Dokumentation.

Entscheidungspunkte

• Wie werden Security-Bedrohungen methodisch in die Risikobeurteilung nach Anhang III integriert, und wer führt Safety- und Security-Analysen zusammen?
• Welche Software, Daten und Hardware-Bauteile sind konformitätsrelevant im Sinne von Abschnitt 1.1.9, und wie werden sie gekennzeichnet und geschützt?
• Wie erfüllt die Maschine Software-Identifikation, Eingriffsnachweise und Rückverfolgungsprotokoll technisch, und wo liegen die Daten?
• Welcher Vermutungsweg wird angestrebt (harmonisierte Normen, gemeinsame Spezifikationen, Cybersicherheitszertifizierung), und wann wird der Status geprüft?
• Wie wird das sichere Verhalten bei Verbindungsverlust kabelloser Steuerungen definiert und getestet?
• Wie werden selbstentwickelnde Steuerungsfunktionen begrenzt, protokolliert und korrigierbar gehalten?

Praktische Empfehlungen

1. Erweitern Sie die Safety-Risikobeurteilung um Angreifermodelle und behandeln Sie böswillige Einwirkungen Dritter als reguläre Gefährdungsquelle.
2. Definieren Sie je Maschine die konformitätsrelevante Software, die zugehörigen Daten und die übertragenden Hardware-Bauteile und leiten Sie daraus Schutz- und Kennzeichnungsmaßnahmen ab.
3. Bauen Sie Software-Inventar, Eingriffs- und Versionsprotokollierung als Produktfunktionen, nicht als nachgelagerte Dokumentation.
4. Entwerfen Sie das Logging mit Aufbewahrungsfristen, Zugriffskontrolle und Zweckbindung als Einheit und dokumentieren Sie den Behördenpfad.
5. Prüfen Sie vor Architekturentscheidungen den aktuellen Stand harmonisierter Normen, gemeinsamer Spezifikationen und nutzbarer Cybersicherheitsschemata.
6. Nutzen Sie etablierte industrielle Security-Rahmen wie IEC 62443 als Stand-der-Technik-Orientierung und verzahnen Sie Produkt-Security mit der OT-Security des Betriebs.
7. Legen Sie für kabellose und fernzugängliche Funktionen ein definiertes sicheres Ausfallverhalten fest und testen Sie es als Sicherheitsfunktion.

Relevante Normreferenzen

• EU-Maschinenverordnung (Verordnung (EU) 2023/1230): Anhang III Abschnitte 1.1.9 und 1.2.1 sowie Allgemeine Grundsätze; Vermutungswege in Art. 20 Abs. 1, 3, 6, 9 und 10; maßgeblich ist die berichtigte Fassung (deutsche Berichtigung vom 01.04.2025).
• Cybersecurity Act (Verordnung (EU) 2019/881): Grundlage der Zertifizierungsschemata, auf die Art. 20 Abs. 9 verweist.
• Verordnung (EU) 2026/1744: fügt unter anderem Art. 20 Abs. 10 (Übergangsvermutung für Hochrisiko-KI-Systeme) ein; die Änderungsverordnung ist seit dem 27.07.2026 in Kraft, der geänderte Art. 20 wird mit der Staffel des Art. 54 ab dem 20.01.2027 anwendbar.
• Cyber Resilience Act (Verordnung (EU) 2024/2847): paralleler horizontaler Rechtsrahmen; keine gegenseitige Vermutungswirkung mit der Maschinenverordnung.
• IEC 62443 (Reihe): lizenzpflichtige Normenreihe für industrielle Security; hier nur als Stand-der-Technik-Referenz.