Cyber Resilience Act & Maschinenverordnung: Was Maschinenbau und OT-Betreiber jetzt wissen müssen

Für die praktische Umsetzung empfiehlt Björn Griese das aus der IT-Security bekannte Defense-in-Depth- bzw. „Zwiebelschalenmodell“ mit drei Maßnahmenebenen:

1. Unternehmensebene: Security-Management und Security-Policies (z. B. Passwortgestaltung) sowie physischer Schutz, wie bspw. Zugangskontrolle zu Schaltschränken mit echten Schließsystemen statt dem „Standardschaltschrankschlüssel“, den jeder Handwerker in der Hosentasche hat.
2. Netzwerkebene: Segmentierung in Zonen und Kanäle/Konduits, ein durchdachter Remote-Zugriff sowie Monitoring, z. B. über ein Intrusion Detection System, und Verschlüsselung vertraulicher Datenübertragungen.
3. Komponentenebene: Nutzer- und Rechteverwaltung, keine Standardpasswörter, sichere Firmware-Updates, verschlüsselte Datenablage (Secure Data) und Secure Logging – Funktionen, die Komponentenhersteller bereitstellen, die aber aktiv genutzt werden müssen.

Auf Netzwerkebene beschreibt Griese eine typische Architektur: Enterprise-Netzwerk (mit Internetanbindung und Firewall) → DMZ (als „Marktplatz“ für Kunden- und Lieferantenzugriffe) → Industrial-/Managed-Switch-Ebene mit VLAN-Segmentierung → OT-/Maschinennetzwerk, weiter abgesichert durch Firewalls. Eine Zone bündelt Komponenten mit gleichem Sicherheitsniveau, ein Kanal/Konduit definiert den erlaubten Datenfluss zwischen Zonen. Empfohlen wird konsequentes Whitelisting statt Blacklisting.

Ein zentraler Praxispunkt betrifft die Platzierung von Router und Firewall: innerhalb oder außerhalb der Maschine. Viele Maschinenbauer gingen bisher davon aus, dass die Maschine ohnehin in einem geschützten Netzwerk des Betreibers läuft und zusätzlicher Schutz überflüssig sei.

Ein Industrie-PC mit Windows innerhalb der Maschine hat oft sehr viele offene Dienste und Ports. Eine vollständige Risikobewertung „von außerhalb“ wird dadurch praktisch unmöglich. Die Lösung: den Router in die Maschine verlegen und dort nur tatsächlich benötigte Dienste und Ports konfigurieren. Das reduziert die Angriffsfläche deutlich und macht sie überhaupt erst bewertbar.

Auch WLAN-Access-Points sollten am Router statt am Switch angeschlossen werden, denn WLANs sind laut Griese ein besonders leichtes Angriffsziel:

Dr. Matthias Orthwein ergänzt, dass Risiken nicht nur von gezielten Angreifern ausgehen:

Als Beispiel nennt er die Reinigungskraft, die versehentlich ein Netzwerkkabel zieht. Besonders kritisch sieht Orthwein die OT-Backup-Lücke vieler Unternehmen:

Reines Betreiben einer bereits vorhandenen Maschine löst zunächst keine neuen Pflichten aus. Die auslösenden Rechtsbegriffe sind „in Verkehr bringen“, „bereitstellen“ und „in Betrieb nehmen“, nicht der fortlaufende Betrieb selbst. Bestehende Maschinen dürfen also grundsätzlich unverändert weiterlaufen.

Sobald jedoch wesentliche Veränderungen an Software, Steuerung, Netzwerk, Fernwartung oder Firmware vorgenommen werden, gilt die Maschine rechtlich als neu hergestellt.

Wer eine solche wesentliche Veränderung durchführt – auch als Betreiber –, wird rechtlich wie ein Hersteller behandelt: mit vollen Dokumentations-, CE- und Risikobewertungspflichten. Als neu gilt zum Beispiel auch der nachträgliche Einbau einer KI-Funktion, die vorher nicht vorhanden war.

Eine wichtige Ausnahme gibt es beim CRA: Reiner Eigenverbrauch, Eigenbau oder Eigenanwendung, also ein Betreiber baut oder verändert eine Maschine ausschließlich für den eigenen Gebrauch, fällt nicht unter den CRA. Die Maschinenverordnung gilt in diesem Fall jedoch weiterhin, sofern die Sicherheit der Maschine betroffen ist.

Auch die Lieferkette ist relevant: Identische Ersatzteile, die Funktion oder Sicherheit der Gesamtmaschine nicht verändern, sind unkritisch. Neue Komponenten dagegen, etwa solche, die erstmals eine digitale Schnittstelle einführen, können selbst als eigenständige unvollständige Maschine, Sicherheitsbauteil oder CRA-Produkt gelten. Verändert eine neue Komponente eine Schnittstelle oder eröffnet neue Angriffswege, ist das eine wesentliche Veränderung, und der Betreiber wird dadurch selbst verantwortlich. Entscheidend ist dabei stets die Gesamtbetrachtung der Maschine, nicht die isolierte Konformität eines Einzelteils. Aus lauter nicht CE-konformen Komponenten kann eine sichere Maschine entstehen, wenn übergeordnete Schutzmechanismen die Risiken adressieren und das dokumentiert ist.

Unabhängig von geplanten Veränderungen gilt: Ab 11. September 2026 müssen auch unveränderte Bestandsmaschinen verpflichtend in das Schwachstellenmanagement einbezogen werden.

Die technische Dokumentation muss der Marktüberwachungsbehörde auf Anfrage vorgelegt werden können. Sie geht nicht automatisch an Kunden. Dazu gehören unter anderem: die Beschreibung der Maschine inklusive bestimmungsgemäßer Verwendung (auch des Security-Umfelds), der innere Aufbau, eine Risikobewertung, Entwurfs- und Designunterlagen, das Verfahren zur Schwachstellenbehandlung sowie Test- und Prüfberichte. Getrennt davon steht die Kundendokumentation: bestimmungsgemäße Verwendung, vorhersehbarer Fehlerfall inklusive möglicher Sicherheitslücken sowie sichere Verwendung, Wartung und Instandsetzung.

Ein zentrales Element ist die SBOM (Software Bill of Materials): eine Liste aller Softwarekomponenten mit Version, im Standardformat z. B. CycloneDX. Sie muss nicht veröffentlicht, aber der Marktüberwachungsbehörde auf Anfrage bereitgestellt werden können.

Bei der CE-Konformitätsbewertung unterscheiden sich CRA und Maschinenverordnung im Detail. Beim CRA reicht für rund 90 Prozent der Produkte, und damit für fast alle Maschinen, eine Hersteller-Selbsterklärung.

Der CRA unterscheidet dabei Klasse 1 (z. B. Router, Switches, benötigt eine im EU-Amtsblatt veröffentlichte harmonisierte Norm, um die Selbsterklärung zu ermöglichen) und Klasse 2 (benötigt zwingend eine zertifizierte Drittstelle). Bei der Maschinenverordnung ist eine Selbsterklärung nur für sehr einfache Maschinen möglich. Die meisten Maschinen fallen unter „Teil B“ und benötigen eine harmonisierte Norm; fehlt diese, ist eine Baumusterprüfung durch eine benannte Stelle nötig. Welche technischen Normen konkret als harmonisiert gelten werden, ist zum jetzigen Zeitpunkt noch nicht abschließend im EU-Amtsblatt veröffentlicht. Das ist ein Grund mehr, sich frühzeitig an etablierten Frameworks wie dem in unserem Beitrag zum OT-Cybersecurity-Standard IEC 62443 beschriebenen Ansatz zu orientieren.

Der CRA-Support-Zeitraum für Sicherheitsupdates ist unabhängig von der Gewährleistung. Der Gesetzgeber erwartet üblicherweise mindestens fünf Jahre Support ab Erstinbetriebnahme der konkreten Maschine. Rainer Baeder bringt den grundlegenden Rollenwechsel auf den Punkt:

Hersteller müssen Zuständigkeiten für Schwachstellen im eigenen Unternehmen festlegen und Meldekanäle auf der eigenen Webseite veröffentlichen, inklusive der Möglichkeit zur anonymen Meldung. Ab dem 11. September 2026 ist zudem konkret gefordert: Eingang von Meldungen im Ticketsystem dokumentieren und eine Erstbewertung zu Echtheit, Ausnutzbarkeit, betroffenen Produkten und Impact durchführen.

Für aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle gilt ein eigenes, verpflichtendes Meldeportal mit festen Fristen. Im Webinar von Orthwein mit der DSGVO-Meldelogik verglichen:

Diese Fristen gelten unabhängig von Wochenenden und Feiertagen. Das ist ein Punkt, den Unternehmen bei der Prozessplanung häufig unterschätzen. Björn Griese empfiehlt, Security Advisories im maschinenlesbaren CSAF-Format (Common Security Advisory Framework) zu veröffentlichen und nennt als Praxisbeispiel den eigenen Weidmüller-Prozess: Meldung sowohl über die eigene Webseite als auch über CERT@VDE, die zentrale deutsche Meldeplattform, damit Kunden eine einheitliche Anlaufstelle haben.

Für Maschinenbauer und Hersteller

• Security/Safety by Design: Cybersecurity von Anfang an mitdenken, nicht nachträglich als Add-on entwickeln.
• Router in die Maschine integrieren: statt auf ein „vertrauenswürdiges Netzwerk“ des Betreibers zu vertrauen. Das reduziert die Angriffsfläche und erleichtert die eigene Risikobeurteilung.
• Keine unsicheren Standardpasswörter: wirksamen Mechanismus zur Passwortänderung bei Erstinbetriebnahme vorsehen oder wirksam dokumentieren.
• SBOM führen und pflegen (z. B. im CycloneDX-Format) und auf Anfrage der Marktüberwachungsbehörde bereitstellen.
• Meldekanäle einrichten: eigene Webseite und z. B. CERT@VDE, inklusive anonymer Meldemöglichkeit und veröffentlichter Policy.
• Alle Fristen operationalisieren: 24 Std./72 Std./14 Tage Meldefristen, 5/10 Arbeitstage Rückmeldung, 90-Tage-Offenlegungsfrist.

Für Komponentenhersteller

• Eigenständige Software prüfen: auch Konfigurationstools können unter den CRA fallen und eine eigene CE-Erklärung benötigen.
• Standardfunktionen bereitstellen: Nutzer-/Rechteverwaltung, sichere Firmware-Updates, verschlüsselte Datenspeicherung, sicheres Logging.
• Konformitätsstatus klären: ob eine neue digitale Komponente selbst als unvollständige Maschine, Sicherheitsbauteil oder CRA-Produkt gilt.

Für OT-Betreiber

• Physischen Zugang sichern: echte Schließsysteme statt Standardschaltschrankschlüssel.
• Netzwerksegmentierung konsequent umsetzen: klares Zonen-/Kanal-Konzept mit Whitelisting statt Blacklisting.
• OT-Backups etablieren: eigene Backup-/Restore-Mechanismen für Produktionssoftware, nicht nur für IT-Systeme.
• Nachweise aktiv einfordern: CE-Erklärung, technische und Kundendokumentation sowie SBOM vom Hersteller anfordern und aufbewahren.
• Eigene Veränderungen prüfen: bei Zusammenbau, Erweiterung oder Nachrüstung klären, ob man dadurch selbst zum „Hersteller“ wird.

Für den strukturierten Aufbau eines belastbaren OT-Security-Programms, unabhängig vom regulatorischen Anlass, lohnt sich der Blick in unsere Beiträge zu OT-Cybersecurity-Governance als Schlüsselelement für den Schutz kritischer Infrastrukturen und zum OT-Cybersecurity-Program-Setup: Leitfaden zur effektiven Implementierung. Beide zeigen, wie sich einzelne Compliance-Anforderungen wie die hier beschriebenen in ein nachhaltiges, unternehmensweites Sicherheitsprogramm einbetten lassen, anstatt Insellösungen für einzelne Gesetze zu bauen.