Cyber Resilience Act: Wo der Nachholbedarf konkret liegt

Der Cyber Resilience Act tritt am 11. Dezember 2027 vollständig in Kraft, doch die entscheidenden Weichen werden bereits vorher gestellt. Eine aktuelle Umfrage, über die heise online berichtet, zeigt: viele Unternehmen sind mit den Vorgaben zu Meldepflichten und Software-Stücklisten noch nicht ausreichend vertraut. Für Governance-, Risk- und Compliance-Funktionen lautet die Frage nicht mehr, ob der CRA relevant ist, sondern welche Nachweise bis zu den nächsten Stichtagen tatsächlich vorliegen müssen und wer sie liefert.

Wie weit ist die Industrie mit der CRA-Umsetzung tatsächlich?

Laut einer von heise online zitierten Umfrage des Cybersicherheits-Anbieters ONEKEY sind 45 Prozent der befragten Unternehmen mit den CRA-Anforderungen kaum oder gar nicht vertraut.

Ein zweiter Befund wirkt in der Lieferkette stärker: nach der gleichen Umfrage liefern nur 18 Prozent der Zulieferer die notwendigen CRA-Informationen, obwohl Hersteller auch für zugelieferte Komponenten haften. Das eigentliche Risiko liegt damit weniger in der eigenen Entwicklungsabteilung als in der Kette der Vorlieferanten.

Trotzdem gibt ein Drittel der Unternehmen an, bis zum Stichtag im Dezember 2027 alle Vorgaben erfüllt haben zu wollen, so heise online. Zwischen diesem Anspruch und einer dokumentierten Vorbereitung liegt in vielen Fällen noch eine Lücke. Ähnliche Unsicherheiten über den eigenen Anwendungsbereich zeigen sich auch bei anderen EU-Rechtsakten, wie die NIS2-Registrierungslücke: Was sie über Scope-Unsicherheit zeigt illustriert.

Welche Fristen liegen zwischen heute und der vollständigen Anwendung?

Der Cyber Resilience Act ist am 10. Dezember 2024 in Kraft getreten, die Meldepflicht für Schwachstellen und Vorfälle gilt ab dem 11. September 2026, und ab dem 11. Dezember 2027 greift die Verordnung vollständig.

Zwischen diesen Stichtagen liegt die eigentliche Vorbereitungszeit. Wer die Meldepflicht ab September 2026 einhalten will, braucht zu diesem Zeitpunkt eine funktionierende Erkennungs- und Eskalationskette und keinen Entwurf davon. Die vollständige Konformität einschliesslich der SBOM-Pflicht folgt gut ein Jahr später, doch die dafür nötigen Prozesse lassen sich nicht in den letzten Wochen vor dem Stichtag aufbauen.

Das Bundesamt für Sicherheit in der Informationstechnik begleitet diese Übergangsfrist mit einer technischen Richtlinie, die Anforderungen an SBOM und Meldewesen konkretisiert, ersetzt aber keine eigene Risikobewertung im Unternehmen.

Was verlangt die Meldepflicht nach Artikel 14 des CRA konkret?

Hersteller müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle als Frühwarnung innerhalb von 24 Stunden und als Folgemeldung innerhalb von 72 Stunden an die zuständige koordinierende Stelle und an die ENISA melden.

Beide Meldungen laufen über die im CRA vorgesehene einheitliche Meldeplattform, die gleichzeitig an das koordinierende CSIRT und an die ENISA übermittelt. Die Frist beginnt mit der Kenntniserlangung des Herstellers, nicht mit der Bestätigung durch eine Fachabteilung oder einen externen Hinweisgeber.

Für eine GRC-Funktion bedeutet das, dass die Eskalationswege innerhalb der 24-Stunden-Frist schriftlich geregelt und eingespielt sein müssen, bevor der Stichtag im September 2026 erreicht ist. Wie stark eine solche Meldekette von eingespielten Prozessen statt von reiner Technik abhängt, beschreibt der Beitrag ISMS: Menschen, Prozesse und Technologie sind entscheidend.

Welche Nachweise fehlen bei der Software-Stückliste noch am häufigsten?

Die SBOM ist Bestandteil der technischen Dokumentation und muss mindestens die direkten Softwareabhängigkeiten erfassen, doch vielen Unternehmen fehlen genau diese Angaben für zugelieferte Komponenten.

Der CRA schreibt kein einzelnes technisches Format vor, in der Praxis haben sich CycloneDX und SPDX etabliert. Entscheidend ist weniger das Format als die Aktualität: eine einmalig erstellte SBOM verliert mit jedem Softwareupdate an Aussagekraft und sollte eng an Build- und Release-Prozesse gekoppelt werden.

Der Befund zu den Zulieferern setzt genau hier an: ohne belastbare Angaben aus der Lieferkette bleibt die eigene SBOM lückenhaft, unabhängig davon, wie gut die interne Dokumentation aufgestellt ist. Wie sich solche Abhängigkeiten von Dritten systematisch erfassen lassen, beschreibt der Beitrag Was das Third-Party Cyber Risk Management von etablierten Sicherheitsfunktionen lernen kann.

Welcher erste Schritt lässt sich jetzt konkret terminieren?

Der nächste überprüfbare Schritt ist ein vollständiges Produktinventar, das für jedes Produkt festhält, ob eine maschinenlesbare SBOM vorliegt und welche Zulieferer noch fehlende Angaben liefern müssen.

Die Sicherheits- oder Compliance-Verantwortlichen sollten bis zum Stichtag am 11. September 2026 einen dokumentierten Eskalationsprozess für aktiv ausgenutzte Schwachstellen vorlegen, einschliesslich Zugang zur Meldeplattform und einer benannten Zuständigkeit für die 24-Stunden-Frist. Parallel dazu lohnt sich eine Bestandsaufnahme, für welche Produkte und Zulieferer heute überhaupt maschinenlesbare SBOM-Daten vorliegen.

Da CRA-Meldungen produktbezogen erfolgen und andere Regime wie NIS2 organisationsbezogen melden, lohnt sich zusätzlich ein Blick auf die Schnittstellen zwischen beiden Pflichten, wie der Beitrag Cyber Resilienz neu denken im Kontext von NIS2 einordnet. Wer diese Bestandsaufnahme jetzt beginnt, hat bis zum Stichtag im September 2026 noch Zeit für einen Testlauf der Meldekette.