Cyber Resilience Act: Jetzt Prozesse sichern

7 Min. Lesezeit

Ab dem 11. September 2026 gilt die Meldepflicht des Cyber Resilience Act für aktiv ausgenutzte Schwachstellen: 24 Stunden Early Warning, 72 Stunden Vollmeldung, 14 Tage Abschlussbericht. Wer heute keinen CRA-reifen Incident-Response-Prozess hat, wird die Fristen im Ernstfall nicht halten. Für Hersteller von Produkten mit digitalen Elementen bleiben noch fünf Monate Vorlauf – und die sind knapp.

Was die CRA-Meldepflicht ab September 2026 konkret verlangt

Der Cyber Resilience Act ist die erste EU-weite Produkt-Cybersecurity-Verordnung. Er adressiert Hersteller, Importeure und Händler von Produkten mit digitalen Elementen – also praktisch alles, was Software enthält oder vernetzt wird. Betroffen sind klassische Software-Anbieter ebenso wie Hardware-Hersteller mit eingebetteten Systemen, Anbieter vernetzter Haushaltsgeräte, Industriesensorik, IoT-Gateways und Produkte mit Firmware-Updates. Die vollständige Anwendbarkeit ist auf den 11. Dezember 2027 terminiert, aber ein wesentlicher Pflichtblock greift früher: Ab dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle melden.

Diese Meldepflicht ist operationell der kritischste Teil des CRA. Sie bindet IT-Security-Teams unmittelbar in regulatorische Prozesse ein und schafft eine harte Schnittstelle zwischen Vulnerability-Handling und Behördenkommunikation. Produkte, die nach dem Stichtag in Verkehr gebracht werden, fallen in vollem Umfang unter die Meldepflicht. Für Bestandsprodukte gelten Übergangsregelungen, aber sobald ein Update ausgerollt wird, muss der Hersteller die CRA-Meldekette ohnehin bedienen können.

Das BSI hat im Rahmen seiner CRA-Beratungsinitiative klargemacht, dass es sich um operative Meldepflichten handelt, nicht um formale Compliance-Dokumentation. Die Fristen sind strikt. Die Adressaten sind eindeutig definiert. Die Meldeinhalte sind technisch wie inhaltlich anspruchsvoll. Ein Marketing-getriebener Standard-Bericht reicht nicht – gefordert sind präzise Angaben zu betroffenen Produkten, Exploits, Mitigation-Status und Patch-Verfügbarkeit.

Die 24-72-14-Uhr: Meldeketten im Detail

Die drei CRA-Fristen für aktiv ausgenutzte Schwachstellen bauen aufeinander auf und zwingen Security-Teams zu einer klar getakteten Eskalationsroutine. Die Uhr beginnt zu laufen, sobald der Hersteller Kenntnis von der aktiven Ausnutzung erlangt. Ab diesem Zeitpunkt bleiben 24 Stunden für eine Early Warning, die die grundlegenden Informationen zur Schwachstelle, zum betroffenen Produkt und zum Kenntnisstand enthält. Die Early Warning ist keine vollständige Meldung, sondern ein Frühwarnsignal an die Behörden.

Innerhalb von 72 Stunden nach derselben Kenntniserlangung muss die Vollmeldung folgen. Sie enthält Angaben zur Art der Schwachstelle, zu den betroffenen Produktversionen, zu ersten Mitigation-Empfehlungen und zum aktuellen Stand der Vorfallsbearbeitung. Wer den 72-Stunden-Slot nicht hält, verletzt eine der zentralen Compliance-Pflichten des CRA. Die praktische Konsequenz ist, dass Incident-Response-Prozesse innerhalb des ersten Arbeitstages nach Entdeckung nicht nur technisch arbeiten, sondern auch regulatorisch meldefähig sein müssen.

Der dritte Schritt ist der Abschlussbericht. Für aktiv ausgenutzte Schwachstellen gilt eine 14-Tage-Frist ab Verfügbarkeit einer Korrekturmaßnahme – also ab dem Zeitpunkt, zu dem der Patch ausgerollt werden kann. Für schwere Sicherheitsvorfälle erweitert sich dieser Zeitraum auf einen Monat. Der Abschlussbericht dokumentiert die Root Cause, die ergriffenen Maßnahmen, den Patch-Rollout-Stand und die Learnings für künftige Produktversionen. Er ist die Grundlage für Folgeaudits durch ENISA und nationale Behörden.

Wer im Unternehmen meldet und wohin

Die CRA-Meldungen laufen zentral über die CRA Single Reporting Platform – ein von ENISA betriebenes Meldesystem, das eine einmalige Eingabe vorsieht. Der Hersteller adressiert die Meldung formal an das Computer Security Incident Response Team im Mitgliedstaat seines Hauptsitzes. In Deutschland ist das BSI beziehungsweise das CERT-Bund die zuständige Stelle. Die Information wird parallel an ENISA weitergeleitet, außer in klar definierten Ausnahmefällen mit besonderen Sicherheitsinteressen.

Für Unternehmen mit mehreren Produktionsstandorten oder Tochtergesellschaften in verschiedenen EU-Staaten ist die Hauptsitz-Regelung entscheidend. Sie legt fest, welches CSIRT zuständig ist, welche nationalen Leitlinien greifen und wer bei Rückfragen kontaktiert wird. Konzerne mit gemischten Strukturen müssen diese Zuordnung sauber dokumentieren und innerhalb der Organisation klären, wer im Ernstfall die Meldung auslöst. Ein reiner Produktverantwortlicher ohne Vollmacht für Behördenkommunikation scheitert an der CRA-Realität.

Innerhalb des Unternehmens braucht die CRA-Meldung eine definierte Verantwortlichkeit. Typischerweise sitzt sie beim Product Security Incident Response Team (PSIRT) mit direkter Anbindung an das CISO-Büro. Wer heute kein PSIRT hat, muss die Funktion vor dem Stichtag aufbauen. Die Alternative ist, Entwicklungsteams ad hoc ins Meldeverfahren zu zwingen – das skaliert nicht und bricht an den 24-Stunden-Fristen. Die personelle Frage ist mindestens so wichtig wie die technische Vorbereitung.

Was ein CRA-reifer Incident-Response-Prozess leisten muss

Ein CRA-konformer Prozess baut auf drei Säulen: Detection, Assessment und Reporting. Detection bedeutet, dass der Hersteller aktive Exploitation frühzeitig erkennt – durch Monitoring eigener Produkte, Auswertung von Threat Intelligence Feeds, Coordinated Vulnerability Disclosure Kanäle und Einbindung in ISAC-Strukturen. Ein Hersteller, der nur auf Kunden-Beschwerden reagiert, ist in einer schlechten Ausgangslage, weil er die Kenntnisschwelle erst spät erreicht und die 24-Stunden-Uhr parallel zum Incident-Triage anläuft.

Assessment heißt, die Relevanz einer Meldung innerhalb weniger Stunden bewerten zu können. Ist die gemeldete Schwachstelle tatsächlich aktiv ausgenutzt, oder nur theoretisch exploitbar? Welche Produktversionen sind betroffen? Gibt es bereits Mitigations, oder muss ein Hotfix gebaut werden? Diese Triage-Fähigkeit verlangt ein aktuelles SBOM, getestete Reproduktions-Umgebungen und eine klare Eskalations-Matrix. Teams, die Triage heute erst nach mehreren Tagen abschließen, brauchen Prozess- und Tool-Investitionen.

Reporting ist die letzte Säule und gleichzeitig der Punkt, an dem Compliance-Pflicht und technische Realität aufeinandertreffen. Die Meldeinhalte müssen strukturiert, präzise und rechtssicher sein. Das CSIRT erwartet keine Marketing-Kommunikation, sondern technische Angaben auf CVE-Level, klare Zeitstempel und nachvollziehbare Mitigation-Schritte. Wer im Ernstfall zwischen Entwicklung, Rechtsabteilung und Kommunikation übersetzen muss, verliert Zeit. Mustertexte und abgestimmte Templates sind Pflichtvorbereitung.

SBOM als technische Voraussetzung

Der CRA verlangt explizit die Erstellung und Pflege einer Software Bill of Materials als Grundlage des Vulnerability-Handlings. Eine SBOM ist eine maschinenlesbare Liste aller Softwarekomponenten eines Produkts – inklusive Versionen, Lizenzen und Abhängigkeiten. Ohne SBOM lässt sich im Schwachstellenfall nicht schnell ermitteln, welche Produkte betroffen sind. Die Meldefristen werden dann praktisch unmöglich einzuhalten.

Die beiden gängigen SBOM-Formate sind SPDX und CycloneDX. Beide sind maschinenlesbar, werkzeugunterstützt und ENISA-konform. Für die Umsetzung empfiehlt sich eine Generierung im Build-Prozess – SBOMs aus dem Repository sind oft unvollständig, weil sie Binary-Abhängigkeiten und transitive Libraries nicht sauber abbilden. Tools wie Syft, Trivy oder die SBOM-Integrationen großer Paketmanager haben sich in DACH-Entwicklungsumgebungen etabliert und liefern valide Ergebnisse.

Wichtig ist die kontinuierliche Pflege. Ein SBOM, das nur beim Release erstellt wird, veraltet innerhalb von Tagen, wenn Dependencies gepatcht werden. CRA-reife Organisationen führen SBOMs als lebende Artefakte, versioniert mit jedem Build und verfügbar in einer zentralen Ablage. Im Ernstfall lässt sich dann per Abfrage binnen Minuten klären, welche Produktversionen eine betroffene Library enthalten – die Voraussetzung für eine schnelle Meldung.

Zeitplan: Was wann gelten muss

Quellen: EU Digital Strategy, BSI CRA Portal, Hogan Lovells Insights 2026

Gap-Analyse: Sechs Fragen an den eigenen Prozess

Vor der Umsetzung empfiehlt sich eine strukturierte Gap-Analyse anhand sechs operativer Fragen. Sie lassen sich in einem halben Tag im CISO-Team beantworten und ergeben einen klaren Maßnahmenplan:

1. Kenntnisschwelle: Wie erfährt das Unternehmen heute von aktiv ausgenutzten Schwachstellen in eigenen Produkten? Gibt es eine Coordinated Vulnerability Disclosure Policy mit kurzen Reaktionszeiten? Wird Threat Intelligence auf eigene Produkte gefiltert ausgewertet?
2. Triage-Fähigkeit: Kann die Security-Abteilung innerhalb von drei bis vier Stunden bewerten, ob eine gemeldete Schwachstelle aktive Exploitation darstellt? Existieren Reproduktions-Umgebungen für alle produktiven Softwareversionen?
3. SBOM-Aktualität: Wird für jedes ausgelieferte Produkt ein aktuelles SBOM erzeugt und vorgehalten? Sind die SBOMs maschinenlesbar und durchsuchbar, oder liegen sie als PDF-Export in einem Wiki?
4. Meldeverantwortung: Wer im Unternehmen ist befugt, eine CRA-Meldung an das BSI zu senden? Gibt es eine 24/7-Erreichbarkeit dieser Rolle? Wie ist die Abstimmung mit der Rechtsabteilung und Kommunikation geregelt?
5. Mustertexte: Existieren vorab abgestimmte Templates für Early Warning, Vollmeldung und Abschlussbericht? Sind sie mit der Rechtsabteilung freigegeben und technisch ausgefüllt?
6. Übungsstand: Wurde die CRA-Meldekette bereits im Trockenlauf getestet? Tabletop-Übungen mit zeitgeführter Eskalation decken Prozesslücken auf, bevor sie im Ernstfall kosten.

Wer alle sechs Fragen mit einem belastbaren Ja beantworten kann, ist CRA-reif. Wer bei zwei oder mehr Fragen passen muss, braucht sofort eine konkrete Roadmap mit Zeitplan bis August 2026 – ein Monat Puffer vor dem Stichtag ist das Minimum.

Fazit

Der CRA bringt mit dem 11. September 2026 eine harte regulatorische Deadline, die bisher nicht Teil des deutschen Produktrechts war. Die Meldepflicht für aktiv ausgenutzte Schwachstellen ist kein Compliance-Dokument, sondern ein operativer Prozess, der innerhalb von 24 Stunden funktionieren muss. IT-Security-Teams brauchen eine klare Verantwortlichkeit, definierte Eskalationspfade, aktuelle SBOMs und vorbereitete Meldetexte. Der technische Aufbau ist in fünf Monaten machbar, aber nur wenn jetzt mit der Gap-Analyse begonnen wird.

Der unterschätzte Teil ist die organisatorische Seite: Wer meldet, unter welcher Vollmacht, auf welcher Rechtsgrundlage. Ohne geklärte Verantwortung verpuffen technische Vorbereitungen im Ernstfall. Für die meisten DACH-Hersteller ist der Aufbau eines Product Security Incident Response Teams der entscheidende Schritt – und der sollte nicht erst am 1. September starten.

Häufige Fragen

Gilt der CRA auch für Open-Source-Software?

Der CRA behandelt Open-Source-Software differenziert. Nicht-kommerzielle Open-Source-Projekte sind von den Hauptpflichten ausgenommen. Sobald Open-Source aber als Teil eines kommerziellen Produkts vertrieben oder in Unternehmen integriert wird, gelten die Pflichten für den Anbieter des kommerziellen Produkts – nicht für den ursprünglichen Open-Source-Maintainer. Unternehmen, die auf Open-Source-Komponenten setzen, tragen die CRA-Verantwortung für ihre integrierten Produkte vollständig selbst.

Was passiert, wenn eine Meldung versäumt wird?

Verstöße gegen die CRA-Meldepflichten können mit Bußgeldern bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes geahndet werden – je nachdem welcher Betrag höher ist. Die Durchsetzung erfolgt durch die nationalen Marktüberwachungsbehörden. In Deutschland wird die Rolle derzeit zwischen BSI und BNetzA abgestimmt. Wichtiger als die Bußgeldhöhe ist die Reputationsfolge: Eine nicht gemeldete aktiv ausgenutzte Schwachstelle kann zu Marktausschluss und Produktrückrufen führen.

Muss ein kleiner Software-Hersteller mit 15 Mitarbeitern auch CRA-konform sein?

Ja. Der CRA kennt keine allgemeine KMU-Ausnahme wie der EU Data Act. Die Pflichten gelten unabhängig von Unternehmensgröße und Umsatz, sobald ein Produkt mit digitalen Elementen auf den EU-Markt gebracht wird. Für kleine Hersteller ist die Umsetzung besonders anspruchsvoll, weil sie die Meldeprozesse mit begrenzten Ressourcen aufbauen müssen. Verbände und ENISA haben Leitfäden für KMU angekündigt, um die Umsetzung zu erleichtern.

Wie verhält sich der CRA zur NIS2-Meldepflicht?

CRA und NIS2 existieren parallel und adressieren unterschiedliche Zielgruppen. NIS2 richtet sich an Betreiber wesentlicher und wichtiger Einrichtungen in 18 kritischen Sektoren. Der CRA richtet sich an Hersteller von Produkten mit digitalen Elementen. Ein Unternehmen kann beiden Regelwerken gleichzeitig unterliegen – etwa ein Krankenhaus, das medizinische Software selbst entwickelt. Die Meldepflichten unterscheiden sich: NIS2 verlangt Meldungen über Incidents in der eigenen Infrastruktur, CRA verlangt Meldungen über Schwachstellen in vertriebenen Produkten.

Was genau ist ein Early Warning im CRA-Sinn?

Die Early Warning ist eine formale Erstmeldung, die die Behörde informiert, dass ein potenzieller Meldefall vorliegt. Sie enthält die Art der Schwachstelle, das betroffene Produkt, den Zeitpunkt der Kenntniserlangung und eine erste Einschätzung der Schwere. Sie ist nicht mit einer Pressemitteilung zu verwechseln – im Gegenteil, sie ist vertraulich zwischen Hersteller und CSIRT. Technische Details, die für eine Exploitation missbraucht werden könnten, gehören nicht in die Early Warning, sondern in die spätere Vollmeldung auf einem geschützten Kanal.

Reicht ein vorhandener ISO-27001-Prozess für CRA-Konformität aus?

Nein, ISO 27001 allein reicht nicht. Der Standard deckt das Information Security Management ab, aber nicht die produktspezifischen Pflichten des CRA. Insbesondere die Meldefristen, die SBOM-Pflicht und die Product-Security-Dimension sind in ISO 27001 nicht enthalten. Komplementäre Standards wie IEC 62443 für Industrial Cybersecurity oder ETSI EN 303 645 für IoT-Produkte bieten die fehlenden Bausteine. Eine CRA-konforme Dokumentation kombiniert typischerweise mehrere Standards und ergänzt sie um CRA-spezifische Meldeprozesse.

Quelle Titelbild: Pexels / Tima Miroshnichenko

Hier schreibt Tobias Massow für Sie

Mehr Artikel vom Autor Tobias Massow