Die meisten Hersteller von Industriegeräten und Maschinenbauer sind sich dessen noch nicht bewusst, aber der Cyber Resilience Act (CRA) verändert grundlegend, was es heute bedeutet, vernetzte industrielle Produkte zu entwickeln und auf den Markt zu bringen.
Nicht, weil Cybersicherheit neu ist, sondern weil CRA langfristige Verantwortlichkeiten für alle digitalen Elemente formalisiert, die in Industrieanlagen eingebettet sind, und klare Erwartungen an die CRA-Konformität für vernetzte Industriegeräte stellt. Als EU-Verordnung gilt die CRA für alle Produkte mit digitalen Elementen, die auf dem europäischen Markt in Verkehr gebracht werden, unabhängig davon, wo sie hergestellt werden¹.
Und hier ist die unbequeme Wahrheit: Wenn Sie die Konnektivität in Ihrem Gerät entwickeln, besitzen oder mit einem Branding versehen, sind Sie laut CRA voll dafür verantwortlich, nachzuweisen, dass es während seines gesamten Lebenszyklus sicher, aktualisierbar und ordnungsgemäß gewartet ist.
Wie diese Verantwortung in der Praxis aussieht, erklärt dieser Artikel und beantwortet eine Frage, die sich viele Hersteller jetzt stellen: Was bedeutet CRA eigentlich für Unternehmen, die ihre eigene Konnektivität aufbauen?
Abbildung 1. CRA-Verantwortungskette – wer Konnektivität besitzt oder unter eigenem Namen vertreibt, trägt die CRA-Haftung.
CRA gilt für "Produkte mit digitalen Elementen", d. h. Hardware und Software, die über eine direkte oder indirekte Netzwerkkonnektivität verfügen oder diese ermöglichen. Dazu gehören eingebettete Kommunikationsschnittstellen, Protokollstacks, Funkmodule, Gateways oder kundenspezifische Konnektivitätslösungen.
Neu ist nicht, dass die Konnektivität Überlegungen zur Cybersicherheit mit sich bringt. Es ist so, dass CRA die Konnektivität als regulierten Teil des Produkts behandelt, der im Laufe der Zeit gesichert, dokumentiert und gewartet werden muss.
In der Praxis bedeutet das:
Auch wenn in der Branche teils diskutiert wird, dass sich Termine verschieben könnten, sind die CRA-Fristen klar definiert:
Abbildung 2. Wichtige CRA Fristen
Die harmonisierten Normen werden noch ausgearbeitet, aber die Entwicklung schreitet voran, und es gibt derzeit keine starken Anzeichen dafür, dass der Termin 2027 verschoben wird.
Abbildung 3. Der derzeitige Entwicklungsstand der harmonisierten Normen und der unterstützenden Dokumente, von denen erwartet wird, dass sie die Konformität der Ratingagenturen untermauern.
Eine der häufigsten Fragen, die wir hören, lautet: Welche Sicherheitsanforderungen führt die CRA für Gerätehersteller und Maschinenbauer ein?
Die kurze Antwort ist, dass CRA weit über die Verbesserung der Cybersicherheit hinausgeht. Sie führt verbindliche Sicherheits- und Lebenszyklusanforderungen ein, die so lange gelten, wie das Gerät auf dem Markt ist, oft 10 bis 15 Jahre oder länger.
Abbildung 4. CRA Sicherheitsanforderungen
Diese Anforderungen sind formal, evidenzbasiert und prüfungspflichtig². Der CRA verlangt:
Hersteller müssen nachweisen, dass die Konnektivität in ihrem Produkt im Rahmen eines strukturierten, wiederholbaren und auditierbaren Sicherheitsprozesses entwickelt und betrieben wird. Informelle oder ad-hoc Vorgehensweisen reichen nicht aus.
Der CRA verlangt fortlaufende Prozesse für:
Diese Verantwortung endet nicht mit der Markteinführung, sondern gilt über die gesamte Betriebsdauer des Produkts hinweg.
Hersteller müssen Folgendes dokumentieren:
Dies wird besonders schwierig, wenn Konnektivitäts-Stacks älteren oder übernommenen Code enthalten.
Der CRA verlangt dauerhaft verfügbare Nachweise, darunter:
Für viele gibt es diese Art der Dokumentation für interne Konnektivitäts-Stacks bislang nicht.
Der CRA führt strenge Konsequenzen ein:
Die Einhaltung des CRA ist längst nicht mehr nur eine regulatorische Pflicht – sie wird zunehmend zur Anforderung von Kunden.
Abbildung 5. Folgen der Nicht-Einhaltung
Ein häufiger Irrtum ist die Annahme, dass bestehende interne Cybersecurity-Praktiken den CRA-Anforderungen entsprechen. Viele Teams fragen sich auch: Wie wirkt sich der CRA auf interne Konnektivitätslösungen aus, die vor Jahren entwickelt wurden?
Tatsächlich reichen informelle oder ad-hoc Sicherheitsmaßnahmen nicht aus, da der CRA Folgendes verlangt:
Viele Gerätehersteller und Maschinenbauer unterschätzen die Lücke zwischen ihrem aktuellen Ansatz und den strengen CRA-Anforderungen. Dies gilt insbesondere dann, wenn auf veraltete Protokoll-Stacks, nicht gewartete Open-Source-Komponenten oder undokumentierte Integrationen gesetzt wird.
Basierend auf jahrzehntelanger Erfahrung in der Unterstützung von Geräteherstellern und Maschinenbauern bei der Integration von Kommunikationstechnologien beobachtet HMS Networks häufig zwei Hauptkategorien von Schwachstellen bei der Vorbereitung auf den CRA: blinde Flecken in der eigenen Konnektivität sowie blinde Flecken im Zusammenhang mit Drittanbietern.
Beide Bereiche führen zu erheblichen Herausforderungen bei der Einhaltung der langfristigen Sicherheits- und Lebenszyklusanforderungen des CRA.
Veraltete Protokoll-Stacks
Viele wurden vor Jahren entwickelt, verfügen nicht über moderne Sicherheitsmechanismen und lassen sich nur schwer auf heutige Standards bringen.
Nicht gewartete Open-Source-Abhängigkeiten
Konnektivitäts-Stacks enthalten häufig Open-Source-Komponenten, die nun dokumentiert, überwacht und regelmäßig aktualisiert werden müssen.
Kein formaler Prozess für den Umgang mit Schwachstellen
Teams beheben Probleme oft situativ, doch der CRA verlangt einen dokumentierten und kontinuierlichen Prozess.
Begrenzte langfristige Wartbarkeit
Interne Konnektivitätslösungen hängen häufig von einzelnen Personen oder veralteten Codebasen ab, die den Update-Anforderungen über 10–15 Jahre nicht gerecht werden.
Diese blinden Flecken sind nachvollziehbar: Konnektivität wurde lange eher als funktionale Anforderung betrachtet – nicht als Thema der industriellen Cybersicherheit.
Der CRA verpflichtet Gerätehersteller und Maschinenbauer sicherzustellen, dass in ihren Produkten eingesetzte Hardware und Software von Drittanbietern die Sicherheitsanforderungen erfüllen. Dies wird oft unterschätzt und kann zu einer der größten Herausforderungen bei der CRA-Konformität werden.
Hardware-Abhängigkeiten
Der CRA gilt für alle Hardwarekomponenten, die die Produktsicherheit beeinflussen können, einschließlich Mikrocontrollern und Secure Elements. Viele ältere Komponenten wechseln in den „Spare-Part-Lifecycle“ und sind dann vom CRA ausgenommen. In diesem Fall geht die gesamte Sicherheitsverantwortung auf den Gerätehersteller über.
Hersteller benötigen daher zunehmend eine CRA-Konformitätserklärung von ihren Hardware-Lieferanten.
Software-Abhängigkeiten
Auch Betriebssysteme, Protokoll-Stacks und eingebettete Bibliotheken müssen über CRA-Konformitätserklärungen verfügen. Fehlen diese, ist der Gerätehersteller für das Monitoring von Schwachstellen, das Bereitstellen von Patches und die Sicherstellung der Sicherheit über den gesamten Lebenszyklus verantwortlich – selbst wenn kein Zugriff auf den Quellcode besteht.
Warum Lieferanten wichtiger denn je sind
Drittanbieter-Software und -Hardware können zum größten Hindernis für die CRA-Konformität werden. Selbst wenn der eigene Code den Anforderungen entspricht, können nicht konforme Komponenten von Lieferanten die Gesamtzulassung verhindern.
Abbildung 6. Lieferantenbezogene CRA-Schwachstellen: Wenn Hardware oder Software von Drittanbietern keine Konformitätserklärung besitzt, geht die Verantwortung für Sicherheit, Updates und Compliance vollständig auf den Hersteller über.
Wenn Sie sich fragen, was der Cyber Resilience Act für Ihre langfristigen Verantwortlichkeiten in der Konnektivität bedeutet, lautet die Antwort: Er schafft verbindliche Anforderungen an Sicherheit, Wartung und Dokumentation, die Gerätehersteller und Maschinenbauer nicht länger ignorieren können.
Letztlich muss jeder Hersteller eine zentrale strategische Frage beantworten:
Wer ist für die CRA-Konformität in Ihrem vernetzten Gerät verantwortlich – Sie oder Ihre Lieferanten?
Der CRA zwingt Hersteller, Konnektivität neu zu denken. Es geht nicht mehr nur darum, ein Gerät mit einem Netzwerk zu verbinden, sondern darum, langfristige Sicherheit, Dokumentation und Lebenszyklusverantwortung zu übernehmen und nachzuweisen.
Daraus ergibt sich die nächste Frage:
Möchten Sie wirklich sämtliche Sicherheits-, Wartungs- und Compliance-Verpflichtungen übernehmen, die mit der Entwicklung und Vermarktung eigener Konnektivität einhergehen?
Im nächsten Artikel gehen wir darauf näher ein: „Why CRA is painful, but necessary“, in dem wir versteckte Kosten, organisatorische Herausforderungen und die Vorteile dieses Wandels für das industrielle Ökosystem beleuchten.
Unabhängig davon, ob Sie bestehende Geräte aktualisieren oder neue entwickeln – die richtige Konnektivitätsstrategie ist entscheidend für die CRA-Readiness. Erfahren Sie mehr über den Cyber Resilience Act und entdecken Sie Anybus-Gateway- und Embedded-Lösungen, mit denen Sie sichere, wartbare und zukunftsfähige Geräte entwickeln können.
Dr. Jens Jakobsen
Product Security Manager, HMS Networks
Dr. Jens Jakobsen ist Product Security Manager bei HMS Networks und verantwortet dort die Stärkung der Cybersicherheit für industrielle Kommunikationsprodukte sowie den Schutz vernetzter Systeme vor neuen Bedrohungen. Er verfügt über umfangreiche Erfahrung aus technischen und leitenden Positionen bei HMS Networks, Schneider Electric und Motorola Solutions und ist seit vielen Jahren im Bereich industrielle Kommunikation und Cybersicherheit tätig. Dr. Jakobsen hält sieben erteilte Patente im Bereich Telekommunikation und industrielle Kommunikationstechnologien.
Referenzen
1. Europäische Union – Verordnung (EU) 2024/2847 (Gesetz über Cyberresilienz) https://eur-lex.europa.eu/eli/reg/2024/2847/oj
2. Europäische Kommission – Der "Blaue Leitfaden" zur Umsetzung der EU-Produktvorschriften (2022) https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:C:2022:247:TOC
