TL;DR
- Zehn verbreitete Annahmen zur CRA-Meldung, die Teams beim Start von Artikel 14 am 11.09.2026 in die Bredouille bringen.
- Die häufigsten: „Dezember 2027 ist die eigentliche Frist“ und „Wir sind SaaS, also ausgenommen“ – beide falsch.
CRA Meldepflicht Irrtümer – Nr. 1: „Die eigentliche Frist ist Dezember 2027 – wir haben Zeit”
Der teuerste aller Irrtümer. Der 11. Dezember 2027 ist, wenn die vollen Produktanforderungen gelten (Konformitätsbewertung, technische Dokumentation, CE-Kennzeichnung). Die Meldepflicht nach Artikel 14 startet 15 Monate früher, am 11. September 2026 – und die Übergangsregel nimmt die Meldung ausdrücklich aus: Sie gilt für alle erfassten Produkte, die vor Dezember 2027 in Verkehr gebracht wurden, verändert oder nicht. Ein 2023 ausgeliefertes Produkt kann außerhalb der CE-Regeln liegen und heute dennoch meldepflichtig sein, wenn eine Schwachstelle darin aktiv ausgenutzt wird. Ihr Bestand ist im Melde-Scope, auch wo er sonst außen vor ist.
2. „Wir sind SaaS, also ausgenommen”
Teils wahr, leicht falsch. Eigenständiges SaaS liegt meist außerhalb des CRA – doch sobald eine Cloud-Komponente eine „Lösung zur Datenfernverarbeitung” ist (das Produkt kann seine Funktion ohne sie nicht erfüllen), fällt sie zurück in den Scope. „Wir sind SaaS” ist eine gegen Ihre Architektur zu prüfende Behauptung, keine Schlussfolgerung.
3. „Jede gefundene Schwachstelle muss gemeldet werden”
Nein. Die Pflicht erfasst nur zwei Dinge: Schwachstellen mit belastbaren Hinweisen auf tatsächliche Ausnutzung und schwerwiegende Vorfälle, die die Produktsicherheit betreffen. Eine Schwachstelle, die Sie finden und patchen, bevor sie jemand ausnutzt, bleibt in Ihrem normalen Schwachstellenprozess und berührt die 24-Stunden-Frist nie – siehe unsere CRA Schwachstellenmeldung.
CRA Meldepflicht Irrtümer – Nr. 4: „Wird eine genutzte Bibliothek irgendwo ausgenutzt, müssen wir melden”
Auslöser ist die Ausnutzung einer Schwachstelle in Ihrem Produkt – nicht die Tatsache, dass eine von Ihnen eingebundene Komponente anderswo in einem fremden Produkt ausgenutzt wurde. Geteilte Abhängigkeiten heißen geteilte Schwachstellen, nicht geteilte Melde-Auslöser. Ein Irrtum wie dieser löst sich mit einem guten Komponenten-Inventar: Zu wissen, wo eine Komponente tatsächlich eingesetzt wird und ob die Ausnutzung Ihre eigene Angriffsfläche berührt, zählt mehr als die trendende CVE-ID.
5. „Wir müssen gesetzlich laufend auf Exploits überwachen”
Artikel 14 schafft keine eigenständige Überwachungspflicht. Die Pflicht wird durch Kenntnis ausgelöst – hinreichende Gewissheit, dass Ihr Produkt betroffen ist – und die meisten meldepflichtigen Fälle beginnen mit einem Eingang: einer CVD-Meldung, einem Kundenhinweis, einem Bericht im PSIRT-Postfach. Gute Erkennung zählt enorm, doch laufende Überwachung ist eine Anforderung, die auf die volle Anwendung im Dezember 2027 auszulegen ist, nicht auf September 2026.
6. „Wir brauchen vollständige SBOMs für jedes Legacy-Produkt bis September”
Fehl-Investition gegen die falsche Frist. Formale SBOM- und Schwachstellenpflichten (Anhang I) gelten ab Dezember 2027. Bis September brauchen Sie genug Komponenten-Transparenz, um bei einem Advisory zu wissen, ob die betroffene Komponente in einem Ihrer Produkte steckt – keine voll versionierte SBOM für jede je verkaufte SKU.
CRA Meldepflicht Irrtümer – Nr. 7: „Eine Person genügt”
Die Single Reporting Platform erlaubt zwei benannte Konten je Hersteller – einen primären und einen sekundären Vertreter –, beide über EU Login, und beide schon heute anlegbar, bevor die Plattform live geht (siehe unser CRA Single Reporting Platform-Update). Ein einzelner Melder, der schläft, im Urlaub oder weg ist, ist genau das Versagensmuster, das eine 24-Stunden-Frist offenlegt. Beide EU-Login-Konten jetzt einzurichten kostet fast nichts und nimmt ein reales Risiko.
8. „Eine Meldung macht die Schwachstelle öffentlich”
Ein häufiger Zögergrund. Das empfangende CSIRT kann die Weitergabe aus Cybersicherheitsgründen verzögern oder zurückhalten, und die volle Offenlegung wird meist zurückgehalten, bis ein Fix existiert – eine ungepatchte, aktiv ausgenutzte Lücke publik zu machen, würde Angreifern eine Blaupause liefern. Nichts davon pausiert Ihre eigene 24/72-Stunden-Frist; es betrifft nur, wer den Inhalt wann sieht. Vertraulichkeit ist einer der hartnäckigsten dieser Irrtümer, und die Angst vor Offenlegung bringt Teams genau dazu, zu spät zu melden.
9. „Wir warten, bis wir völlig sicher sind”
Auf die vollständige forensische Bestätigung zu warten, ist kein gültiger Grund, das 24-Stunden-Fenster zu verpassen. Die Schwelle ist „hinreichende Gewissheit” nach einer ersten Bewertung, kein Beweis über jeden Zweifel. Eine noch laufende Untersuchung mit dem Ziel voller Gewissheit entschuldigt keine verspätete Meldung, sobald diese Schwelle überschritten ist – siehe „Kenntniserlangung” in unseren CRA Meldepflichten.
CRA Meldepflicht Irrtümer – Nr. 10: „Wir automatisieren die Einreichung per API”
Die gibt es bislang nicht. Die Einreichung erfolgt durch eine Person, die ein Webformular ausfüllt. Erkennung, Triage und Entwurf lassen sich intern automatisieren, doch die eigentliche Einreichung braucht einen benannten Menschen, erreichbar und handlungsfähig – auch außerhalb der Bürozeiten und am Wochenende.
Was diese CRA Meldepflicht Irrtümer ergeben
Diese CRA Meldepflicht Irrtümer teilen eine Wurzel: Artikel 14 als einmal zu finalisierendes Dokument zu behandeln statt als im laufenden Betrieb gelebte Fähigkeit. Wer am 11. September gut dasteht, hat nicht den dicksten Ordner – sondern zwei Melder benannt, die EU-Login-Konten erstellt, eine grobe 24-Stunden-Vorlage gebaut und geklärt, wer ans Telefon geht, wenn eine Meldung im Postfach landet.
● Artikel 14 ist ab 11. September 2026 aktiv – eine gelebte Fähigkeit schlägt jeden dicken Ordner.
Die meisten dieser Irrtümer verschwinden, sobald Meldung eine eingeübte Fähigkeit ist statt eines Dokuments. COMPLYD liefert einen einsatzbereiten Workflow für beide Melde-Tracks, rund um die 24h/72h/Abschluss-Stufen. Sehen Sie die CRA Incident Reporting Software, testen Sie unser kostenloses CRA-Online-Check-Tool, oder buchen Sie eine Demo.
Häufige Fragen
Sind Legacy-Produkte im CRA-Melde-Scope?
Ja. Die Meldepflicht nach Artikel 14 gilt für erfasste Produkte, die vor Dezember 2027 in Verkehr gebracht wurden, auch wo sie außerhalb der CE- und Konformitätsanforderungen liegen.
Muss ich jede Schwachstelle melden?
Nein – nur aktiv ausgenutzte Schwachstellen (Hinweise auf tatsächliche Ausnutzung) und schwerwiegende Vorfälle, die Ihr Produkt betreffen. Normal entdeckte und gepatchte Schwachstellen sind nach Artikel 14 nicht meldepflichtig.
Kann ich die Einreichung automatisieren?
Derzeit nicht. Erkennung, Triage und Entwurf ja, doch die Einreichung selbst ist ein von einem benannten, erreichbaren Menschen ausgefülltes Webformular – benennen Sie jetzt einen primären und sekundären Melder.
Passend zu diesem Beitrag
Im CRA Leitfaden · Schritt 7
Im CRA Leitfaden · Schritt 6
Wo steht dein Produkt beim Cyber Resilience Act?
Erste Einordnung in Minuten – oder direkt die Software ansehen, die aus dem Gesetzestext einen Workflow macht.
Zuletzt aktualisiert am 25. September 2026 · Quellen: Verordnung (EU) 2024/2847 (CRA) — EUR-Lex, ENISA — Single Reporting Platform
Stephan Hutterer
Gründer & CEO, COMPLYD
Produktsicherheits-Spezialist mit über 20 Jahren Erfahrung im Schutz kritischer OT-Systeme und tiefer IEC-62443-Expertise. Er gründete COMPLYD, um den EU Cyber Resilience Act für Produktteams umsetzbar zu machen.