Bildquelle: extern
Der Cyber Resilience Act verlagert Produktsicherheit aus dem Release in den gesamten Supportzyklus
Der Cyber Resilience Act, kurz CRA, ist eine EU-Verordnung für Produkte mit digitalen Elementen, also für vernetzte Hardware, Software und relevante Komponenten. Ihr Ziel ist, dass solche Produkte nicht nur beim Verkaufsstart sicherer sind, sondern über ihren gesamten Lebenszyklus mit nachvollziehbaren Sicherheitsmaßnahmen betrieben, gepflegt und bei Problemen gemeldet werden. Relevant ist das, weil die Verordnung Produktsicherheit ausdrücklich mit Support, Schwachstellenbearbeitung und Marktaufsicht verbindet – und damit Themen erfasst, die viele Hersteller bisher eher als nachgelagerte Betriebsaufgaben behandelt haben.
Damit ändert sich für Hersteller, Softwareanbieter und produktnahe Plattformteams die Blickrichtung. Security ist unter dem CRA nicht mehr sauber in „vor Go-live“ und „nach Go-live“ zu trennen. Wer ein Produkt auf den EU-Markt bringt, muss schon vor der Vermarktung nachweisen, wie Risiken bewertet, Sicherheitsanforderungen umgesetzt und Konformität dokumentiert wurden. Gleichzeitig muss dasselbe Unternehmen später Updates liefern, Schwachstellen aktiv behandeln, Supportzeiträume benennen und meldepflichtige Ereignisse in engem Zeitfenster an die zuständigen Stellen geben.
Gerade deshalb ist der CRA für IT-Management so interessant. Die Verordnung trifft nicht nur klassische Gerätehersteller, sondern auch Anbieter von Softwareprodukten, eingebetteten Komponenten und digitalen Lieferketten. In vielen Organisationen liegen Entwicklung, Produktmanagement, Support, Incident Response und Rechts-/Compliance-Funktionen aber noch in getrennten Taktungen. Der CRA macht diese Trennung riskanter, weil die Nachweis- und Reaktionspflichten nur funktionieren, wenn Produktakte, Komponentenwissen, Supportversprechen und Meldewege zusammenpassen.
Warum der CRA mehr als ein neues CE-Etikett ist
Wer den CRA nur als zusätzliche Zertifizierungs- oder Kennzeichnungspflicht liest, unterschätzt seine operative Reichweite. Die Kommission beschreibt ausdrücklich, dass Hersteller entlang der gesamten Lieferkette für Sicherheitsresultate verantwortlich sind. Das betrifft finale Produkte wie Apps, Plattformsoftware oder vernetzte Geräte ebenso wie Komponenten etwa Chips, Betriebssysteme und andere digitale Bausteine. Der eigentliche Hebel ist also nicht das CE-Zeichen selbst, sondern die Pflicht, Sicherheitsanforderungen über Planung, Entwicklung, Auslieferung und Wartung hinweg belastbar umzusetzen.
In der Praxis heißt das: Ein Produktteam kann Sicherheit nicht mehr allein als Release-Gate organisieren. Wenn die Architektur zwar zum Verkaufsstart plausibel wirkt, später aber keine saubere Update-Logik, keine Verantwortlichkeit für Schwachstellen oder keinen klaren Supportzeitraum hat, fehlt ein wesentlicher Teil der CRA-Fähigkeit. Genau an dieser Stelle wird der CRA für viele Hersteller zur Betriebsfrage. Nicht, weil Betrieb und Entwicklung verschmelzen müssten, sondern weil beide Seiten denselben Produktlebenszyklus absichern müssen.
Vor dem Inverkehrbringen beginnt bereits die Dauerarbeit
Auf der Herstellerseite beginnt der CRA mit einer Risikobewertung. Darauf aufbauend müssen die wesentlichen Cybersicherheitsanforderungen umgesetzt, technisch dokumentiert und in einer passenden Konformitätsbewertung belegt werden. Erst danach folgen CE-Kennzeichnung, Konformitätserklärung, Nutzungsinformationen und die Angabe des Supportzeitraums. Diese Abfolge ist wichtig, weil sie verhindert, dass Sicherheitszusagen nur als Marketingaussage formuliert werden.
Für Produktverantwortliche bedeutet das eine unangenehme, aber gesunde Verschiebung: Der angekündigte Supportzeitraum wird selbst zu einer verbindlichen Betriebszusage. Wer drei, fünf oder mehr Jahre Unterstützung ausweist, muss intern schon heute wissen, wie Updates ausgeliefert, bekannte Schwachstellen priorisiert, Altversionen beobachtet und Abhängigkeiten bewertet werden. Der CRA koppelt den Markteintritt damit an Fähigkeiten, die früher oft erst nach dem Verkauf improvisiert wurden.
Besonders relevant ist das für Anbieter, deren Produkte auf vielen zugekauften Komponenten, Bibliotheken, Cloud-Diensten oder Embedded-Bausteinen beruhen. Rein formal kann ein Hersteller zwar einzelne Teile beziehen, die Gesamtverantwortung für das Produkt verschwindet dadurch aber nicht. Ohne belastbare Übersicht über verwendete Komponenten, Release-Stände, Lieferantenbeziehungen und Updatepfade wird deshalb schon die technische Dokumentation schnell brüchig. Ein explizites Schlagwort wie SBOM ist dabei nicht einmal der Kernpunkt. Entscheidend ist, dass ein Hersteller jederzeit erklären kann, was im Produkt steckt, welche Schwachstellenlage dazu bekannt ist und wie Korrekturen tatsächlich in den Support gelangen.
Schwachstellenmanagement wird zur Produktfunktion
Viele Unternehmen behandeln Schwachstellenmanagement bis heute als Querschnittsprozess des SOC, der IT-Sicherheit oder eines PSIRT. Unter dem CRA bleibt das fachlich richtig, reicht organisatorisch aber nicht mehr aus. Die Verordnung verlangt, dass Hersteller Schwachstellen während des angegebenen Supportzeitraums behandeln. Damit wird Vulnerability Handling zu einem festen Bestandteil der Produktverantwortung und nicht nur zu einer Spezialdisziplin im Sicherheitsbereich.
Das hat mehrere Folgen. Erstens braucht jedes Produkt eine klare Ownership dafür, wer eingehende Hinweise bewertet, ob eine Schwachstelle das eigene Produkt tatsächlich betrifft und wie Priorisierung, Patch-Entwicklung und Kundenkommunikation zusammenlaufen. Zweitens müssen Support und Entwicklung dieselben Produktstände sehen. Wenn der Kundensupport nicht weiß, welche Versionen noch unterstützt werden, oder wenn Entwicklungsteams ihre Komponentenstände nicht sauber nachvollziehen können, werden Reaktionsfristen schnell zum Glücksspiel. Drittens braucht es einen realistischen Umgang mit Fremdkomponenten. Eine Bibliothek, ein Chip oder ein Container-Base-Image ist unter dem CRA kein externer Sonderfall, sondern Teil der eigenen Risikorechnung.
Genau hier kippt das Thema oft vom Compliance-Projekt in die operative Realität. Viele Hersteller haben zwar Ticketing, Advisories und Patch-Mechaniken, aber keine durchgehende Verbindung zwischen Produktakte, Komponentenübersicht, Supportmatrix und Kundenkommunikation. Unter dem CRA wird diese Lücke sichtbar, weil eine Schwachstelle nicht mehr nur technisch behoben, sondern auch regulatorisch nachvollziehbar gehandhabt werden muss.
Meldewege werden enger getaktet als viele Produktorganisationen heute arbeiten
Ab dem 11. September 2026 greifen die CRA-Meldepflichten für aktiv ausgenutzte Schwachstellen und schwere Vorfälle. Laut EU-Kommission ist dann eine Frühwarnung innerhalb von 24 Stunden nach Kenntnis erforderlich, eine weitergehende Meldung innerhalb von 72 Stunden und ein Abschlussbericht später je nach Fall – bei aktiv ausgenutzten Schwachstellen spätestens 14 Tage nach verfügbarer Korrekturmaßnahme, bei schweren Vorfällen innerhalb eines Monats nach der Erstmeldung.
Hinzu kommt, dass Hersteller diese Meldungen nicht mehr an verschiedene Stellen einzeln verteilen sollen. Dafür wird die Single Reporting Platform aufgebaut, die ENISA betreibt. Sie leitet Meldungen an das zuständige koordinierende CSIRT und grundsätzlich gleichzeitig an ENISA weiter. Für die Hersteller klingt das zunächst nach Vereinfachung, praktisch erhöht es aber den Druck auf die internen Vorstufen. Denn eine Plattform ersetzt keine saubere Entscheidung darüber, was überhaupt meldepflichtig ist, welche Fakten bereits belastbar vorliegen und wer die Freigabe für eine 24-Stunden-Warnung erteilt.
Produktteams, Security, Support und Management müssen deshalb dieselbe Uhr sehen. Wer eine aktiv ausgenutzte Schwachstelle erst nach langer interner Diskussion sauber klassifizieren kann, hat das eigentliche Problem schon vor der Plattform. Der CRA belohnt also nicht die schönste Meldemaske, sondern kurze Wege zwischen Erkennung, Bewertung, Entscheidung und externer Meldung.
Auch Softwareanbieter ohne klassische Gerätefertigung sind betroffen
Ein häufiger Denkfehler lautet, der CRA sei vor allem ein Thema für IoT-Hardware, Industrieanlagen oder Consumer-Elektronik. Tatsächlich macht die Kommission aber klar, dass auch Softwareprodukte und relevante Komponenten erfasst werden. Für viele europäische Softwareanbieter ist das brisant, weil ihre Organisationen historisch nicht wie klassische Produkthersteller strukturiert wurden. Sie haben starke Release-Prozesse, aber schwächere Langzeit-Supportmodelle. Oder sie liefern SaaS-nahe Komponenten, deren Sicherheits- und Updateverantwortung vertraglich diffus verteilt ist.
Gerade dort lohnt ein nüchterner Blick auf die eigenen Produktgrenzen. Welche Komponente gilt wirklich als eigenes Produkt mit digitalem Element? Wo endet die Verantwortung am eigenen Code – und wo gerade nicht, weil ein Paket, Agent, Connector oder Client aktiv auf dem Markt bereitgestellt wird? Der CRA zwingt Unternehmen dazu, diese Grenzen nicht nur juristisch, sondern operativ zu klären. Sonst entstehen später Widersprüche zwischen Vertriebsversprechen, Supportdokumentation, Sicherheitsmeldungen und Konformitätsunterlagen.
Was Hersteller und produktnahe IT-Teams jetzt konkret vorbereiten sollten
- Produktinventar schärfen: Klären, welche Produkte, Komponenten und Varianten tatsächlich in den CRA-Anwendungsbereich fallen.
- Supportzeiträume belastbar definieren: Keine vagen Marketingangaben, sondern realistische Zusagen mit Budget, Personal und Updatepfad hinterlegen.
- Komponenten- und Abhängigkeitswissen absichern: Bibliotheken, Embedded-Bausteine, Images, Drittmodule und Versionen nachvollziehbar führen.
- PSIRT, Support und Entwicklung koppeln: Schwachstellenbearbeitung braucht gemeinsame Sicht auf Betroffenheit, Priorität, Patch und Kundenkommunikation.
- Meldeworkflow vor dem Stichtag testen: Frühwarnung in 24 Stunden ist nur realistisch, wenn Rollen, Eskalation und Freigabe bereits geübt wurden.
- Technische Dokumentation nicht als Schlussarbeit behandeln: Sie muss aus echten Produkt- und Betriebsdaten entstehen, nicht aus nachträglicher Textproduktion.
Unternehmen, die diese Punkte früh angehen, gewinnen mehr als bloße Regeltreue. Sie schaffen auch intern ein robusteres Bild darüber, welche Produkte noch tragfähig unterstützt werden, wo Lieferkettenrisiken liegen und wie schnell Sicherheitsprobleme tatsächlich in Kundenwirkung übersetzt werden. Genau das macht den CRA strategisch interessanter als viele klassische Compliance-Themen.
Fazit
Der Cyber Resilience Act verschiebt Produktsicherheit von einem punktuellen Release-Thema in einen dauerhaft nachweisbaren Support- und Reaktionszyklus. Für Hersteller und Softwareanbieter ist das unbequem, aber sinnvoll: Risikobewertung, technische Dokumentation, Supportzusage, Schwachstellenbehandlung und Meldung werden endlich als zusammenhängende Produktverantwortung gelesen.
Wer den CRA jetzt nur als spätere Marktaufsichtspflicht ablegt, wird spätestens bei Supportdauer, Fremdkomponenten und Meldefristen unter Druck geraten. Wer ihn dagegen als Anlass nimmt, Produktakte, Supportmodell, Incident- und Vulnerability-Prozesse zusammenzuführen, kann nicht nur regulatorische Reife gewinnen, sondern auch das eigene Sicherheitsversprechen glaubwürdiger machen.
