Der Cyber Resilience Act verändert nicht primär die Rechtsabteilung, sondern die Art, wie Du digitale Produkte entwickelst, absicherst und betreibst. Wer CRA Compliance umsetzen will, muss Security-Anforderungen in Produktentscheidungen, Release-Prozesse und Lieferketten integrieren. Ein Dokumentationsprojekt kurz vor dem Marktstart wird dafür nicht reichen.
Die Verordnung (EU) 2024/2847 ist seit Dezember 2024 in Kraft. Die meisten Pflichten gelten ab dem 11. Dezember 2027. Für Meldepflichten bei aktiv ausgenutzten Schwachstellen und schweren Sicherheitsvorfällen gilt bereits der 11. September 2026. Das lässt wenig Raum für eine rein reaktive Vorbereitung – besonders dort, wo Entwicklung, Produktmanagement, Einkauf und Security bislang mit getrennten Datenständen arbeiten.
CRA Compliance umsetzen beginnt mit dem richtigen Scope
Der CRA richtet sich an Produkte mit digitalen Elementen, die in der EU auf den Markt gebracht werden. Erfasst sind Hardware- und Softwareprodukte einschließlich ihrer Komponenten sowie bestimmte Lösungen zur Fern-Datenverarbeitung, wenn diese für die Funktion eines Produkts erforderlich sind. Entscheidend ist also nicht, ob ein Produkt physisch ausgeliefert wird, sondern welche digitale Funktion es bereitstellt und wer sie verantwortet.
Für viele Unternehmen ist die erste Hürde die Herstellerrolle. Hersteller ist nicht nur, wer Hard- oder Software selbst entwickelt. Die Rolle kann auch übernehmen, wer ein Produkt unter eigenem Namen vermarktet oder eine wesentliche Änderung vornimmt. Importeure und Händler haben eigene Prüf- und Mitwirkungspflichten. Bei Open-Source-Software differenziert der CRA: Nicht-kommerzielle Beiträge werden anders behandelt als Produkte, die kommerziell bereitgestellt oder in ein vermarktetes Angebot integriert werden. Open Source ist damit kein Freifahrtschein, aber auch nicht pauschal ein Compliance-Risiko.
Die Scope-Analyse sollte nicht als einmalige juristische Klassifizierung enden. Sie braucht eine belastbare Produktlandkarte: Welche Komponenten werden in der EU bereitgestellt? Welche Teams entwickeln sie? Welche Abhängigkeiten, Managed Services, Firmware-Bausteine und Update-Kanäle gehören dazu? Und welche Gesellschaft tritt gegenüber Kunden tatsächlich als Hersteller auf? Ohne diese Zuordnung bleiben technische Nachweise und regulatorische Verantwortlichkeiten schnell widersprüchlich.
Security by Design wird zur Produktpflicht
Der CRA verlangt, dass Produkte bei ihrer Bereitstellung ohne bekannte ausnutzbare Schwachstellen ausgeliefert werden und ein angemessenes Schutzniveau über ihren Supportzeitraum bieten. Die Anforderungen aus Anhang I reichen von sicherer Voreinstellung und Zugriffsschutz bis zu Schwachstellenbehandlung, sicherer Aktualisierung und dem Schutz von Vertraulichkeit, Integrität und Verfügbarkeit.
Das klingt vertraut, ist aber mehr als eine Sammlung etablierter Security-Praktiken. Der regulatorische Unterschied liegt in der Verbindlichkeit und in der Nachweisbarkeit. Ein Threat Model in einem Wiki, das nach dem Architekturreview niemand mehr pflegt, hilft im Audit wenig. Ebenso reicht ein Penetrationstest vor dem Go-live nicht aus, wenn kritische Bibliotheken später ohne klare Verantwortlichkeit aktualisiert werden.
Praktisch sollte jedes Produktteam ein nachvollziehbares Sicherheitsmodell führen: schützenswerte Assets, Vertrauensgrenzen, relevante Angriffspfade, Sicherheitsannahmen und akzeptierte Restrisiken. Daraus folgen Anforderungen an Architektur und Betrieb. Bei einer industriellen Edge-Komponente werden etwa sichere Boot-Ketten, lokale Administrationsschnittstellen und signierte Updates zentral sein. Bei Unternehmenssoftware können Identitätsintegration, Mandantentrennung, Protokollierung und sichere Standardkonfigurationen stärker im Vordergrund stehen. Das Sicherheitsziel bleibt gleich, die angemessene Umsetzung hängt vom Produkt und seinem Einsatzkontext ab.
Besonders kritisch ist die Frage, wer Sicherheitsentscheidungen verbindlich trifft. Produktmanager können Time-to-Market nicht allein gegen bekannte Risiken abwägen. Security wiederum darf nicht nur kontrollieren, wenn die Architektur längst feststeht. Sinnvoll ist ein gemeinsames Entscheidungsmodell mit klaren Security Gates: vor Architekturfreigabe, vor externer Beta, vor allgemeiner Verfügbarkeit und bei wesentlichen Änderungen. Diese Gates müssen nicht bürokratisch sein. Sie müssen aber Risiken, Ausnahmen und Verantwortliche sichtbar machen.
Der Supportzeitraum ist Teil des Produktversprechens
Hersteller müssen Schwachstellen während des Supportzeitraums wirksam behandeln. Dieser beträgt grundsätzlich mindestens fünf Jahre, sofern die erwartete Produktlebensdauer nicht kürzer ist. Sicherheitsupdates müssen kostenfrei bereitgestellt und klar von Funktionsupdates getrennt angeboten werden können.
Damit wird Lifecycle-Management zu einer Compliance-Frage. Wer noch nicht verbindlich festlegt, wie lange eine Version unterstützt wird, kann weder Ressourcen noch Nachweise sauber planen. Das betrifft auch End-of-Life-Prozesse: Kunden brauchen rechtzeitig klare Informationen, welche Versionen keine Sicherheitsupdates mehr erhalten und welche Migrationspfade realistisch sind. Ein bloßer Hinweis in Release Notes ist dafür organisatorisch zu schwach.
SBOM und Vulnerability Management müssen zusammenarbeiten
Der CRA fordert technische Dokumentation. Dazu gehört auch eine Software Bill of Materials in einem gängigen, maschinenlesbaren Format, mindestens für Abhängigkeiten auf oberster Ebene. Die SBOM ist kein Selbstzweck und kein vollständiger Beweis für Sicherheit. Sie schafft aber die Voraussetzung, bei einer neu bekannt gewordenen Schwachstelle schnell festzustellen, welche Produkte, Versionen und Kundeninstallationen betroffen sein könnten.
In der Praxis scheitert das oft an Medienbrüchen. Das Build-System kennt die konkrete Paketversion, der Einkauf verwaltet kommerzielle Komponenten, ein Security-Scanner bewertet Findings und das Support-Team kennt nur die installierte Hauptversion beim Kunden. CRA-tauglich wird dieser Prozess erst, wenn sich diese Informationen verbinden lassen.
Du brauchst deshalb eine eindeutige Produkt- und Versionsidentität, reproduzierbare Build-Artefakte und einen geregelten Umgang mit Komponentenlisten. Für Container, Firmware und Plug-ins gelten dabei unterschiedliche technische Muster. Ein zentrales Ziel bleibt jedoch gleich: Eine Sicherheitsmeldung muss vom betroffenen Artefakt über die Produktversion bis zu verantwortlichen Teams und Kundenkommunikation verfolgbar sein.
Automatisierte Scans sind wertvoll, ersetzen aber keine Bewertung. Eine Common Vulnerabilities and Exposures-Meldung kann in einem Produkt enthalten sein, ohne praktisch ausnutzbar zu sein. Umgekehrt kann eine als moderat bewertete Schwachstelle in einer exponierten Managementschnittstelle ein hohes Geschäftsrisiko erzeugen. Teams brauchen deshalb definierte Service Levels für Triage, Risikobewertung, Behebung, Ausnahmegenehmigungen und Kommunikation. Entscheidend ist nicht, jede Warnung sofort zu schließen, sondern begründete Entscheidungen innerhalb belastbarer Fristen treffen zu können.
Meldepflichten brauchen einen operativen Ernstfallprozess
Ab September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle innerhalb enger Fristen an die zuständigen Stellen und ENISA melden. Die Verordnung sieht gestufte Meldungen vor, beginnend mit einer frühen Warnung innerhalb von 24 Stunden. Das ist keine Aufgabe, die ein einzelner Compliance Owner im Nachgang erledigen kann.
Ein funktionierender Prozess verbindet Product Security Incident Response, Legal, Datenschutz, Unternehmenskommunikation und gegebenenfalls den Betrieb. Er muss klären, wer einen Vorfall als potenziell meldepflichtig einstuft, welche Fakten für eine Erstmeldung ausreichend sind und wie Teams auch außerhalb regulärer Arbeitszeiten entscheiden. Das unterscheidet sich von etablierten Meldeketten nach DSGVO oder NIS2, kann aber an dieselben Krisenstrukturen andocken.
Wichtig ist die Trennung von Sachverhalt und Spekulation. In den ersten Stunden fehlen oft vollständige Informationen. Ein gutes Verfahren ermöglicht dennoch eine fristgerechte, transparente Erstmeldung und ergänzt sie später um technische Ursachenanalyse, Abhilfemaßnahmen und Auswirkungen. Wer darauf wartet, bis jede Logzeile ausgewertet ist, wird die Fristen kaum halten.
Konformitätsbewertung ist der Beweis, nicht der Startpunkt
Vor dem Inverkehrbringen stehen Konformitätsbewertung, EU-Konformitätserklärung und CE-Kennzeichnung. Für viele Produkte kann der Hersteller die Konformität selbst bewerten. Für bestimmte als kritisch eingestufte Produkte gelten weitergehende Anforderungen, die eine externe Stelle einbeziehen können. Welche Route einschlägig ist, muss früh in der Produktplanung geklärt werden – nicht erst, wenn Vertrieb und Beschaffung einen Liefertermin zugesagt haben.
Die technische Dokumentation muss die Sicherheitsanforderungen, die gewählte Umsetzung, Tests, Risikoanalyse, Schwachstellenprozesse und Produktinformationen nachvollziehbar abbilden. Sie ist zehn Jahre aufzubewahren. Das ist ein starkes Argument gegen Compliance-Artefakte, die nur in persönlichen Laufwerken oder projektspezifischen Tickets liegen.
Ein praxistaugliches Zielbild ist ein Evidence Flow entlang des Entwicklungsprozesses. Architekturentscheidungen, Security-Anforderungen, Testnachweise, SBOMs, Freigaben und Ausnahmen werden dort erzeugt, wo die Arbeit stattfindet, und anschließend produktbezogen konsolidiert. Nicht jede Organisation braucht dafür sofort eine neue Plattform. Aber sie braucht klare Datenverantwortung und versionierbare Nachweise.
So priorisierst Du die Umsetzung
Der sinnvollste Start ist kein umfassendes Gap-Assessment über das gesamte Portfolio ohne Entscheidungslogik. Beginne mit einer repräsentativen Produktgruppe: hoher Umsatzanteil, komplexe Softwarelieferkette, lange Lebensdauer oder besonders hohes Schadenspotenzial. An ihr lassen sich Scope, Nachweiskette, Schwachstellenprozess und Meldefähigkeit unter realen Bedingungen testen.
Parallel sollte die IT- und Produktleitung ein gemeinsames Steuerungsgremium etablieren. Dort gehören Produktverantwortung, Engineering, Security, Legal, Einkauf, Support und gegebenenfalls Managed Operations an einen Tisch. Seine Aufgabe ist nicht, jede Sicherheitslücke zu diskutieren. Es entscheidet über Standards, Risikoakzeptanz, Budget für Supportzeiträume und Eskalationen, die einzelne Teams nicht auflösen können.
Der CRA zwingt Unternehmen damit zu einer unbequemen, aber hilfreichen Frage: Können wir für jedes vermarktete digitale Produkt tatsächlich erklären, woraus es besteht, wie es geschützt wird und wer es über Jahre absichert? Wenn die Antwort heute nur teilweise lautet, liegt darin kein Scheitern. Es ist der konkrete Ausgangspunkt, an dem aus Compliance-Arbeit belastbare Produktverantwortung wird.
