Der CRA betrifft das Produktgeschäft, nicht nur das Security-Team
Warum der Cyber Resilience Act mehr ist als eine Cybersecurity-Vorschrift: Er berührt Marktzugang, Produktstrategie, Lieferkette und Time-to-Market.
Der Cyber Resilience Act (CRA) wird oft als Cybersecurity-Regulierung besprochen. Diese Sicht ist zu klein. Der CRA richtet sich nicht in erster Linie an das Security-Team, sondern an das Produktgeschäft eines Unternehmens. Diesen Fehler sehe ich noch immer zu häufig.
Warum reicht die reine Sicherheitssicht nicht aus?
Weil Cybersicherheit durch den CRA mit mehreren Themen verbunden wird, die weit über die IT-Sicherheit hinausgehen: CE-Kennzeichnung, technische Dokumentation, Umgang mit Schwachstellen, Supportzeiträume, Konformitätsbewertung und Verantwortung über den gesamten Lebenszyklus eines Produkts.
Sobald diese Punkte zusammenkommen, ist es nicht mehr nur eine technische Frage. Es wird zu einer Frage des Marktzugangs. Es wird zu einer Frage der Produktstrategie. Es wird zu einer Frage der Lieferkette. Und für viele Unternehmen kann es zu einer Frage der Time-to-Market werden.
Wen betrifft das konkret?
Besonders betroffen sind Hersteller, Unternehmen mit eingebetteten Produkten, IoT-Anbieter, Zulieferer der Industrieautomation, Softwareanbieter und Engineering-Teams, die mit Produkten mit digitalen Elementen arbeiten. Der Kreis ist also weit gezogen: Er reicht vom Hersteller vernetzter Geräte bis zum Softwareanbieter, und er schließt die Teams ein, die diese Produkte entwickeln.
Ist 2027 der eigentliche Startpunkt?
Nein. 2027 ist nicht die eigentliche Startlinie. Die Meldepflichten nach Artikel 14 gelten seit dem 11. September 2026. Das ist der unbequeme Teil, denn die Vorbereitung musste damit vor dem Jahr beginnen, das viele im Kopf haben.
Was Unternehmen bis dahin können müssen, lässt sich in fünf Fragen fassen:
- Was ist in unseren Produkten enthalten?
- Welche Komponenten setzen wir ein?
- Wie gehen wir mit Schwachstellen um?
- Wer ist für diesen Prozess verantwortlich?
- Wie entstehen die Nachweise dafür?
Alle fünf Fragen betreffen das Produkt als Ganzes und nicht nur einzelne Sicherheitsfunktionen. Wer sie beantworten will, muss wissen, wie ein Produkt aufgebaut ist, wie es gepflegt wird und wer dafür einsteht.
Was bedeutet das für die Organisation?
Der CRA sollte nicht als Papierarbeit behandelt werden. Er sollte auch nicht als Thema gelten, um das sich die Security schon kümmern wird. Er wird zu einer Aufgabe der gesamten Produktorganisation, denn die Antworten auf die fünf Fragen liegen nicht an einer einzigen Stelle.
Meine Einschätzung: Unternehmen, die das früh verstehen, werden ein ganz anderes 2027 erleben als Unternehmen, die abwarten. Der Unterschied liegt darin, ob die Fragen nach Komponenten, Schwachstellen, Verantwortung und Nachweisen früh gestellt wurden.
Warum spreche ich vom Produktgeschäft?
Weil dort die Folgen sichtbar werden. Wenn die CE-Kennzeichnung an die Cybersicherheit gekoppelt ist, hängt die Verkaufsfähigkeit eines Produkts davon ab, wie sauber diese Themen im Produktprozess behandelt wurden. Ein Produkt, dessen Dokumentation, Schwachstellenbehandlung und Supportplanung nicht stehen, kann den Zeitplan der Markteinführung verändern. Das ist der Grund, warum ich den CRA als Thema für die Geschäftsführung und die Produktverantwortlichen sehe und nicht allein für die Sicherheitsabteilung.
Wer mit dieser Perspektive beginnt, stellt zuerst die Fragen nach Komponenten, Prozess und Verantwortung. Die Frage nach Werkzeugen kommt danach.
Was ist die kurze Fassung?
Der CRA ist keine Frage, die ein Security-Team allein beantwortet. Er verbindet Technik mit Marktzugang, Dokumentation, Lieferkette und Lebenszyklus eines Produkts. Deshalb gehört er dorthin, wo über das Produkt entschieden wird.