Das Wichtigste in 60 Sekunden / tl;dr
- Ab 11. September 2026 müssen aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle bei betroffenen digitalen Produkten melden.
- Die erste Warnung ist grundsätzlich binnen 24 Stunden, die ausführlichere Meldung binnen 72 Stunden ab Kenntnis abzugeben.
- Nicht jede Schwachstelle und nicht jeder Ausfall ist automatisch meldepflichtig. Entscheidend sind aktive Ausnutzung beziehungsweise die gesetzlich definierte Schwere des Vorfalls.
- Die Single Reporting Platform soll bis zum Stichtag betriebsbereit sein. Ein EU Login kann vorab angelegt werden; die eigentliche SRP-Registrierung soll laut ENISA erst bei einem konkreten Meldebedarf beginnen.
- Die vollständigen Produkt-, Entwicklungs- und Konformitätspflichten gelten überwiegend ab 11. Dezember 2027. Der Meldeprozess braucht jedoch schon 2026 Produktinventar, Zuständigkeiten und technische Belege.
Quellen: Verordnung (EU) 2024/2847 (Cyber Resilience Act) · EU-Kommission: CRA-Meldepflichten · EU-Kommission: Zeitplan der CRA-Umsetzung
01
Am Stichtag beginnt die Meldepflicht, nicht der gesamte CRA
Der Cyber Resilience Act ist seit Dezember 2024 in Kraft. Seine Hauptpflichten gelten überwiegend ab dem 11. Dezember 2027. Artikel 14 über die Meldung aktiv ausgenutzter Schwachstellen und schwerer Sicherheitsvorfälle wird jedoch bereits am 11. September 2026 anwendbar.
Das ist operativ entscheidend: Eine Organisation kann die spätere Konformitätsarbeit noch planen, während bei einem konkreten Sicherheitsereignis bereits 2026 die Uhr läuft. Die Meldefähigkeit lässt sich deshalb nicht auf das nächste Produkt-Release verschieben.
11. Juni 2026
Vorschriften zu notifizierten Konformitätsbewertungsstellen gelten.
11. September 2026
Meldepflichten aus Artikel 14 beginnen.
11. Dezember 2027
Die Hauptpflichten des CRA werden vollständig anwendbar.
Auch ältere und nicht mehr unterstützte Produkte können betroffen sein
Artikel 14 gilt ab dem 11. September 2026 für alle Produkte mit digitalen Elementen im CRA-Anwendungsbereich, auch wenn sie schon vor dem 11. Dezember 2027 in Verkehr gebracht wurden oder ihr Supportzeitraum beendet ist. Nicht rückwirkend zu melden ist eine aktive Ausnutzung, von der der bereits vor dem Stichtag wusste. Wird die aktive Ausnutzung erst danach bekannt, kann die Meldepflicht greifen.
02
Welche Software fällt überhaupt in den Anwendungsbereich?
Der CRA richtet sich an Produkte mit digitalen Elementen, die auf dem EU-Markt bereitgestellt werden und eine direkte oder indirekte logische oder physische Datenverbindung haben. Er umfasst nicht nur Geräte, sondern auch Softwareprodukte und separat vertriebene Komponenten.
Typisch im Anwendungsbereich
Desktop- und Mobile-Software, Betriebssysteme, Netzwerkprodukte, Softwarebibliotheken als eigenständiges Produkt, IoT-Geräte sowie digitale Komponenten, die separat auf dem Markt angeboten werden.
Remote-Funktionen können dazugehören
Eine entfernte Datenverarbeitungslösung kann Teil des Produkts sein, wenn sie vom entwickelt oder verantwortet wird und ohne sie eine Produktfunktion nicht erfüllt würde.
Reines SaaS ist nicht automatisch ein CRA-Produkt
Ein eigenständiger Cloud-Dienst ohne Produkt-mit-digitalen-Elementen-Bezug fällt nicht allein deshalb unter den CRA. Andere Regelwerke, etwa NIS2, können dennoch einschlägig sein.
Rollen zählen
, Einführer und Händler haben unterschiedliche Pflichten. Wer ein Produkt unter eigenem Namen oder eigener Marke anbietet oder wesentlich verändert, kann die gesetzliche Herstellerrolle übernehmen.
Kostenlos und Open Source bedeutet nicht automatisch: außerhalb des CRA
Nicht kommerziell bereitgestellte freie Open-Source-Software ist besonders behandelt. Sobald Software im Rahmen einer kommerziellen Tätigkeit auf dem Markt bereitgestellt wird, muss genauer geprüft werden. Für Open-Source-Stewards bestehen eigene, abgestufte Pflichten.
03
Wer trägt im CRA welche Rolle?
Die Person, die programmiert, ist nicht automatisch der . Entscheidend ist vor allem, wer das Produkt entwickelt oder entwickeln lässt und es unter eigenem Namen oder eigener Marke auf dem EU-Markt anbietet.
Eigenes Produkt unter eigener Marke
Das anbietende Unternehmen trägt regelmäßig die gesetzliche Herstellerrolle, auch wenn ein externer Dienstleister entwickelt hat.
Kundenprodukt unter Kundenmarke
Der Kunde kann sein. Der beauftragte Entwickler bleibt regelmäßig technischer Dienstleister.
Fertiges Fremdprodukt im Betrieb
Der Kunde ist typischerweise Betreiber oder Nutzer. Der ursprüngliche Anbieter trägt regelmäßig die Herstellerrolle.
Wesentlich verändert und erneut angeboten
Wer ein Produkt wesentlich verändert und erneut auf dem Markt bereitstellt, kann selbst Herstellerpflichten übernehmen.
Rechtliche Verantwortung und technische Arbeit trennen
Der kann Entwicklung, Hosting, Monitoring und Wartung beauftragen. Betreiber und technische Dienstleister müssen die benötigten Informationen und Maßnahmen zuverlässig zuliefern. Die gesetzliche Rollenverteilung ändert sich durch die Beauftragung aber nicht automatisch.
04
Was muss gemeldet werden und was nicht?
Die Meldepflicht fokussiert zwei Ereignistypen. Ein normaler Bug, eine nur theoretisch bekannte Schwachstelle oder eine kurze betriebliche Störung ist nicht automatisch ein CRA-Fall.
Aktiv ausgenutzte Schwachstelle
Es gibt verlässliche Anhaltspunkte, dass ein böswilliger Akteur die Schwachstelle ohne Erlaubnis eines Systeminhabers tatsächlich ausgenutzt hat.
Schwerer Sicherheitsvorfall
Der Vorfall beeinträchtigt oder gefährdet den Schutz der Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit sensibler oder wichtiger Daten oder Funktionen. Alternativ hat er böswilligen Code in das Produkt oder in Systeme eines Nutzers eingebracht oder kann dazu führen.
Nicht automatisch meldepflichtig
- Eine Schwachstelle ist bekannt, aber es gibt keine verlässlichen Hinweise auf aktive Ausnutzung.
- Ein gewöhnlicher Funktionsfehler hat keine relevante Auswirkung auf die Produktsicherheit.
- Ein isolierter Infrastrukturvorfall betrifft das digitale Produkt nicht in der gesetzlich beschriebenen Weise.
- Eine Meldung von Forschenden allein beweist noch keine aktive Ausnutzung; sie kann aber sofortige Untersuchung auslösen.
Die Entscheidung „nicht meldepflichtig“ sollte nicht nur im Chat oder im Kopf einer Person existieren. Eine kurze dokumentierte Begründung mit Faktenstand und Zeitpunkt ist im Nachhinein deutlich belastbarer.
05
24 Stunden, 72 Stunden und der Abschlussbericht
Die Fristen laufen ab dem Zeitpunkt, an dem der Kenntnis erlangt. Genau dieser Zeitpunkt muss deshalb organisatorisch und technisch feststellbar sein.
Wer die Meldung tatsächlich erhält
Die Meldung wird über den elektronischen Zugangspunkt des koordinierenden CSIRT des Mitgliedstaats übermittelt, in dem der seine Hauptniederlassung in der Union hat. Sie ist gleichzeitig für ENISA zugänglich. Für ohne Hauptniederlassung in der Union regelt Artikel 14 Absatz 7 eine gestufte Zuständigkeit.
Binnen 24 Stunden
Frühwarnung über die Single Reporting Platform. Bei Vorfällen ist, soweit verfügbar, auch anzugeben, ob rechtswidrige oder böswillige Handlungen vermutet werden.
Binnen 72 Stunden
Ausführlichere Meldung mit den bis dahin verfügbaren allgemeinen Informationen. Je nach Fall gehören dazu Produkt und Art der Schwachstelle oder Ausnutzung beziehungsweise Art und erste Bewertung des Vorfalls sowie ergriffene oder für Nutzer verfügbare Abhilfemaßnahmen.
Schwachstelle: Abschluss
Spätestens 14 Tage nachdem eine Korrektur- oder Abhilfemaßnahme verfügbar ist, folgt der Abschlussbericht mit Analyse und Angaben zur Maßnahme.
Schwerer Vorfall: Abschluss
Der Abschlussbericht ist grundsätzlich binnen eines Monats nach der 72-Stunden-Meldung einzureichen.
Praxisbeispiel: Vom Schwachstellenhinweis zur CRA-Meldung
Ein fiktiver Ablauf zeigt, wann aus einem technischen Alarm ein meldepflichtiger Fall werden kann und ab welchem Zeitpunkt die Fristen laufen.
Beispiel anzeigen
Dienstag, 09:10 Uhr: Hinweis eingegangen
Ein automatischer Scan meldet eine neue in einer verwendeten Login-Bibliothek. Das Team prüft, welche Produktversionen die Bibliothek enthalten und ob der betroffene Code tatsächlich verwendet und erreichbar ist. Der Treffer allein löst noch keine CRA-Meldung aus.
Dienstag, 11:40 Uhr: Aktive Ausnutzung bestätigt
Logdaten zeigen gezielte Angriffsversuche gegen eine betroffene Kundeninstallation. Die erste technische Bewertung ergibt mit hinreichender Sicherheit, dass die Schwachstelle im eigenen Produkt aktiv ausgenutzt wird. Dieser Zeitpunkt wird als Kenntnisnahme dokumentiert.
Bis Mittwoch, 11:40 Uhr: Frühwarnung
Der CRA-Hersteller übermittelt innerhalb von 24 Stunden die verfügbaren Informationen über die Single Reporting Platform. Die Untersuchung läuft parallel weiter.
Bis Freitag, 11:40 Uhr: Ausführlichere Meldung
Innerhalb von 72 Stunden folgen Angaben zu Produkt, betroffenen Versionen, Schwachstelle, bisheriger Auswirkung und bereits ergriffenen Schutzmaßnahmen.
Parallel: Kunden schützen
Gefährdete Funktionen werden eingeschränkt, betroffene Kunden informiert und ein Sicherheitsupdate vorbereitet. Veröffentlichung, Rollout und Wirksamkeit des Updates werden dokumentiert.
Nach Bereitstellung der Abhilfe: Abschlussbericht
Spätestens 14 Tage nachdem die Korrektur oder Abhilfemaßnahme verfügbar ist, folgt der Abschlussbericht mit technischer Analyse und Beschreibung der umgesetzten Maßnahmen.
Entscheidend ist nicht der erste -Alarm. Entscheidend ist der dokumentierte Zeitpunkt, an dem die erste Bewertung mit hinreichender Sicherheit eine aktive Ausnutzung der Schwachstelle im eigenen Produkt ergibt.
Die Meldung an Behörden ist nicht der einzige Kommunikationsweg
Nach Kenntnis einer aktiv ausgenutzten Schwachstelle oder eines schweren Sicherheitsvorfalls muss der betroffene Nutzer und gegebenenfalls alle Nutzer informieren. Inhalt, Empfängerkreis und Zeitpunkt sind risikobasiert und verhältnismäßig zu bestimmen. Das verlangt keine wahllose öffentliche Offenlegung technischer Details, die weitere Angriffe erleichtern könnte.
06
Ein belastbarer Meldeprozess in sieben Übergaben
Ein PDF-Notfallplan allein genügt nicht. Der Prozess muss dort beginnen, wo Hinweise tatsächlich eintreffen: Support, Monitoring, E-Mail, Bugtracker, Abhängigkeitswarnungen oder externe Sicherheitsforschung.
Eingang sichern
Zentralen Sicherheitskontakt und interne Eskalationswege definieren; Meldungen erhalten eine unveränderliche Eingangszeit.
Produkt zuordnen
Betroffenes Produkt, Version, Mandanten, Regionen, Komponenten und Verantwortliche aus einem gepflegten Inventar bestimmen.
Fakten trennen
Bestätigte Beobachtungen, Annahmen, offene Fragen und fremde Angaben getrennt festhalten.
Ereignis klassifizieren
Aktive Ausnutzung und Schwerekriterien strukturiert prüfen; Rechts- und Sicherheitsverantwortliche bei Grenzfällen einbinden.
Frist und Owner setzen
Kenntniszeitpunkt, 24-/72-Stunden-Deadline, verantwortliche Person und Vertretung sichtbar machen.
Melden und weiter untersuchen
Frühwarnung fristgerecht mit vorhandenem Wissen abgeben; Unsicherheit ist kein Grund, die Untersuchung bis kurz vor Fristende aufzuschieben.
Abhilfe und Abschluss verbinden
Patch, Kundeninformation, Rollout, Wirksamkeitsprüfung und Abschlussbericht auf denselben Vorgang beziehen.
Ein kleiner Anbieter braucht nicht zwingend ein eigenes SOC. Er braucht aber einen eindeutigen Eingang, eine entscheidungsfähige Rufkette, Zugriff auf Produktwissen und eine geübte Vertretung.
07
Welche technischen Belege im Ernstfall Zeit sparen
Die Meldung verlangt keine perfekte Forensik nach wenigen Stunden. Ohne vorbereitete Produkt- und Betriebsdaten bleibt aber schon die erste Bewertung unnötig vage.
Produkt- und Versionsinventar
Welche Versionen sind im Feld, bei welchen Kunden und mit welchen Supportzeiträumen?
Komponenten und Abhängigkeiten
Welche Bibliothek oder Komponente steckt in welchen Builds? Eine SBOM kann helfen, ersetzt aber keine gepflegte Zuordnung.
Security- und Betriebslogs
Zeitlich konsistente, zugriffsgeschützte Logs für relevante Authentifizierungs-, Administrations- und Updatevorgänge.
Updatepfad
Wie wird eine Korrektur gebaut, geprüft, verteilt, überwacht und bei Problemen zurückgenommen?
Entscheidungsprotokoll
Wer wusste wann was, welche Einordnung wurde getroffen und welche offenen Punkte bestanden?
Kontakt- und Vertretungsmatrix
Produkt, Security, Geschäftsführung, Datenschutz, Recht, Support und externe Dienstleister mit echten Stellvertretungen.
Zugangsdaten für die Meldeplattform gehören nicht in ein gemeinsam genutztes Incident-Dokument oder Ticket. Ein EU Login kann vorab sicher eingerichtet und die interne Vertretungsbefugnis geklärt werden. ENISA empfiehlt jedoch, die eigentliche SRP-Registrierung und die Validierung durch das zuständige CSIRT erst zu starten, wenn eine konkrete Meldung abgegeben werden muss.
08
Was ich an Bestandssystemen konkret nachrüste
Für meine Kunden setze ich ein kompaktes CRA-Readiness-Update mit vier technischen Basisbausteinen um. Zusätzlich biete ich eine laufende Überwachung der eingesetzten Open-Source-Pakete an:
Sicherheitsereignisse erfassen
Auffällige Anmeldungen, unberechtigte Zugriffe und kritische Änderungen werden nachvollziehbar protokolliert.
Technisches Beispiel
Strukturierte, zugriffsgeschützte Logs mit Zeitstempel, Produktversion und Korrelations-ID.
Softwarebestand dokumentieren
Für jede Produktversion wird automatisch eine maschinenlesbare Komponentenliste erzeugt.
Technisches Beispiel
SBOM im CycloneDX- oder SPDX-Format, automatisch während des Builds erstellt.
Schwachstellen sicher melden
Sicherheitsforschende erhalten einen eindeutigen Kontakt und einen geregelten Meldeweg.
Technisches Beispiel
Eigene Sicherheitsadresse, CVD-Richtlinie und /.well-known/security.txt.
Updates sicher ausliefern
Jede veröffentlichte Version wird eindeutig dokumentiert, getestet und kontrolliert verteilt. So lässt sich feststellen, welche Installationen betroffen sind und ob ein Sicherheitsupdate erfolgreich ausgerollt wurde.
Technisches Beispiel
Versionierte Releases, automatisierte Tests, Release Notes, Prüfsummen oder Signaturen, stufenweiser Rollout und ein vorbereiteter Rollback.
SBOM-Sicherheitsmonitoring (optional)
Die Komponentenliste wird regelmäßig mit neuen Einträgen aus dem -Katalog abgeglichen. Treffer bei verwendeten Open-Source-Paketen werden den betroffenen Produktversionen zugeordnet und fachlich bewertet.
Technisches Beispiel
Automatisierter Dependency-Scan mit Paket- und Versionsabgleich, Benachrichtigung bei neuen Treffern sowie Prüfung von Herstellerhinweisen, tatsächlicher Betroffenheit, Code-Erreichbarkeit und verfügbarer Abhilfe.
Diese Maßnahmen unterstützen Erkennung, Bewertung und Meldung von Sicherheitsproblemen. Ein Treffer im -Katalog beweist noch nicht, dass das eigene Produkt tatsächlich verwundbar oder eine CRA-Meldung erforderlich ist. Ab dem 11. September 2026 gelten zunächst die Meldepflichten. Die umfassenden technischen Produktpflichten folgen grundsätzlich ab dem 11. Dezember 2027.
09
Die Meldung ist nur der frühe Teil der CRA-Arbeit
Bis Dezember 2027 folgen wesentlich breitere Anforderungen über den Produktlebenszyklus. Wer den Meldeprozess jetzt sinnvoll baut, kann viele Grundlagen dafür wiederverwenden.
Cybersecurity-Risikobewertung
Risiken systematisch bewerten und während Planung, Entwicklung, Produktion, Bereitstellung und Wartung berücksichtigen.
Secure by design und default
Produkte ohne bekannte ausnutzbare Schwachstellen bereitstellen, Angriffsflächen begrenzen und sichere Voreinstellungen wählen.
Vulnerability Handling
Schwachstellen annehmen, untersuchen, beheben, Updates sicher verteilen und Informationen bereitstellen.
Supportzeitraum
Einen angemessenen Supportzeitraum bestimmen, dokumentieren und Sicherheitsupdates grundsätzlich ohne Verzögerung und kostenfrei bereitstellen.
Technische Dokumentation und Konformität
Klassifizierung, Risikobewertung, Nachweise, Konformitätsverfahren, EU-Konformitätserklärung und CE-Kennzeichnung vorbereiten.
10
Entscheidungsmatrix und 10-Punkte-Checkliste
Erste Einordnung eines eingehenden Ereignisses
| Signal | Sofortige Frage | Nächster Schritt |
|---|---|---|
| Schwachstellenhinweis | Gibt es verlässliche Hinweise auf aktive Ausnutzung? | Technisch validieren, Evidenz sichern, CRA-Klassifizierung starten. |
| Produktvorfall | Sind Sicherheitseigenschaften schwer beeinträchtigt und Schwerekriterien erfüllt? | Auswirkung und Reichweite bestimmen, Kenntniszeit festhalten. |
| Abhängigkeitsalarm | Gibt es Hinweise, dass die Schwachstelle in unserem Produkt aktiv ausgenutzt wird? | Betroffene Versionen, Erreichbarkeit des Codes und Hinweise auf Ausnutzung im eigenen Produkt prüfen. |
| Betriebsausfall | Ist es ein Sicherheitsvorfall des Produkts oder nur eine Betriebsstörung? | CRA und andere Meldewege getrennt prüfen. |
Vor dem 11. September erledigen
- Betroffene Produkte und Rollen der inventarisieren.
- Zentralen Sicherheitsmeldekanal und unveränderliche Eingangszeit schaffen.
- Kenntniszeitpunkt und Eskalationskriterien schriftlich definieren.
- 24-/72-Stunden-Vorlagen mit klaren Pflichtfeldern vorbereiten.
- Intern festlegen, wer im Ereignisfall melden darf und ein EU Login nutzt. Die SRP-Registrierung erst bei einer konkreten Meldung starten.
- Produkt-, Versions- und Abhängigkeitsdaten auffindbar machen.
- Verantwortliche und Stellvertretungen mit Erreichbarkeit benennen.
- Patch-, Rollback- und Kundenkommunikationspfad testen.
- Entscheidungen einschließlich „nicht meldepflichtig“ dokumentieren.
- Einen Tabletop-Test mit realistischer Schwachstelle durchführen.
11
Häufige Fragen
Muss ab September 2026 jede Sicherheitslücke gemeldet werden?
Nein. Die verpflichtende Meldung betrifft aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle im Sinne des CRA. Bekannte, aber nicht aktiv ausgenutzte Schwachstellen müssen weiterhin behandelt werden, lösen jedoch nicht allein die Artikel-14-Meldung aus.
Beginnt die 24-Stunden-Frist erst nach vollständiger technischer Bestätigung?
Nein. Nach den Kommissionsleitlinien liegt Kenntnis vor, sobald eine unverzügliche erste Bewertung mit hinreichender Sicherheit ergibt, dass eine Schwachstelle im eigenen Produkt aktiv ausgenutzt wird oder ein schwerer Sicherheitsvorfall die Produktsicherheit beeinträchtigt hat. Vollständige Forensik ist nicht erforderlich. Die erste Bewertung darf aber auch nicht künstlich verzögert werden.
Sind reine SaaS-Angebote betroffen?
Reines, eigenständiges SaaS fällt nicht automatisch als Produkt mit digitalen Elementen unter den CRA. Eine Remote-Datenverarbeitung kann aber Teil eines CRA-Produkts sein, wenn sie für dessen Funktion erforderlich ist und in der Verantwortung des s liegt.
Brauchen kleine Unternehmen denselben Prozess?
Die Meldepflicht gilt grundsätzlich auch für kleine . Der Prozess darf schlank sein, muss aber Fristen, Verantwortlichkeiten und Produktwissen zuverlässig zusammenbringen. Das CRA-Sanktionsregime nimmt Kleinst- und Kleinunternehmen speziell für das Versäumen der 24-Stunden-Frist von Geldbußen aus. Die Meldepflicht selbst entfällt dadurch nicht.
Ersetzt die CRA-Meldung andere Meldepflichten?
Nein. Je nach Organisation und Ereignis können beispielsweise NIS2-, Datenschutz- oder vertragliche Meldewege zusätzlich relevant sein. Ein guter Incident-Prozess prüft diese Wege parallel, ohne sie miteinander zu vermischen.
Kann die Meldung nachgereicht werden, wenn noch Fakten fehlen?
Die Stufen sind genau dafür vorgesehen: Frühwarnung, ausführlichere Meldung und Abschlussbericht. Vorhandene Informationen werden fristgerecht gemeldet und anschließend ergänzt.
12
Offizielle Quellen
Primärquellen und offizielle Umsetzungshinweise für diesen Beitrag. Zuletzt geprüft am 2. August 2026.
- Verordnung (EU) 2024/2847 (Cyber Resilience Act)
- EU-Kommission: CRA-Meldepflichten
- EU-Kommission: Umsetzungshinweise vom 27. Juli 2026
- EU-Kommission: FAQ zur CRA-Umsetzung
- EU-Kommission: Zeitplan der CRA-Umsetzung
- ENISA: Single Reporting Platform
- EU-Kommission: Zusammenfassung des CRA
- EU-Kommission: Pflichten der gesetzlichen Herstellerrolle
- CVE Program: Glossar und Definitionen