Ein Servicetechniker entdeckt Hinweise darauf, dass eine Schwachstelle in der Steuerung einer ausgelieferten Maschine aktiv ausgenutzt wird. Für den Hersteller beginnt damit eine Aufgabe, die sich nicht bis zum nächsten regulären Softwareupdate aufschieben lässt: Er muss das Ereignis prüfen, betroffene Produkte zuordnen und gegebenenfalls innerhalb kurzer Fristen melden. Dabei zählt, wann er von dem meldepflichtigen Sachverhalt Kenntnis erlangt hat.
Seit dem 11. September 2026 müssen Hersteller von Produkten mit digitalen Elementen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle melden. Die übrigen Pflichten des Cyber Resilience Act gelten grundsätzlich ab dem 11. Dezember 2027. Für Maschinenbauer ist deshalb jetzt vor allem wichtig, Softwarestände und Fernzugriffe ihrer Maschinen im Feld nachvollziehen zu können.
Was ist der Cyber Resilience Act und für wen gilt er?
Der Cyber Resilience Act (CRA) ist eine unmittelbar geltende EU-Verordnung für Produkte mit digitalen Elementen. Er knüpft an das konkrete Produkt und die Rolle seines Herstellers an – nicht pauschal an jede Maschine oder jeden Betrieb, der sie nutzt.
Die Verordnung (EU) 2024/2847 legt Cybersicherheitsanforderungen für Produkte mit digitalen Elementen fest, die auf dem EU-Markt bereitgestellt werden. Dazu können Hardware, Software und deren Komponenten gehören. Im Maschinenbau kommen etwa vernetzte Steuerungen, Bediengeräte oder Softwarefunktionen in Betracht. Ob eine bestimmte Maschine oder Komponente erfasst ist, hängt jedoch von ihrer konkreten Ausgestaltung und den Regeln zum Anwendungsbereich ab. Eine mechanische Anlage wird nicht allein dadurch zum CRA-Produkt, dass im Werk ein Netzwerk vorhanden ist.
Für Hersteller ist diese Unterscheidung praktisch bedeutsam. Sie müssen feststellen, welche ihrer Produkte digitale Elemente enthalten, welche Softwareversionen zu welchen ausgelieferten Ausführungen gehören und wie Sicherheitsinformationen aus dem Feld bei ihnen ankommen. Der CRA richtet Anforderungen an die Sicherheit des Produkts und an den Umgang mit Schwachstellen während seines Unterstützungszeitraums; die Meldepflicht für meldepflichtige Ereignisse besteht auch nach dessen Ende fort. Gerade bei langlebigen Maschinen entsteht daraus eine organisatorische Aufgabe: Ein Hinweis aus einer Kundenanlage muss sich einem Produkt, einer Version und einer zuständigen Stelle beim Hersteller zuordnen lassen.
Die aktuell geltenden Meldepflichten sind dabei vom späteren Beginn der meisten weiteren Herstellerpflichten zu trennen. Wer Produktentwicklung und Dokumentation auf den späteren Stichtag ausrichtet, benötigt für meldepflichtige Ereignisse trotzdem schon heute einen funktionsfähigen Eskalationsweg.
Welche Meldepflichten gelten bereits?
Zu melden sind zwei Ereignisse: aktiv ausgenutzte Schwachstellen im Produkt und schwerwiegende Sicherheitsvorfälle, die dessen Sicherheit beeinträchtigen. Entscheidend ist die Kenntnis des Herstellers.
Artikel 14 des CRA erfasst aktiv ausgenutzte Schwachstellen in Produkten mit digitalen Elementen; bloß theoretische Lücken reichen nicht aus. Zudem müssen Hersteller schwerwiegende Sicherheitsvorfälle mit Produktauswirkung melden. Maßgeblich sind Vorfallschwere und Produktbezug, nicht beliebige IT-Alarme.
Bei beiden Ereignisarten ist eine Frühwarnung spätestens innerhalb von 24 Stunden nach Kenntnis fällig, eine weitergehende Meldung binnen 72 Stunden. Die Frühwarnung muss nicht auf die abgeschlossene Analyse warten: Hersteller sollten festhalten, was sie bereits wissen, welche Produkte betroffen sein könnten und was noch untersucht wird.
Für den Abschlussbericht unterscheiden sich die Fristen: Bei aktiv ausgenutzten Schwachstellen ist er spätestens 14 Tage nach Verfügbarkeit einer Korrektur- oder Risikominderungsmaßnahme fällig, bei schwerwiegenden Sicherheitsvorfällen binnen eines Monats nach der Vorfallmeldung. Wer beide Fälle intern zusammenführt, sollte diese Auslöser ausdrücklich kennzeichnen.
Die Meldung wird über die einheitliche Meldeplattform nach Artikel 16 an das zuständige Computer Security Incident Response Team (CSIRT) übermittelt und zugleich der EU-Agentur für Cybersicherheit ENISA zugänglich gemacht. Ein internes Ticket oder eine Nachricht an den Maschinenbetreiber ersetzt diesen Meldeweg nicht. Für die praktische Einordnung der Meldepflichten aus dem Cyber Resilience Act ist vor allem die Verbindung von Produktzuordnung, Kenntniszeitpunkt und fristgerechter Eskalation wichtig.
Hinzu kommt die Information der Nutzer betroffener Produkte nach den Vorgaben des Artikels 14. Sie sollen von der Schwachstelle beziehungsweise dem Vorfall erfahren und, soweit einschlägig, über Maßnahmen zur Begrenzung des Risikos informiert werden. In einem Maschinenpark kann das bedeuten, dass Hersteller zunächst betroffene Produkt- und Softwarestände eingrenzen und anschließend die passenden Ansprechpartner bei ihren Kunden erreichen müssen. Behördenmeldung und Nutzerinformation sind eigenständige Aufgaben, die in einem abgestimmten Ablauf zusammengehören.
Was kommt ab Dezember dazu?
Ab dem 11. Dezember 2027 gelten die übrigen wesentlichen Anforderungen des CRA. Hersteller müssen Cybersicherheit dann durchgängig in Entwicklung, Bereitstellung, Pflege und Konformitätsbewertung ihrer Produkte verankern.
Der CRA verlangt eine risikoorientierte Produktgestaltung, geeignete Sicherheitseigenschaften sowie ein systematisches Schwachstellenmanagement inklusive Identifikation, Behebung und Bereitstellung von Updates. Die angemessenen Maßnahmen richten sich nach dem Produktrisiko – etwa bei einer fernzugänglichen Maschinensteuerung im Vergleich zu isolierter Software.
Zudem gewinnen Dokumentation, Nutzerinformationen und Konformitätsbewertung an Bedeutung. Hersteller müssen die Einhaltung der Vorgaben nachvollziehbar belegen; eine nachgeschobene Sicherheitsprüfung vor dem Inverkehrbringen genügt nicht. Entwicklungsentscheidungen, Komponenten, Schnittstellen und Schwachstellenprozesse müssen ineinandergreifen.
Bereits bestehende Meldeprozesse bieten einen guten Ausgangspunkt, um Versionsübersichten und Risikobewertungen mit Updateplanung und Dokumentation zu verknüpfen. Allein erfüllen sie die künftigen Vorgaben jedoch nicht; sie sind lediglich Baustein eines umfassenden Produktsicherheitsmanagements.
Wie unterscheidet sich der CRA von NIS2 und der Maschinenverordnung?
Der CRA regelt die Cybersicherheit von Produkten mit digitalen Elementen. NIS2 richtet sich an erfasste Einrichtungen und ihre Sicherheitsorganisation; die Maschinenverordnung hat einen anderen, maschinenrechtlichen Schwerpunkt.
Diese Regelwerke können denselben industriellen Alltag betreffen, stellen aber unterschiedliche Fragen. Beim CRA lautet sie beispielsweise: Welche Sicherheitsanforderungen muss der Hersteller für eine vernetzte Steuerung erfüllen, und was muss er bei einer aktiv ausgenutzten Schwachstelle im Produkt melden? Die NIS2-Richtlinie betrifft dagegen unter anderem das Risikomanagement und die Meldung erheblicher Sicherheitsvorfälle durch Einrichtungen, die unter ihren Anwendungsbereich und das jeweilige nationale Umsetzungsrecht fallen. In Deutschland gilt das NIS2-Umsetzungsgesetz seit dem 6. Dezember 2025. Ob ein Maschinenhersteller oder Betreiber davon erfasst ist, wird nicht allein durch den Einsatz vernetzter Maschinen entschieden.
Die Maschinenverordnung (EU) 2023/1230 gilt ab dem 20. Januar 2027 und regelt Anforderungen an Maschinen und dazugehörige Produkte. Sicherheitsrelevante digitale Funktionen können dort ebenfalls eine Rolle spielen. Daraus folgt aber weder, dass eine Prüfung nach Maschinenrecht die CRA-Pflichten ersetzt, noch dass eine CRA-Meldung automatisch eine Meldung nach NIS2 ist.
Für die Praxis hilft eine getrennte Zuständigkeitsprüfung: Welches Produkt ist betroffen? In welcher Rolle handelt das Unternehmen – als Hersteller, Betreiber oder beides? Und welcher konkrete Vorfall löst unter welchem Regelwerk eine Pflicht aus? Gerade größere Maschinenbauer können mehrere Rollen gleichzeitig innehaben. Ein gemeinsames Sicherheitsteam kann Hinweise bearbeiten, sollte die rechtlichen Meldewege aber eindeutig auseinanderhalten.
Warum ist die Fernwartung der kritische Punkt?
Fernwartung verbindet Hersteller mit Maschinen im Feld. Sicherheitsereignisse lassen sich jedoch nur dann verlässlich bewerten, wenn Identitäten, Sitzungen und Softwarestände eindeutig zuordenbar sind.
Ein auffälliger Fernzugriff ist zunächst nur ein Signal, keine fertige CRA-Bewertung. Sicherheitsteams müssen nachvollziehen können, wer mit welchen Rechten zugriff, welche Komponenten betroffen sind und was geschah. Zudem gilt es, zwischen Fehlkonfigurationen, Betreiberproblemen und Produktschwachstellen zu unterscheiden. Protokolle und Produktübersichten beschleunigen diesen Prozess.
Unterschiedliche Software- und Steuerungsstände gleicher Maschinentypen erschweren die Eingrenzung zusätzlich. Ein Inventar aus Versionen, Komponenten und Kundenkontakten liefert bei aktiven Angriffen die Entscheidungsgrundlage für gesetzliche Meldepflichten und die Kundenkommunikation.
Ein VPN schützt lediglich den Übertragungskanal, regelt jedoch weder Berechtigungen, noch Sitzungsdetails oder kontrollierte Updates. Da in der OT Verfügbarkeit und Betriebssicherheit Vorrang haben, erfordert sichere Fernwartung neben reinem Zugangsschutz stets klare Zuständigkeiten und geregelte Änderungsprozesse.
Welche Rolle spielt IEC 62443?
Die Normenreihe IEC 62443 strukturiert technische Sicherheitsanforderungen für industrielle Automatisierungs- und Steuerungssysteme. Sie ersetzt jedoch weder die konkrete Produktbewertung noch CRA-Meldepflichten.
Für Maschinenbauer ist sie wegen des Fokus auf industrielle Betriebsbedingungen relevant. Teil IEC 62443-3-3 definiert Sicherheitsanforderungen und Security Levels (z. B. Zugriffskontrolle und Systemintegrität). Entscheidend ist, den Systemumfang und das angestrebte Schutzniveau präzise festzulegen, da ein „Security Level“ isoliert wenig aussagt.
Zertifizierungsnachweise belegen geprüfte Anforderungen, bedeuten jedoch keine automatische CRA-Konformität. Die Verordnung fordert eigenständige Bewertungen und Herstellerpflichten zu Schwachstellenmanagement, Dokumentation und Meldungen. Ein zertifizierter Baustein stützt die Nachweiskette, erfüllt aber nicht stellvertretend alle Pflichten für das Endprodukt.
Wie setzen Hersteller einen belastbaren Meldeprozess auf?
Ein Meldeprozess muss auch dann funktionieren, wenn der erste Hinweis unvollständig ist und mehrere Teams beteiligt sind. Die folgende Checkliste verbindet Feldsignale mit Produktbewertung, Fristen und Nutzerinformation.
- Verantwortliche festlegen: Benennen Sie eine Stelle, die Sicherheitshinweise annimmt und die CRA-Bewertung koordiniert. Produktentwicklung, IT/OT-Security, Service und Kommunikation brauchen definierte Aufgaben sowie Vertretungen. Klären Sie vorab, wer eine Meldung freigibt und wer außerhalb üblicher Arbeitszeiten erreichbar ist.
- Signale bündeln: Führen Sie Hinweise aus Fernwartung, Serviceeinsätzen, Kundenmeldungen, Schwachstelleninformationen und internen Analysen an einem nachvollziehbaren Eingang zusammen. Erfassen Sie den ursprünglichen Hinweis und seine Weitergabe, damit ein sicherheitsrelevantes Signal nicht in einem allgemeinen Serviceticket liegen bleibt.
- Produkte zuordnen: Prüfen Sie betroffene Produktreihen, Komponenten und Softwarestände. Halten Sie fest, welche Ausführungen ausgeliefert wurden und welche Kunden erreicht werden müssen. Bei unsicherer Zuordnung dokumentieren Sie die Annahmen, statt die Prüfung bis zur vollständigen Gewissheit aufzuschieben.
- Meldegegenstand bewerten: Unterscheiden Sie zwischen einer aktiv ausgenutzten Schwachstelle im Produkt und einem schwerwiegenden Sicherheitsvorfall mit Auswirkungen auf dessen Sicherheit. Lassen Sie technische Analyse und regulatorische Einordnung zusammenarbeiten. Nicht jeder Alarm ist meldepflichtig, aber ein möglicher CRA-Fall muss sofort an die zuständige Stelle gelangen.
- Kenntniszeitpunkt und Fristen dokumentieren: Halten Sie fest, wann der Hersteller vom jeweiligen meldepflichtigen Sachverhalt Kenntnis erlangt hat. Planen Sie die unverzügliche Frühwarnung spätestens innerhalb von 24 Stunden und die weitergehende Meldung spätestens innerhalb von 72 Stunden. Vermerken Sie gesondert, welcher Auslöser für den Abschlussbericht gilt.
- Meldung und Nutzerinformation koordinieren: Reichen Sie die erforderlichen Angaben über die einheitliche Meldeplattform ein. Bereiten Sie parallel die Information betroffener Nutzer vor: Welche Produkte sind betroffen, welches Risiko besteht und welche verfügbaren Maßnahmen können es begrenzen? Aussagen an Kunden sollten zum gesicherten Untersuchungsstand passen.
- Abhilfe und Nachweise nachführen: Koordinieren Sie Korrektur- oder Risikominderungsmaßnahmen mit Entwicklung, Service und Betreibern. Reichen Sie den Abschlussbericht fristgerecht ein – bei Schwachstellen spätestens 14 Tage nach Verfügbarkeit der Maßnahme, bei schwerwiegenden Vorfällen binnen eines Monats nach Übermittlung der Vorfallmeldung nach Artikel 14 Absatz 4. Archivieren Sie Meldungen, Entscheidungen und die dazugehörige technische Begründung.
Der Ablauf sollte an einem konkreten Szenario getestet werden. Ein geeigneter Tischtest beginnt etwa mit einer Kundenmeldung zu einer auffälligen Steuerung und endet beim Entwurf der Frühwarnung und der Nachricht an betroffene Betreiber. Dabei zeigen sich häufig ganz praktische Fragen: Ist die installierte Version bekannt? Kann das Sicherheitsteam den zuständigen Produktverantwortlichen erreichen? Und liegen die Kontaktdaten für die Nutzerinformation vor? Solche Lücken lassen sich vor einem echten Vorfall geordneter schließen.
Was sollten Maschinenhersteller jetzt priorisieren?
Der wichtigste Schritt ist ein simulierter Meldefall an einem real ausgelieferten Produkttyp. Er zeigt, ob Hersteller Feldsignale rechtzeitig bewerten und betroffene Maschinen zuordnen können.
Verfolgen Sie dafür an einer vernetzten Maschine einen Sicherheitshinweis vom Serviceeingang bis zur Fristenentscheidung. Prüfen Sie, wer Kenntniszeitpunkte dokumentiert, aktive Ausnutzungen bewertet und Nutzer informiert. Das Ergebnis ist eine konkrete Arbeitsliste für Inventar, Rollen und Kommunikation, die aus der Meldepflicht einen überprüfbaren, zukunftssicheren Prozess macht.
Häufige Fragen zu CRA-Meldepflichten und Maschinen
Die Umsetzung hängt vom Produkt und der Unternehmensrolle ab. Die folgenden Punkte bieten eine Orientierung.
Gilt der CRA auch für Maschinen?
Ja, wenn sie digitale Elemente (z. B. vernetzte Steuerungen oder Software) enthalten. Die Vorgaben gelten jedoch nicht pauschal für jedes Bauteil. Hersteller müssen erfassen, welche Komponenten betroffen sind und welche Rolle sie bei der Bereitstellung einnehmen.
Wer muss melden – Hersteller oder Betreiber?
Die Meldepflichten (Art. 14) liegen allein beim Hersteller. Hinweise von Betreibern ersetzen diese Meldung nicht. Unternehmen, die Maschinen herstellen und zugleich betreiben, müssen beide Rollen strikt trennen.
Was passiert bei Verstößen?
Neben Sanktionen drohen behördliche Anordnungen zur Konformitätsherstellung. Um Fristversäumnisse zu vermeiden, sollten Hersteller Meldeprozesse, Zuständigkeiten und Eskalationswege vorab festlegen sowie Entscheidungen dokumentieren.
Was ist der Unterschied zwischen CRA und NIS2?
Der CRA reguliert Produkte mit digitalen Elementen und deren Hersteller. NIS2 richtet sich an Einrichtungen (Unternehmen) und deren Risikomanagement. Maschinenbauer können unter beide Regelwerke fallen, je nachdem, ob das Produkt oder die Organisation betrachtet wird.
Hilft eine IEC-62443-Zertifizierung bei der CRA-Konformität?
Sie dient als technischer Nachweis für den jeweiligen Prüfbereich, garantiert aber keine vollständige CRA-Konformität. Zusätzliche Pflichten wie Schwachstellenmanagement, Sicherheitsupdates und Meldeprozesse müssen separat erfüllt werden.
Ist Fernwartung per VPN CRA-konform?
Ein VPN sichert nur die Verbindung, belegt aber keine Konformität. Entscheidend ist der Gesamtprozess: Zugriffskontrollen, Produktsicherheit, Schwachstellenbehandlung und die lückenlose Zuordnung von Zugriffen und Softwareständen.
Wann beginnen die Meldefristen?
Für Frühwarnungen und Meldungen (Art. 14) beginnt die Frist ab Kenntniserlangung des Herstellers über einen Vorfall oder eine aktiv ausgenutzte Schwachstelle. Für Abschlussberichte startet sie bei Schwachstellen mit Verfügbarkeit einer Gegenmaßnahme, bei Vorfällen mit Übermittlung der Vorfallmeldung.
Disclaimer: Diesen Blogbeitrag habe ich im Auftrag und im Namen von Klispy veröffentlicht.