Auch wenn neue Maschinen mit digitalen Elementen erst ab Dezember 2027 die vollständigen Produktanforderungen des CRA erfüllen müssen, gelten die Meldepflichten bereits mehr als ein Jahr früher, und zwar unabhängig davon, wann eine Maschine in Verkehr gebracht wurde. Im Vergleich zu NIS-2 und Dora rückt der CRA Maschinen, Steuerungen, Schnittstellen (HMI, Human Machine Interfaces), Edge-Gateways, Remote-Service-Komponenten und zugehörige Software in den Fokus und verlangt belastbare Prozesse über den gesamten Lebenszyklus, von Entwicklung und Dokumentation bis zu Updates und Meldungen. Entscheidend ist, ob das Produkt digitale Elemente enthält und in der EU verfügbar ist.
Moderne Anlagen bestehen aus bis zu 5.000 Bauteilen unterschiedlicher Hersteller. Jede Komponente bringt eigene Software, Releasezyklen und damit auch Schwachstellen mit. Trotzdem trägt der Maschinenbauer die Verantwortung für die Gesamtsicherheit des Produkts, auch wenn er zentrale Komponenten nicht selbst entwickelt und nicht bis in jedes Detail der Zulieferungen hineinschauen kann. Hinzu kommt: Während IT im Rhythmus weniger Jahre erneuert wird, laufen OT-Anlagen oft 15 bis 20 Jahre. Zudem sind Updates häufig riskant, da sie zu Stillständen führen und die Gesamtfunktion beeinflussen können. Dennoch verlangt der CRA, dass Hersteller Schwachstellen dokumentieren, Risiken bewerten und angemessene Gegenmaßnahmen nachweisen. Cybersecurity wird damit zur Ingenieuraufgabe entlang von Konstruktion, Service und Betrieb.
Viele der entlang des Produktlebenszyklus zentral gebündelten CRA-Vorgaben lassen sich jedoch mit solider Produktklassifizierung, technischer Dokumentation und klaren Nutzerinformationen umsetzen. Besonders herausfordernd für Maschinenbauer sind allerdings vier Punkte: das kontinuierliche Schwachstellenmanagement, die Bereitstellung von Patches oder alternativen Schutzmaßnahmen, die fristgerechte Meldung von Vorfällen sowie die nachvollziehbare Steuerung des Produktlebenszyklus.
Mit Transparenz zur Compliance
Schwachstellenmanagement beginnt mit Transparenz. Hersteller müssen genau wissen, welche Software in welcher Version ihre Maschinen steuert. Ohne eine Software Bill of Materials (SBOM), also eine vollständige Übersicht aller Softwarekomponenten, bleibt das ein Blindflug. Eine stets aktuelle Inventarliste bildet die Grundlage für alle weiteren Schritte.
Bei der Bewertung von Schwachstellen unterstützt zudem ein Product Security Incident Response Team (PSIRT). Diese spezialisierte Arbeitsgruppe innerhalb eines Unternehmens identifiziert Sicherheitslücken in eigenen Produkten, Systemen oder Services und analysiert beziehungsweise behebt diese.
Updates vs. Betriebsstabilität
Der CRA fordert Sicherheitsupdates, auch wenn viele kritische Bausteine von Dritten stammen. Gleichzeitig darf eine Anlage dadurch nicht destabilisiert werden und muss in einer realen Umgebung funktionieren. Und sobald eine Schwachstelle aktiv ausgenutzt wird oder ein schwerer Vorfall vorliegt, läuft die Uhr: Neben der 24- und 72-Stunden-Meldung verlangt der CRA außerdem einen Abschlussbericht, der spätestens 14 Tage nach Verfügbarkeit einer Korrekturmaßnahme bei aktiv ausgenutzten Schwachstellen und binnen eines Monats bei schweren Sicherheitsvorfällen vorliegen muss. Hier bedarf es einer systematischen Überwachung und einer sauberen Datenbasis, um betroffene Modelle sowie den Status der Ausnutzung belastbar bestimmen zu können. Auch hier bildet die Inventarliste das Fundament. Doch nicht jede Schwachstelle erfordert sofort einen Patch. Die Bewertung muss klären, welche Patches welches Handeln erfordern.
Automatisierung statt Tabellen
Manuelle Ansätze stoßen aufgrund der Vielzahl an Komponenten in der Praxis schnell an Grenzen. CRA-Fähigkeit basiert deshalb auf drei Faktoren: Transparenz über Assets und Softwarestände, ein belastbarer Pfad für Updates oder alternative Gegenmaßnahmen und Prozesse, die Sicherheitsinformationen so verdichten, dass Meldungen fristgerecht und nachweisbar möglich sind. Die Basis hierfür liefern automatisierte Discovery- und Asset-Management-Ansätze. Sie erfassen kontinuierlich relevante Komponenten, bündeln Informationen zentral und erkennen Veränderungen. Wird eine neue Schwachstelle bekannt, lässt sich prüfen, ob und wo die eigene installierte Basis betroffen ist.
