Cyber Resilience Act: Warum Produktsicherheit in die Entwicklung gehört

Seit dem 11. September 2026 müssen Hersteller vernetzter Produkte aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle innerhalb von 24 Stunden melden. Am 11. Dezember 2027 folgen alle übrigen Anforderungen des Cyber Resilience Act (CRA). Ab dann drohen bei Verstößen Bußgelder von bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes. (BSI: Cyber Resilience Act)

Die Zeit bis dahin klingt komfortabel. Sie ist es nicht, wenn Zuständigkeiten, Prozesse und Know-how erst noch aufgebaut werden müssen. Und genau das ist bei vielen Herstellern der Fall.

Der CRA ist ein Produktthema, kein IT-Thema

Mit NIS2 haben viele Unternehmen gelernt, Informationssicherheit zu organisieren. Der Informationssicherheitsbeauftragte oder der CISO kümmert sich, häufig angesiedelt in der IT. Naheliegend, den CRA einfach dazuzulegen. Nur passt das nicht.

Der CRA regelt die Sicherheit von Produkten mit digitalen Elementen. Er betrifft also das, was ein Unternehmen entwickelt und verkauft, nicht die eigene Infrastruktur. Damit gehört er zum CTO, zur Entwicklungsleitung und in die Entwicklungsteams. Prof. Dr. Dominik Merli von der Technischen Hochschule Augsburg hat das im Podcast Cybersecurity Basement klar formuliert: Die IT betreibt Infrastruktur und hat in der Produktentwicklung eigentlich nichts zu sagen. Ihr Know-how, etwa zu Kryptografie, kann Entwicklungsteams trotzdem helfen.

Entscheidend ist, dass jemand in der Entwicklung die Verantwortung für Security übernimmt. Manche Unternehmen schaffen dafür eine eigene Rolle: den Product Security Officer. Er treibt Security in den Entwicklungsprozessen voran und ist damit näher am Produkt als ein klassischer ISB.

Embedded Systems brauchen individuelle Antworten

Ein Server oder eine Cloud-Umgebung folgt Standards. Eine Maschinensteuerung dagegen ist oft eine Eigenentwicklung: eigene Platine, unterschiedliche Chips, mal mit Linux, mal ganz ohne Betriebssystem, manchmal mit integrierten Safety-Funktionen. Pauschale Sicherheitsrezepte greifen hier nicht.

Wie konkret die Fragen werden, zeigt das Beispiel Fernwartung.

• Kann das Gerät über TLS kommunizieren?

• Reicht die Rechenleistung für Kryptografie?

• Und kann sich das Gerät überhaupt eindeutig ausweisen, etwa über ein Zertifikat und einen Private Key?

Gerade das Identitätsmanagement wird laut Merli von vielen Herstellern bisher eher stiefmütterlich behandelt. Wer Anlagen betreibt, kennt zusätzlich die OT-typischen Hürden: knappe Wartungsfenster, eingeschränkte Patchbarkeit und Protokolle, mit denen klassische IT-Tools wenig anfangen können. Ein Netzwerkscan im laufenden Betrieb kann im Zweifel mehr Schaden anrichten als nutzen.

Die Risikoanalyse klärt erst die Risiken, dann die Maßnahmen

Der CRA verlangt eine Bewertung der Cybersicherheitsrisiken für jedes Produkt. Der Einstieg ist ein gemeinsames Systemverständnis: Was macht das Produkt, aus welchen Komponenten besteht es, wo wird es eingesetzt? Im Behördenumfeld, im Kraftwerk oder beim Privatkunden ergeben sich völlig unterschiedliche Bedrohungen.

Dann wird es interdisziplinär. Neben der Entwicklung bringen Geschäftsführung, Safety-Verantwortliche, Support und Service jeweils ihre eigene Perspektive ein. Geht die größere Gefahr von Spionage aus oder von Sabotage? Welche Funktionen dürfen auf keinen Fall ausfallen? Was passiert beim Kunden, wenn die Maschine angegriffen wird?

Eine verbreitete Fehlannahme: Am Ende der Analyse liegt ein fertiger Maßnahmenplan auf dem Tisch. Ihr Zweck ist zunächst, die relevanten Risiken zu identifizieren. Erst darauf aufbauend lassen sich Schutzmaßnahmen sinnvoll priorisieren. Fünf Standardmaßnahmen, die jedes Gerät sicher machen, gibt es nicht. Merli schilderte im Podcast, dass so eine Analyse mit mehreren Tagen Aufwand verbunden ist und ein erster Stand in ein bis zwei Wochen erreichbar ist.

Schwachstellenmanagement ist mehr als eine Mailadresse

Der CRA verpflichtet Hersteller, Schwachstellen zu untersuchen, zu bewerten und zeitnah Updates bereitzustellen. Aktiv ausgenutzte Schwachstellen müssen über eine zentrale Meldeplattform an das zuständige nationale CSIRT gemeldet werden: als Frühwarnung innerhalb von 24 Stunden, mit einer Meldung innerhalb von 72 Stunden und einem Abschlussbericht spätestens 14 Tage nach Bereitstellung einer Korrekturmaßnahme. (Europäische Kommission: Cyber Resilience Act – Reporting obligations)

Das setzt voraus, dass Hinweise überhaupt ankommen. Ein einfacher erster Schritt ist eine security.txt auf der Website, die zeigt, wohin Sicherheitsforscher, Kunden oder Partner gefundene Lücken melden können. Ein Meldeweg allein reicht aber nicht. Im Podcast berichtet Merli von einem multinationalen Konzern, der zwar ein gutes Meldeformular hatte, dann aber monatelang nicht reagierte. Bis zum Patch verging nach mehrfachem Nachhaken und unter Einbeziehung des BSI ein Jahr.

Wichtig ist auch die Haltung. Eine gemeldete Schwachstelle ist kein Skandal, sondern Alltag. Problematisch wird es erst, wenn sie nicht ernst genommen wird oder kein Prozess existiert, der sie behebt.

Die Selbsterklärung ist schnell unterschrieben und trotzdem angreifbar

Für die meisten Produkte reicht beim CRA eine Konformitätsbewertung durch den Hersteller selbst. Für wichtige und kritische Produkte müssen je nach Kategorie externe Stellen eingebunden werden. Eine eigene CRA-Kennzeichnung gibt es nicht. Die Anforderungen fließen in die CE-Kennzeichnung ein.

Die Versuchung, eine Selbsterklärung schnell auszufüllen, ist groß, besonders wenn unklar ist, was Risikoanalyse und Schwachstellenmanagement leisten müssen. Wer selbst viel in Prozesse, Dokumentation und Schutzmaßnahmen investiert hat, wird kaum tatenlos zusehen, wie ein Konkurrent mit deutlich weniger Aufwand dasselbe CE-Kennzeichen trägt. Meldungen an Behörden und Nachfragen zur technischen Dokumentation sind dann eine realistische Folge.

Ich gehe fest davon aus, dass wir da das ein oder andere Negativbeispiel sehen werden, an dem klar wird: Wenn man keine Mindeststandards erfüllt, dann hat man auf dem europäischen Markt auch nichts verloren.

Prof. Dr. Dominik Merli, Technische Hochschule Augsburg

Verantwortung lässt sich nicht auslagern

Externe Partner können Methodik mitbringen, Workshops moderieren und Know-how aufbauen. Welche Maßnahmen in einem Produkt umsetzbar sind und wie sie in den Entwicklungsprozess passen, entscheidet aber das Unternehmen selbst. Der CRA verlangt deshalb vor allem eines: interne Prozesse, die auch nach dem ersten Audit tragen.

Der Einstieg muss dabei nicht teuer sein. Merli empfahl im Podcast, die drei, vier wichtigsten Köpfe im Unternehmen für zwei bis drei Stunden zusammenzuholen und ein Szenario durchzuspielen: Was könnte uns passieren? Welche Folgen hätte ein Angriff für unsere Produkte, Anlagen und Maschinen? Einmal im Jahr wiederholt, für das Unternehmen und für jedes Produkt, ist das ein solides Fundament für alles, was der CRA verlangt.

Das ganze Gespräch im Podcast

Wie aus einer Schnapsidee ein Rap über den Cyber Resilience Act wurde, wie das Förderprojekt OT-CRAft KMU beim CRA unterstützt und was Dominik Merli sonst noch über OT-Security und Security by Design erzählt, gibt es in der aktuellen Folge von Cybersecurity Basement: