Ab dem 11. September 2026 gelten die Meldepflichten des Cyber Resilience Act (CRA). Hersteller müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle, die sich auf die Sicherheit eines Produkts mit digitalen Elementen auswirken, melden. Die erste Meldung muss innerhalb von 24 Stunden erfolgen. Nach 72 Stunden sind weitere Informationen erforderlich.
Ob Ihr Unternehmen darauf vorbereitet ist, erkennen Sie nicht allein daran, dass es ein Ticketsystem oder einen allgemeinen Incident-Response-Prozess gibt. Entscheidend ist, ob Sie einen Hinweis kurzfristig dem richtigen Produkt zuordnen, technisch und regulatorisch bewerten, intern eskalieren und fristgerecht melden können. Die Entscheidung muss auch bei unvollständiger Informationslage möglich und später nachvollziehbar sein.
Kurz gesagt: Ihr Unternehmen ist vorbereitet, wenn Produktübersicht, Eingangskanäle, technische Bewertung, Meldeentscheidung, Plattformzugang und Folgemeldungen auch unter Zeitdruck zusammen funktionieren. Der folgende Selbstcheck macht sichtbar, an welcher Stelle dieser Ablauf noch unterbrochen ist.
Geschätzte Lesedauer: 12 Minuten
CRA-Meldepflichten auf einen Blick
- Start: Die Meldepflichten nach Artikel 14 CRA gelten ab dem 11. September 2026.
- Betroffene Unternehmen: Hersteller von Produkten mit digitalen Elementen, die auf dem EU-Markt bereitgestellt werden.
- Meldeanlässe: aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle mit Auswirkungen auf die Sicherheit des Produkts.
- Erste Frist: Frühwarnung innerhalb von 24 Stunden nach Kenntniserlangung. Wann genau diese im CRA-Sinne vorliegt, ist für die Praxis noch nicht abschließend geklärt.
- Zweite Frist: ergänzende Meldung innerhalb von 72 Stunden, soweit die Informationen nicht bereits vorliegen.
- Entscheidender Nachweis: ein praktisch funktionierender und nachvollziehbar dokumentierter Prozess, nicht lediglich ein vorhandenes Ticket oder Prozessdokument.
Was ab dem 11. September 2026 gemeldet werden muss
Der CRA unterscheidet insbesondere zwei meldepflichtige Ereignisse:
- eine aktiv ausgenutzte Schwachstelle in einem Produkt mit digitalen Elementen;
- einen schwerwiegenden Sicherheitsvorfall, der sich auf die Sicherheit eines solchen Produkts auswirkt.
Nicht jede bekannte oder neu entdeckte Schwachstelle löst damit automatisch eine Meldung innerhalb von 24 Stunden aus. Ihr Prozess muss aber schnell genug feststellen können, welches Produkt betroffen ist, welche Erkenntnisse zur Ausnutzung oder zum Vorfall vorliegen und ob die Voraussetzungen einer Meldung erfüllt sind.
Für beide Meldewege sieht Artikel 14 CRA zunächst eine Frühwarnung innerhalb von 24 Stunden und anschließend eine Meldung innerhalb von 72 Stunden vor. Bei aktiv ausgenutzten Schwachstellen folgt spätestens 14 Tage, nachdem eine Korrektur- oder Risikominderungsmaßnahme verfügbar ist, ein Abschlussbericht. Bei schwerwiegenden Sicherheitsvorfällen ist grundsätzlich innerhalb eines Monats nach der 72-Stunden-Meldung ein Abschlussbericht vorgesehen.
Die Meldungen sollen über die europäische Single Reporting Platform erfolgen. Da deren konkrete Ausgestaltung für die praktische Umsetzung relevant ist, sollten Hersteller den aktuellen Stand bei EU-Kommission, ENISA und BSI verfolgen.
Der bloße Eingang eines ungeprüften Hinweises ist nicht automatisch mit der Kenntnis einer aktiv ausgenutzten Schwachstelle oder eines schwerwiegenden Sicherheitsvorfalls gleichzusetzen. Für bestimmte NIS2-Meldungen erläutert Erwägungsgrund 31 der Durchführungsverordnung (EU) 2024/2690, dass eine erste Bewertung erfolgt sein und hinreichende Gewissheit über den Vorfall bestehen muss. Diese Regel gilt jedoch nicht unmittelbar für den CRA. Ob die angekündigte CRA-Guidance den Zeitpunkt der Kenntniserlangung vergleichbar auslegt, bleibt abzuwarten. Hersteller sollten deshalb einen schnellen und dokumentierten Weg vom Eingang eines Hinweises zur ersten fachlichen Bewertung festlegen. Eine pauschale Pflicht, jeden Eingang rund um die Uhr zu überwachen, lässt sich daraus derzeit nicht belastbar ableiten.
Der 24-Stunden-Selbstcheck
Bewerten Sie jedes der folgenden acht Themenfelder anhand der zugehörigen Fragen. Vergeben Sie anschließend für das gesamte Themenfeld:
- 2 Punkte: umgesetzt, dokumentiert und praktisch erprobt;
- 1 Punkt: grundsätzlich geregelt, aber lückenhaft, informell oder von Einzelpersonen abhängig;
- 0 Punkte: nicht vorhanden oder derzeit ungeklärt.
Maximal sind 16 Punkte erreichbar. Der Punktwert dient der Orientierung und ist kein Nachweis der CRA-Konformität.
1. Kennen Sie die betroffenen Produkte und Verantwortlichen?
- Haben Sie ein aktuelles Verzeichnis der Produkte mit digitalen Elementen, die Sie als Hersteller auf dem EU-Markt bereitstellen?
- Können Sie eine Meldung eindeutig einem Produkt, einer Version und gegebenenfalls einer Variante zuordnen?
- Ist für jedes Produkt eine fachlich verantwortliche Stelle benannt?
- Kennen Sie relevante Komponenten und Abhängigkeiten von Drittanbietern?
- Ist nachvollziehbar, wie lange das jeweilige Produkt unterstützt wird?
Wenn bereits das Produktportfolio unklar ist, lässt sich die Betroffenheit durch eine Schwachstelle kaum verlässlich feststellen. Die Produktübersicht ist deshalb keine reine Dokumentationsaufgabe, sondern eine Voraussetzung für die Meldefähigkeit.
2. Erreichen Hinweise die richtige Stelle?
- Gibt es einen veröffentlichten und überwachten Kontakt für externe Schwachstellenmeldungen?
- Werden Hinweise aus Support, Entwicklung, Penetrationstests, Schwachstellenscannern und externen Quellen zusammengeführt?
- Erkennt der Support, wann ein Vorgang an Product Security oder ein PSIRT weiterzugeben ist?
- Sind Stellvertretungen für Urlaub, Krankheit und andere Abwesenheiten geregelt?
- Ist festgelegt, wie mit unvollständigen oder zunächst wenig plausiblen Hinweisen umgegangen wird?
Ein Ticketsystem löst diese Fragen nicht automatisch. Es dokumentiert einen Vorgang, entscheidet aber weder über Produktbetroffenheit noch über eine regulatorische Eskalation.
3. Können Sie die Produktbetroffenheit kurzfristig bewerten?
- Können Sie feststellen, ob eine betroffene Bibliothek oder Komponente in Ihren Produkten enthalten ist?
- Sind Produktversionen, Komponentenstände und technische Zuständigkeiten ausreichend dokumentiert?
- Können die erforderlichen Fachleute kurzfristig eingebunden werden?
- Gibt es eine festgelegte Methodik zur technischen Bewertung einer Schwachstelle?
- Können Sie begründen, warum ein Produkt betroffen oder nicht betroffen ist?
Eine Software Bill of Materials kann die Zuordnung erleichtern. Sie ersetzt aber weder die technische Analyse noch die Entscheidung, wie mit einer konkreten Schwachstelle umzugehen ist.
4. Ist die Meldeentscheidung geregelt?
- Sind die Kriterien für eine aktiv ausgenutzte Schwachstelle im Prozess berücksichtigt?
- Ist definiert, wie ein schwerwiegender Sicherheitsvorfall erkannt und bewertet wird?
- Ist klar, wer die Meldung fachlich vorbereitet und wer sie freigibt?
- Sind Entwicklung, Product Security, Recht, Kommunikation und Geschäftsführung sinnvoll eingebunden?
- Kann eine Frühwarnung auch dann abgegeben werden, wenn nach 24 Stunden noch keine vollständige Ursachenanalyse vorliegt?
- Wird auch eine Entscheidung gegen eine Meldung nachvollziehbar dokumentiert?
Die kurze Frist verlangt keine vollständige technische Aufklärung innerhalb von 24 Stunden. Sie verlangt aber einen Prozess, der mit einem zunächst unvollständigen Informationsstand umgehen kann.
5. Funktioniert der Ablauf auch außerhalb des Normalfalls?
- Wie werden Hinweise außerhalb der regulären Arbeitszeiten entgegengenommen und wann beginnt die fachliche Bewertung?
- Wer entscheidet, wenn die primär verantwortliche Person nicht verfügbar ist?
- Kann das Unternehmen mehrere gleichzeitig betroffene Produkte bearbeiten?
- Sind externe Entwicklungs- und Technologiepartner vertraglich und organisatorisch eingebunden?
- Sind die benötigten Informationen und Systeme ohne einzelne Schlüsselpersonen zugänglich?
Der CRA schreibt damit nicht pauschal eine bestimmte Organisationsform vor. Das Unternehmen muss jedoch praktisch sicherstellen, dass die gesetzlichen Fristen eingehalten werden können.
6. Können Sie eine Meldung tatsächlich abgeben?
- Ist bekannt, welche Angaben die Frühwarnung enthalten muss?
- Ist geregelt, wer für das Unternehmen meldet?
- Sind erforderliche Zugänge und Berechtigungen vorbereitet?
- Kann die Freigabe ohne unnötige Abstimmungsschleifen erfolgen?
- Ist festgelegt, wie vertrauliche Informationen behandelt werden?
- Werden alle Fristen nach der ersten Meldung zuverlässig verfolgt?
Ein Prozessdiagramm ist erst dann belastbar, wenn die Beteiligten auch über die erforderlichen Informationen, Befugnisse und Zugänge verfügen.
7. Sind Folgemeldung, Behebung und Kommunikation verbunden?
- Geht die erste Bewertung strukturiert in die vertiefte technische Analyse über?
- Sind Korrektur- und Risikominderungsmaßnahmen mit Verantwortlichen und Terminen hinterlegt?
- Können betroffene Nutzer zielgerichtet informiert werden?
- Ist nachvollziehbar, welche Produktversionen ein Sicherheitsupdate benötigen?
- Werden die für den Abschlussbericht erforderlichen Informationen fortlaufend gesammelt?
Meldung und Behebung dürfen keine getrennten Prozesse sein. Andernfalls muss das Meldeteam Informationen nachträglich zusammensuchen, während die Fristen weiterlaufen.
8. Haben Sie den Prozess bereits erprobt?
- Wurde ein realistischer Schwachstellenfall als Tabletop Exercise durchgespielt?
- Wurden die benötigten Zeiten für Zuordnung, Bewertung, Eskalation und Freigabe gemessen?
- Waren alle erforderlichen Rollen beteiligt?
- Wurden erkannte Lücken dokumentiert und behoben?
- Ist eine Wiederholung nach wesentlichen Prozess- oder Produktänderungen vorgesehen?
Erst eine Übung zeigt, ob die beschriebenen Abläufe auch unter Zeitdruck funktionieren.
Auswertung: Wo steht Ihr Unternehmen?
| Punktzahl | Einordnung | Sinnvoller nächster Schritt |
|---|---|---|
| 13 bis 16 Punkte | Gute Ausgangslage. Prüfen Sie, ob die beschriebenen Abläufe auch in einem realistischen Fall und bei Abwesenheit einzelner Schlüsselpersonen funktionieren. | Tabletop Exercise und gezielte Prüfung der Nachweise. |
| 8 bis 12 Punkte | Wesentliche Bestandteile sind vorhanden, greifen aber noch nicht zuverlässig ineinander. Die Einhaltung der Fristen hängt wahrscheinlich von einzelnen Personen oder improvisierten Entscheidungen ab. | Strukturierte CRA-Beratung und priorisierter Maßnahmenplan; bei bereits vorhandenen Prozessen gegebenenfalls eine gezielte Gap-Analyse. |
| 0 bis 7 Punkte | Eine fristgerechte und nachvollziehbare Meldung ist derzeit nicht verlässlich abgesichert. | Produktübersicht, Zuständigkeiten und Meldeprozess priorisiert aufbauen und anschließend erproben. |
Unabhängig von der Gesamtpunktzahl besteht unmittelbarer Handlungsbedarf, wenn einer dieser Punkte fehlt: ein belastbares Produktverzeichnis, ein überwachter Eingangskanal, technische Bewertungskompetenz, eine entscheidungsbefugte Rolle, ein geregelter Plattformzugang oder eine funktionierende Stellvertretung.
Diese Einordnung ist ein Selbstcheck. Sie ist weder eine rechtliche Bewertung des Einzelfalls noch ein Nachweis der CRA-Konformität.
Praxisbeispiel: Das Ticket ist da – die Entscheidung fehlt
Ein externer Sicherheitsforscher meldet eine mögliche Schwachstelle in einer Open-Source-Komponente. Der Support legt innerhalb weniger Minuten ein Ticket an. Damit ist der Hinweis dokumentiert, aber noch nicht geklärt, ob tatsächlich eine aktiv ausgenutzte Schwachstelle in einem eigenen Produkt vorliegt. Für die erste fachliche Bewertung bleiben entscheidende Fragen offen:
- In welchen Produkten und Versionen wird die Komponente verwendet?
- Ist die beschriebene Angriffsmöglichkeit in der konkreten Produktkonfiguration erreichbar?
- Gibt es Hinweise auf eine aktive Ausnutzung?
- Wer darf eine Meldung auslösen?
- Welche Informationen können nach 24 Stunden belastbar angegeben werden?
- Wer übernimmt die weitere Analyse und die Folgemeldung?
Das Problem ist nicht die Geschwindigkeit des Ticketsystems. Es fehlt die belastbare Verbindung zwischen Produktwissen, technischer Bewertung und regulatorischer Entscheidung.
Wie wir Sie beim CRA unterstützen
Der Selbstcheck zeigt mögliche Schwachstellen. Er beantwortet aber noch nicht, welche CRA-Anforderungen für Ihre Produkte und Prozesse relevant sind. In unserer CRA-Beratung ordnen wir gemeinsam Ihre Ausgangslage ein, klären offene Anforderungen und leiten sinnvolle nächste Schritte ab.
Zunächst besprechen wir Ihr Produktportfolio und die voraussichtliche Einordnung der betrachteten Produkte. Anschließend betrachten wir gemeinsam mit den beteiligten Rollen insbesondere:
- Entwicklungsprozesse,
- Schwachstellenmanagement und Incident Response,
- Third-Party-Management,
- technische Anforderungen,
- Testing.
Welche Unterstützung sinnvoll ist, hängt von Ihrem Stand ab. Geht es um Einordnung, Anforderungen und Vorgehen, steht die CRA-Beratung im Vordergrund. Sind Prozesse und Dokumente bereits vorhanden, können wir sie in einer gezielten Gap-Analyse systematisch gegen definierte Anforderungen prüfen. Die Gap-Analyse ist damit ein mögliches Modul der Beratung und nicht deren Oberbegriff.
Damit erhalten Sie keine pauschale Konformitätsaussage, sondern eine belastbare Arbeitsgrundlage: offene Punkte, ihre Bedeutung für Produkte und Prozesse sowie eine nachvollziehbare Reihenfolge für die weitere Umsetzung.
Anschließend wissen Sie:
- welche Bestandteile bereits belastbar umgesetzt sind;
- welche Abläufe nur informell oder personenabhängig funktionieren;
- welche Nachweise fehlen;
- welche Lücken vor dem 11. September 2026 besonders dringlich sind;
- welche weiteren Schritte für die vollständige Anwendung des CRA ab Dezember 2027 vorbereitet werden sollten.
Ein Cybersecurity-Test für digitale Produkte kann dabei wichtige Schwachstellen und technische Erkenntnisse liefern. Er ersetzt jedoch weder das Schwachstellenmanagement noch die organisatorischen und regulatorischen Prozesse des Herstellers. Wie Findings anschließend systematisch bewertet und behoben werden können, erläutert der Beitrag Was mache ich als Kunde mit einem Pentestbericht?
Ist Ihr CRA-Meldeprozess bereit für September 2026?
Wenn Sie bei mehreren Fragen mit „Teilweise“ oder „Nein“ geantwortet haben, klären wir mit Ihnen, wo die Ursachen liegen und welche Form der Unterstützung zu Ihrem Stand passt. Die CRA-Beratung verbindet regulatorische Anforderungen mit Ihren Produkten, Entwicklungsprozessen und vorhandenen Nachweisen.
CRA-Beratung unverbindlich besprechen
Häufige Fragen zu den CRA-Meldepflichten
Ja. Die Meldepflichten nach Artikel 14 CRA gelten ab dem 11. September 2026. Die wesentlichen übrigen Verpflichtungen des CRA werden grundsätzlich ab dem 11. Dezember 2027 anwendbar.
Nein. Artikel 14 CRA bezieht sich insbesondere auf aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle mit Auswirkungen auf die Sicherheit des Produkts. Jede Schwachstelle muss aber angemessen erfasst, bewertet und behandelt werden.
Nein. Innerhalb von 24 Stunden ist zunächst eine Frühwarnung vorgesehen. Der Prozess muss deshalb eine erste belastbare Bewertung und Meldung ermöglichen, obwohl noch nicht alle technischen Einzelheiten feststehen.
Das hängt von seinem Anwendungsbereich ab. Ein allgemeiner Prozess für die Unternehmens-IT deckt Produktverantwortung, Produktversionen, externe Komponenten, Nutzerkommunikation und Schwachstellenbehandlung nicht automatisch ab.
Die konkrete Ausgestaltung hängt vom Produkt und vom Unternehmen ab. Die Beratung kann die Einordnung des Produktportfolios, relevante CRA-Anforderungen, Entwicklungsprozesse, Schwachstellenmanagement, Incident Response, Third-Party-Management, technische Anforderungen und Testing umfassen. Eine Gap-Analyse ist sinnvoll, wenn vorhandene Prozesse und Dokumente gezielt geprüft werden sollen.
Nein. Eine CRA-Beratung ordnet Anforderungen und Umsetzungsstand ein und zeigt sinnvolle nächste Maßnahmen. Sie ist keine Zertifizierung und keine Garantie, dass sämtliche Anforderungen im Einzelfall erfüllt sind.