Cyber Resilience Act: Wie Entwicklungsdaten zu belastbaren CRA-Nachweisen werden

Seit dem 11. September 2026 gelten die Meldepflichten des Cyber Resilience Act (CRA): Hersteller müssen aktiv ausgenutzte Schwachstellen in ihren Produkten innerhalb von 24 Stunden melden. Spätestens jetzt zeigt sich, ob ein Unternehmen für jedes Produkt, jede Version und jede Variante schnell weiß, welche Komponenten verbaut sind. In diesem Beitrag zeigen wir, wie vorhandene Entwicklungsdaten helfen, die CRA-Readiness eines ganzen Produktportfolios kontinuierlich zu bewerten und CRA-Konformitätsnachweise effizient zu führen.

Der Cyber Resilience Act in Kürze: Meldepflichten und Fristen im Überblick

Der Cyber Resilience Act (CRA) ist seit dem 10. Dezember 2024 in Kraft. Seit dem 11. September 2026 gelten die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle aus Artikel 14, auch für Produkte, die bereits auf dem Markt sind: Frühwarnung binnen 24 Stunden, ausführlichere Meldung binnen 72 Stunden, jeweils über die zentrale Meldeplattform der ENISA; ein Abschlussbericht folgt. Ab dem 11. Dezember 2027 gelten alle übrigen Anforderungen, einschließlich Konformitätsbewertung und CE-Kennzeichnung, für neu in Verkehr gebrachte Produkte, für bereits in Verkehr gebrachte nur bei einer wesentlichen Änderung. Bei Verstößen drohen Bußgelder von bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist.

Wer betroffen ist und welche Handlungsfelder sich ergeben, beschreibt unser Beitrag Cyber Resilience Act: Strategische Chance statt regulatorische Last. Hier geht es um die nächste Frage: Wie führen Hersteller die CRA-Nachweise über ein ganzes Produktportfolio hinweg, ohne dass die Dokumentation zum Selbstzweck wird? Denn der eigentliche Wert liegt in resilienteren Produkten, die Angriffe besser abwehren, Störungen begrenzen und schnell auf neue Schwachstellen reagieren.

Warum das Produktportfolio bei der CRA-Compliance zur eigentlichen Herausforderung wird

Bei einem einzelnen Produkt lässt sich der CRA-Status noch manuell erfassen. Bei Hunderten von Produkten, Dutzenden Konfigurationen und zahlreichen Versionen wird das langsam, fehleranfällig und schwer wiederholbar, obwohl das Schwachstellenmanagement den gesamten Unterstützungszeitraum abdecken muss.

Zudem sind die Daten fragmentiert. Sie liegen in Software-Composition-Analyse (SCA), statischer Codeanalyse, CI/CD, Ticketsystemen und Penetrationstests. Bei Hardware-Software-Produkten kommt eine technische Hürde dazu: Für Java lässt sich eine Software Bill of Materials (SBOM) über Maven oder Gradle weitgehend automatisch erzeugen. Bei hardwarenahem C- oder C++-Code fehlt dieser Weg oft, weil Bibliotheken direkt im Quellcode oder in zugelieferten Binärkomponenten stecken. Build-Analysen und Binär-Scans liefern dann Ergebnisse in anderem Format und mit anderer Aussagekraft. Die Daten sind also oft vorhanden, aber weder vergleichbar noch zusammengeführt. Es fehlt eine gemeinsame Produktsicht, die Befunde einer konkreten Version zuordnet und mit den CRA-Anforderungen verknüpft.

Vom Tool-Signal zum CRA-Konformitätsnachweis

Ein technisches Signal wird nicht allein dadurch zum Nachweis, dass es zentral gespeichert ist. Ein Tool-Signal ist zunächst nur ein Befund. Erst der Zusammenhang aus Befund, Risikobewertung, Maßnahme und Prüfergebnis macht ihn für die Assurance nutzbar, also für die begründete und überprüfbare Aussage, dass eine Anforderung erfüllt ist. Das gilt auch für die SBOM: Der CRA verlangt sie maschinenlesbar, mindestens für die Abhängigkeiten der obersten Ebene. Entscheidend für das Schwachstellenmanagement ist aber, was mit den Schwachstellen geschieht, die sie sichtbar macht.

Solange harmonisierte Normen nicht vollständig vorliegen, bieten IEC 62443-4-1 und BSI TR-03183 eine gute Orientierung für Kontrollziele. Exemplarisch sieht die Zuordnung so aus:

Welche Anforderungen im Einzelfall relevant sind, ergibt sich aus der Risikobewertung des jeweiligen Produkts.

Die CRA-Readiness- und Assurance-Plattform als Integrationsschicht

Damit diese Zuordnung nicht für jedes Produkt manuell entsteht, bietet sich eine zentrale Readiness- und Assurance-Plattform an. Gemeint ist kein weiteres Scan-Werkzeug, sondern eine Integrationsschicht über der bestehenden Toolchain. Sie übernimmt die Ergebnisse vorhandener Werkzeuge, ordnet sie Produkten zu und bewertet sie anhand der Kontrollziele. Architektonisch lässt sie sich in sechs Ebenen gliedern:

1. Datenquellen wie Dependency-Track, SonarQube, CI/CD oder Ticketsysteme liefern die Befunde.

2. Adapter überführen sie in ein gemeinsames Datenmodell und erhalten Zeitstempel und Herkunft.

3. Das Produkt- und Versionsmodell ordnet sie Produkt, Release, Variante und Komponente zu.

4. Die Bewertungs- und Kontrollebene verknüpft sie über Regeln und Quality Gates mit den Kontrollzielen; wo Regeln nicht ausreichen, fließt die fachliche Bewertung ein.

5. Der Nachweisspeicher legt Nachweise und Entscheidungen versioniert und rückverfolgbar ab.

6. Die Nutzer- und Workflowebene stellt den Status in Dashboards, CI/CD, Tickets und Benachrichtigungen bereit.

Nicht die Menge der gesammelten Daten schafft Assurance, sondern ihre eindeutige Zuordnung, Aktualität und Bewertung. Für Produktteams heißt das: Eine Datenquelle wird einmal angebunden, etwa indem ein Dependency-Track-Projekt einem Produkt und einer Version zugeordnet wird. Danach übernimmt die Plattform neue Ergebnisse automatisch, prüft sie auf Aktualität und Vollständigkeit und stellt den Status dort bereit, wo die Teams ohnehin arbeiten.

Praxisbeispiel: CRA-Meldepflicht in der Praxis: Eine kritische Schwachstelle, 300 Produktvarianten, 24 Stunden

Ein vereinfachtes, fiktives Szenario: Ein Hersteller von Automatisierungskomponenten betreut rund 300 Produktvarianten. Eines Morgens wird bekannt, dass eine Schwachstelle in einer verbreiteten Open-Source-Bibliothek aktiv ausgenutzt wird. Ohne gemeinsame Produktsicht beginnt die Suche per E-Mail und Tabelle, und bis ein verlässliches Lagebild vorliegt, vergehen leicht Tage.

Mit der Plattform liegen die SBOMs aller Releases bereits vor, und eine Abfrage zeigt in Minuten, dass die betroffene Version in 12 Varianten aus vier Releases steckt. Für jede Variante entsteht automatisch ein Bewertungsvorgang. Die Fachleute stellen fest, dass die verwundbare Funktion in fünf Varianten nicht erreichbar ist, und dokumentieren das begründet, etwa als VEX-Status (Vulnerability Exploitability eXchange). Für die übrigen sieben werden Maßnahmen angestoßen. So liegt nach wenigen Stunden die Grundlage für die Entscheidung vor, ob und für welche Produkte eine Frühwarnung nach Artikel 14 nötig ist. Die Entscheidung selbst trifft der Hersteller, aber auf Basis eines vollständigen und dokumentierten Lagebilds statt einer Schätzung.

Was sich automatisieren lässt – und wo Expertise nötig bleibt

Das Beispiel zeigt die sinnvolle Arbeitsteilung. Die Plattform automatisiert nicht die Konformitätsentscheidung, sondern Datenerhebung, Zuordnung, Konsistenzprüfungen und wiederholbare Regeln.

Gut automatisierbar: Liegt für den Release eine aktuelle SBOM vor? Gibt es kritische Schwachstellen ohne fristgerechte Behandlung? Ist jede bekannte Schwachstelle bewertet? Sind die definierten Security-Tests erfolgreich? Liegen Pflichtinformationen und Nachweise in der erwarteten Version vor?

Fachlich zu bewerten: Fällt das Produkt in den Anwendungsbereich, und welche Produktkategorie gilt? Ist eine Schwachstelle im Produktkontext ausnutzbar? Sind die Risikoszenarien vollständig, die Maßnahmen angemessen und Restrisiken vertretbar? Welches Konformitätsbewertungsverfahren ist anzuwenden?

Die Plattform liefert aktuelle, strukturierte Daten und macht Abweichungen sichtbar. Die Entscheidungen treffen qualifizierte Verantwortliche, und die Verantwortung bleibt beim Hersteller.

Schrittweise vom Piloten zum Regelbetrieb

Eine solche Plattform entsteht am besten in vier Phasen. Auf Transparenz und Priorisierung des Portfolios folgt das Fundament aus Rollen, Bewertungsmaßstäben und Quality Gates. Ein repräsentatives Produkt durchläuft dann als Pilot den gesamten Prozess von der Risikoanalyse bis zum Konformitätsnachweis, einschließlich Schwachstellenbehandlung und Meldung, bevor der validierte Ansatz auf weitere Produktlinien übertragen wird.

So wächst aus einem Pilotprojekt ein gemeinsamer Rahmen für das gesamte Portfolio. Jedes Produkt behält seine individuelle Risikobewertung, während wiederverwendbare Adapter, Kontrollziele und Nachweisstrukturen die Teams entlasten.

Fazit: Aus verteilten Daten wird Steuerungsfähigkeit

Viele Informationen für CRA-Nachweise entstehen bereits heute in der Entwicklung. Produktbezogen zusammengeführt und laufend bewertet, schaffen sie mehr als Compliance-Transparenz: Sie helfen Herstellern, Risiken früher zu erkennen, Maßnahmen gezielter zu priorisieren und im Ernstfall innerhalb der Meldefristen des Cyber Resilience Act fundiert zu entscheiden.

Wie viel Ihrer CRA-Readiness steckt bereits in Ihren Entwicklungswerkzeugen? Sprechen Sie uns an: In einer gemeinsamen Standortbestimmung zeigen wir Ihnen, wo Sie stehen und welche Schritte den größten Hebel haben.