CRA-Meldepflicht ab 11. September 2026: Wer meldet, was und wann

Bringen Sie ein Produkt mit digitalen Elementen in Verkehr? WZ-IT beobachtet Schwachstellen in Ihren Komponenten laufend über CVE-Monitoring und ordnet mit Ihnen ein, welche Compliance-Anforderungen für Ihren Betrieb gelten. Betroffenheit gemeinsam klären

Am 11. September 2026 tritt die erste operative Pflicht des Cyber Resilience Act in Kraft. Sie ist eng zugeschnitten: Es geht ausschließlich um Meldungen, nicht um Konformitätsbewertung oder CE-Kennzeichnung. Wer meldepflichtig ist, muss ab diesem Tag innerhalb von 24 Stunden reagieren können.

Die meisten Darstellungen zählen die Fristen auf. Die schwierigere Frage kommt davor und wird selten beantwortet: Bin ich überhaupt Hersteller? Für Unternehmen, die fremde Hardware konfigurieren, Open-Source-Software bündeln und das Ergebnis unter eigenem Namen abgeben, ist die Antwort weniger eindeutig, als sie zunächst wirkt.

Dieser Beitrag ordnet ein, was am 11. September beginnt, wer davon betroffen ist, wodurch eine Meldung ausgelöst wird und was bis dahin praktisch vorbereitet sein muss.

Stand: 22. August 2026.

Inhaltsverzeichnis

• Was am 11. September 2026 beginnt
• Wer im Sinne des CRA Hersteller ist
• Wodurch eine Meldung ausgelöst wird
• Die drei Meldungen und ihre Fristen
• Was nicht unter den CRA fällt
• Open Source: Betreiber, Verwalter, Hersteller
• Was bis zum 11. September vorbereitet sein muss
• Unser Vorgehen bei WZ-IT
• Weiterführende Guides

Was am 11. September 2026 beginnt

Die Verordnung (EU) 2024/2847 wurde am 20. November 2024 im Amtsblatt veröffentlicht und ist am 10. Dezember 2024 in Kraft getreten. Ihre Pflichten greifen gestaffelt:

Diese Staffelung ist für die Einordnung wichtig. Ab September gibt es eine Meldepflicht ohne das übrige Pflichtenprogramm. Sichere Entwicklung, Schwachstellenmanagement über den Unterstützungszeitraum, technische Dokumentation und CE-Kennzeichnung folgen erst 15 Monate später.

Praktisch heißt das: Es gibt kein Zulassungsverfahren, das jemand im September bestehen müsste. Es gibt eine Pflicht, im Ernstfall schnell und an der richtigen Stelle zu melden.

Wer im Sinne des CRA Hersteller ist

Artikel 3 definiert den Hersteller als eine Organisation, die Produkte mit digitalen Elementen entwickelt oder herstellt oder entwickeln beziehungsweise herstellen lässt und sie unter ihrem Namen oder ihrer Marke vermarktet.

Der zweite Halbsatz ist der entscheidende. Eigene Fertigung ist nicht erforderlich, der eigene Name genügt. Damit fallen Konstellationen darunter, die sich intern nicht wie Produktion anfühlen:

• Eine Appliance aus zugekaufter Hardware, auf der eine selbst zusammengestellte Softwareauswahl vorinstalliert ist und die unter eigenem Produktnamen abgegeben wird
• Ein Gerät, das ein Partner unter eigener Marke weitervertreibt, während die Zusammenstellung von Ihnen stammt
• Ein Softwareprodukt, dessen Bestandteile überwiegend aus Open-Source-Projekten stammen und das als Ganzes unter eigenem Namen ausgeliefert wird

Auch die Vertriebsform ändert daran wenig. Bereitstellung auf dem Markt ist nach Artikel 3 die entgeltliche oder unentgeltliche Abgabe eines Produkts zum Vertrieb oder zur Verwendung im Rahmen einer Geschäftstätigkeit. Vermietung statt Verkauf führt aus dieser Definition nicht heraus.

Eine häufige Verwechslung betrifft die CE-Kennzeichnung. Ein Hardwarehersteller weist CE und RoHS für elektrische Sicherheit und Stoffbeschränkungen aus. Das sind andere Rechtsgrundlagen. Die Cybersicherheitskonformität nach CRA ist damit nicht abgedeckt.

Wer dagegen fremde Software lediglich betreibt, etwa im Rahmen von Managed Hosting, bringt nichts in Verkehr und ist kein Hersteller. Die Grenze verläuft dort, wo aus Betrieb eine eigene Abgabe unter eigenem Namen wird oder wo ein Produkt wesentlich verändert weitergegeben wird.

Wodurch eine Meldung ausgelöst wird

Artikel 14 Absatz 1 verlangt die Meldung jeder aktiv ausgenutzten Schwachstelle, die im Produkt enthalten ist, sobald der Hersteller davon Kenntnis erlangt. Absatz 3 verlangt dasselbe für jeden schwerwiegenden Sicherheitsvorfall mit Auswirkungen auf die Sicherheit des Produkts.

Zwei Bedingungen müssen zusammenkommen.

Erstens: Die Schwachstelle wird aktiv ausgenutzt. Artikel 3 Nummer 42 definiert das als eine Schwachstelle, zu der verlässliche Nachweise dafür vorliegen, dass ein böswilliger Akteur sie in einem System ohne Zustimmung des Systemeigners ausgenutzt hat. Der Wortlaut spricht von einem System, nicht von Ihrem. Als verlässliche Nachweise gelten etablierte externe Quellen wie der CISA-KEV-Katalog oder die europäische Schwachstellendatenbank, Threat Intelligence mit technischen Indikatoren oder eigene Forensik.

Nicht ausreichend sind ein hoher CVSS-Wert, ein veröffentlichter Proof of Concept oder ein einzelner Alarm aus dem eigenen Monitoring. Theoretische Angreifbarkeit löst die Pflicht nicht aus.

Zweitens: Die Schwachstelle ist in Ihrem Produkt enthalten. Das verlangt eine produktspezifische Bewertung. Wird die betroffene Komponente überhaupt ausgeliefert? In der betroffenen Version? Ist der verwundbare Codepfad im eigenen Build enthalten und aktiviert? Fällt eine dieser Fragen negativ aus, ist die Schwachstelle nicht enthalten und es gibt nichts zu melden. Diese Feststellung müssen Sie treffen und dokumentieren können.

Nicht Teil der Voraussetzungen ist die Einsatzumgebung. Ob ein einzelnes Gerät beim Kunden aus dem Internet erreichbar ist oder in einem abgeschotteten Netz steht, steht in Artikel 14 nicht. Das ist auch folgerichtig: Der Hersteller kennt die Einsatzumgebung seiner ausgelieferten Geräte in der Regel nicht. Eine abgeschottete Betriebsweise gehört deshalb als mindernde Maßnahme in die 72-Stunden-Meldung, nicht als Grund davor, gar nicht zu melden.

Die drei Meldungen und ihre Fristen

Gemeldet wird gleichzeitig an das als Koordinator benannte CSIRT des betreffenden Mitgliedstaats und an die ENISA, über die einheitliche Meldeplattform nach Artikel 16.

Die beiden Abschlussberichte laufen also unterschiedlich: Bei der Schwachstelle beginnt die Frist erst, wenn eine Maßnahme verfügbar ist. Beim Vorfall läuft sie ab der eingereichten Meldung.

Dazu kommt Artikel 14 Absatz 8: Betroffene Nutzer sind über die Schwachstelle oder den Vorfall zu informieren, einschließlich möglicher Gegen- und Abhilfemaßnahmen.

Die kritische Zahl ist die 24. Eine Frühwarnung innerhalb eines Tages setzt voraus, dass die Meldung nicht am Vorfalltag erst organisiert wird.

Was nicht unter den CRA fällt

Artikel 2 nimmt mehrere Produktgruppen aus, weil sie bereits sektorspezifisch geregelt sind: Medizinprodukte und In-vitro-Diagnostika, Kraftfahrzeuge, zertifizierte Luftfahrzeugausrüstung und Schiffsausrüstung. Ebenfalls ausgenommen sind Ersatzteile, die identische Teile nach den ursprünglichen Spezifikationen ersetzen, sowie Produkte, die ausschließlich für Zwecke der nationalen Sicherheit oder Verteidigung entwickelt wurden.

Für IT-Dienstleister sind zwei weitere Abgrenzungen wichtiger:

Reines SaaS ist nach Erwägungsgrund 9 nicht Ziel des CRA und fällt eher in den Anwendungsbereich der NIS-2-Richtlinie und des BSI-Gesetzes. Die Ausnahme davon sind Datenfernverarbeitungslösungen, die für ein Produkt mit digitalen Elementen unerlässlich sind und vom Hersteller oder unter seiner Verantwortung entwickelt wurden. Eine Cloud-Komponente, ohne die eine ausgelieferte Appliance nicht funktioniert, gehört zum Produkt.

Reiner Betrieb fremder Software begründet keine Herstellerrolle. Wer Systeme für Kunden verwaltet, ist Dienstleister. Betreiberpflichten ergeben sich dann eher aus NIS2 als aus dem CRA. Wir haben die Anforderungen dort im Beitrag zu NIS2 und Fernwartung ausgeführt.

Bei Individualsoftware für einen einzelnen Kunden ist die Rechtslage nicht abschließend geklärt. Ein Teil der Literatur ordnet lokal installierte Auftragssoftware in den Anwendungsbereich ein, ein anderer sieht Entwicklung für genau einen Kunden außerhalb. Wer regelmäßig Individualsoftware ausliefert, sollte das für die eigenen Vertragsmodelle rechtlich klären lassen, statt sich auf eine der beiden Lesarten zu verlassen.

Open Source: Betreiber, Verwalter, Hersteller

Der CRA unterscheidet drei Rollen, die in der Praxis oft vermischt werden.

Nicht-kommerzielle freie und quelloffene Software ist vom Anwendungsbereich ausgenommen. Ein Projekt ohne kommerzielle Verwertung wird nicht zum Hersteller.

Verwalter quelloffener Software ist nach Artikel 24 eine juristische Person, die kein Hersteller ist und die Entwicklung bestimmter, für kommerzielle Tätigkeiten bestimmter Open-Source-Produkte systematisch und nachhaltig unterstützt. Die Pflichten sind bewusst geringer: eine dokumentierte Cybersicherheitsstrategie, Zusammenarbeit mit den Marktüberwachungsbehörden und Mitwirkung bei der Meldung aktiv ausgenutzter Schwachstellen, soweit die Rolle an der Entwicklung reicht. Keine CE-Kennzeichnung, keine förmliche Konformitätsbewertung. Auch für Verwalter greift die Meldepflicht ab dem 11. September 2026.

Hersteller wird, wer ein Open-Source-Produkt unter eigenem Namen vermarktet oder es wesentlich verändert weitergibt. Die Rolle richtet sich nach der tatsächlichen Marktstellung, nicht nach der internen Bezeichnung. Für Unternehmen, die eine lokale KI-Appliance oder einen App Node mit vorinstalliertem Open-Source-Stack ausliefern, ist das die entscheidende Frage: Sie liefern fremden Code, aber ein eigenes Produkt.

Was bis zum 11. September vorbereitet sein muss

Der Aufwand liegt nicht im Melden, sondern in dem, was eine Meldung innerhalb von 24 Stunden überhaupt möglich macht.

1. Wissen, was ausgeliefert wird. Eine belastbare Komponentenliste je Produkt und Version, inklusive der Abhängigkeiten. Ohne sie lässt sich die Frage "betrifft uns das?" nicht beantworten, und ohne Antwort meldet man entweder zu viel oder zu spät. Eine Software-Stückliste ist ab Dezember 2027 ohnehin Teil der technischen Dokumentation.

2. Mitbekommen, wenn etwas ausgenutzt wird. Die Auslösequelle sind nicht alle CVEs, sondern die Teilmenge mit belegter Ausnutzung. Praktisch heißt das: Abgleich der eigenen Komponentenliste gegen KEV, die europäische Schwachstellendatenbank und Herstellermeldungen. Genau das leistet ein laufendes CVE-Monitoring, angewendet auf das eigene Produkt statt nur auf die eigenen Server.

3. Den Meldeweg vorher festlegen. Welches CSIRT ist zuständig, wer hat Zugang zur ENISA-Plattform, wer entscheidet über die Meldung, wer schreibt sie, wer informiert die Nutzer. Diese Fragen am Vorfalltag zu klären, kostet den größeren Teil der 24 Stunden.

4. Zulieferer und Reseller einbeziehen. Wenn ein Partner Ihr Produkt unter eigener Marke weitervertreibt, bleibt die Meldepflicht bei Ihnen als Hersteller. Sie brauchen dafür Informationen von Ihren Zulieferern über deren Komponenten und Absprachen mit Resellern über die Weitergabe von Vorfallinformationen.

Unser Vorgehen bei WZ-IT

Wir betreiben Systeme für Kunden und liefern zugleich Geräte mit vorinstalliertem Open-Source-Stack aus. Damit stellen sich beide Fragen auch bei uns, und wir behandeln sie getrennt.

Für den Betrieb fremder Software sind wir Dienstleister, nicht Hersteller. Die einschlägigen Anforderungen kommen dort aus NIS2 und aus den vertraglichen Zusagen, nicht aus dem CRA.

Für ausgelieferte Geräte prüfen wir die Herstellerrolle produktbezogen und arbeiten an der Grundlage, die eine 24-Stunden-Meldung erst möglich macht: eine gepflegte Komponentenliste je Auslieferungsstand und ein Abgleich gegen Quellen, die belegte Ausnutzung führen. Der Meldeweg selbst ist Organisation, nicht Technik, und gehört vor den ersten Ernstfall.

Wir geben keine Rechtsberatung. Wo die Zuordnung einer Rolle über Pflichten entscheidet, gehört sie anwaltlich geklärt. Was wir beitragen, ist die technische Seite: Transparenz über das, was tatsächlich ausgeliefert wird, und eine Beobachtung, die nicht bei jeder CVE Alarm schlägt, sondern bei der Teilmenge mit belegter Ausnutzung.

Weiterführende Guides

• NIS2 und Fernwartung: Anforderungen und BSI-Frist ordnet die Betreiberseite ein, die neben dem CRA gilt
• Metabase-Schwachstelle mit CVSS 10.0 zeigt an einem realen Fall, wie schnell aus einer Meldung eine ausgenutzte Schwachstelle wird
• CVE-Monitoring und Compliance im Betrieb beschreiben die laufenden Leistungen dahinter

Unklar, ob aus Ihrem Produkt eine Herstellerpflicht entsteht? Wir sichten mit Ihnen, was Sie tatsächlich ausliefern, welche Komponenten darin stecken und wie ein Meldeweg aussieht, der eine 24-Stunden-Frist einhält. Termin vereinbaren

Quellen

• Verordnung (EU) 2024/2847 (Cyber Resilience Act), Volltext
• Artikel 14: Meldepflichten der Hersteller
• Artikel 3: Begriffsbestimmungen
• Artikel 24: Pflichten der Verwalter quelloffener Software
• BSI: Cyber Resilience Act
• Europäische Kommission: Cyber Resilience Act
• ENISA: Single Reporting Platform, FAQ
• CISA: Known Exploited Vulnerabilities Catalog