CRA: Meldepflicht für Verwalter quelloffener Software – ab wann?

Berlin, 9. September 2026

Aktualisierung vom 9. September 2026, abends: Die ENISA hat ihre FAQ zur Single Reporting Platform heute geändert. Die Antworten 27, 29 und 30 – zwei davon neu – halten nunmehr fest, dass die Meldepflichten der Verwalter quelloffener Software nach Art. 24 Abs. 3 CRA erst ab dem 11. Dezember 2027 gelten, und dass die Plattform derzeit nur Pflichtmeldungen von Herstellern annimmt; alle anderen werden an das zuständige nationale CSIRT verwiesen, eine gleichwohl eingereichte Meldung kann als ungültig gekennzeichnet werden. Damit folgt auch die Agentur, die die Meldeplattform betreibt, der Lesart der Kommissions-FAQ Ziff. 5.5; dass die nationalen Marktüberwachungsbehörden dem folgen, ist zu erwarten. Die nachstehende Darstellung beider Lesarten bleibt unverändert; geändert hat sich die praktische Erwartung – und die Statusfrage unter Ziffer 1 wird dadurch wichtiger, nicht unwichtiger.

Zwei Tage vor Wirksamwerden der Meldepflichten des Cyber Resilience Act ist die Lage für Verwalter quelloffener Software unklar geworden. Die Europäische Kommission hat ihre FAQ zur Umsetzung des CRA am 4. September 2026 auf die Fassung 1.4 aktualisiert. Einzige Änderung dieser Fassung ist die neu eingefügte Ziffer 5.5, nach der die über Art. 24 Abs. 3 auf Verwalter erstreckten Meldepflichten erst ab dem 11. Dezember 2027 gelten. Das Informationsblatt der ENISA zur einheitlichen Meldeplattform nennt Hersteller und Verwalter quelloffener Software dagegen gemeinsam unter dem Stichtag 11. September 2026 und differenziert bei den Fristen nicht – die FAQ der ENISA zur Meldeplattform ist allerdings noch am selben Tag an die Lesart der Kommission angeglichen worden (siehe die Aktualisierung oben).

Für eine Organisation, die quelloffene Entwicklung unterstützt, folgen daraus zwei Fragen. Sie werden regelmäßig vermengt, und nur die zweite ist wirklich offen.

1. Sind Sie überhaupt Verwalter quelloffener Software?

Art. 3 Nr. 14 CRA verlangt drei Voraussetzungen kumulativ: eine juristische Person; keinen Hersteller im Sinne des Art. 3 Nr. 13; und die systematische und nachhaltige Unterstützung der Entwicklung freier und quelloffener Software, die für kommerzielle Tätigkeiten bestimmt ist, einschließlich der Sicherstellung ihrer Brauchbarkeit. In den von uns geführten Prüfungen scheitert es an der zweiten Voraussetzung – und zwar meist aus Gründen, die die Organisation selbst nicht mit dem CRA in Verbindung gebracht hatte.

  • Auslieferungsmodell und Vertriebswege. Wer gibt die kompilierte Fassung an den Endnutzer ab – die Organisation selbst über eigene Website, eigene Paketquellen oder eigene Installationsprogramme, oder ausschließlich Vendoren und Mitglieder? Das Bereitstellen eines Repositoriums ist kein Inverkehrbringen; die Abgabe eines Installationsprogramms unter eigenem Namen kann eines sein.
  • Lizenzbedingungen. Art. 3 Nr. 48 verlangt, dass der Quellcode offen geteilt und so lizenziert wird, dass er frei zugänglich, nutzbar, veränderbar und weiterverbreitbar ist. Ein Kündigungsrecht im Ermessen des Lizenzgebers, eine Pflicht zur Vernichtung von Kopien oder „angemessene und faire Bedingungen“ anstelle einer benannten Open-Source-Lizenz zerstören diese Einordnung jeweils.
  • Mitgliederbeschränkter Quellcodezugang. Quellcode für Mitglieder, Objektcode für alle ist der häufigste Befund überhaupt. Er betrifft die Qualifikation als freie und quelloffene Software und stellt sich damit vor jeder Frage der Herstellereigenschaft.
  • Eigener Name, eigene Marke. Eine für Software eingetragene Marke, die an der Komponente selbst geführt wird, begründet zusammen mit einer kommerziellen Tätigkeit die Herstellereigenschaft nach Art. 3 Nr. 13. Beide Merkmale sind kumulativ – der Markenauftritt allein genügt nicht, und die Verwaltung von Marken zählt ausdrücklich zu den verwaltertypischen Aufgaben.
  • Rechtekette aus Beitrags- und Vendorverträgen. Ob die Rechte unbefristet und ohne Lizenzgebühren eingeräumt sind, oder ob Gebühren oder ein Wahlrecht für implementierungsnotwendige Patente bestehen bleiben.

Zwei methodische Punkte sind hier wesentlich. Der Status ist projekt- oder repositoriumsbezogen festzustellen und nicht einmalig für die Entität, wie die Leitlinien der Kommission ausdrücklich vorgeben; ein Register der Projekte mit Lizenz, Publizität, kommerzieller Bestimmung und Unterstützungstiefe ist das brauchbare Instrument, und es ist fortzuschreiben. Und wo der Verwalterstatus nicht feststeht, ist die Organisation für die betreffende Komponente Hersteller: Art. 14 gilt dann unmittelbar ab dem 11. September 2026, ohne jede Verweisung und ohne jede Datumsfrage.

Was das in der Praxis heißt – sechs Befunde aus unseren Prüfungen

Die Beispiele sind anonymisiert und stammen aus verschiedenen Mandaten. In jedem Fall hatte die Organisation eine feste Vorstellung von ihrem Status; in fünf von sechs Fällen hat die Prüfung sie geändert.

  • Beispiel 1 – Abgabe unter eigenem Namen. Ein Konsortium stellte seine Referenzimplementierung auf der eigenen Website als signiertes Installationsprogramm mit der eigenen eingetragenen Wortmarke bereit. Das bloße Vorhalten eines Repositoriums wäre unbedenklich gewesen; die Abgabe unter eigenem Namen neben der kostenpflichtigen Mitgliedschaft machte die Organisation für diese Komponente zur Herstellerin.
  • Beispiel 2 – Quellcode nur für Mitglieder. Eine Foundation lizenzierte den Quellcode nur an Mitglieder, während die Binaries allen offenstanden. Die Prüfung endete bei Art. 3 Nr. 48: Ohne freien Zugang zum Quellcode fehlt es an freier und quelloffener Software – und damit an jeder Grundlage für den Verwalterstatus.
  • Beispiel 3 – gebührenpflichtiges Wahlrecht bei Patenten. Eine IPR-Policy eröffnete den Beitragenden die Wahl gebührenpflichtiger Bedingungen für implementierungsnotwendige Patente. Die Rechtekette war damit nicht gebührenfrei, die Weiterverbreitung nicht frei im geforderten Sinn – ein Lizenzproblem, das keine technische Sicherheitsmaßnahme heilt.
  • Beispiel 4 – Kündigungsrecht in der Lizenz. Eine Lizenz behielt dem Lizenzgeber ein freies Kündigungsrecht vor und verpflichtete die Nutzer zur Vernichtung ihrer Kopien, während sich das Projekt durchgehend als Open Source bezeichnete – unvereinbar mit der dauerhaften, unwiderruflichen Rechteeinräumung, die eine Open-Source-Lizenz verlangt. In einem anderen Fall enthielt das öffentliche Repositorium überhaupt keine Lizenzdatei.
  • Beispiel 5 – Konformitätszeichen und eigenes Werkzeug. Ein Konformitätsprogramm arbeitete mit einem privaten Zeichen und einem öffentlichen Register. Das Zeichen allein begründete keine Herstellereigenschaft – die Verwaltung von Marken zählt ausdrücklich zu den verwaltertypischen Aufgaben – wohl aber zusammen mit der Abgabe des Testwerkzeugs durch die Organisation selbst, und zwar für dieses Werkzeug.
  • Beispiel 6 – Status bestätigt. Quellcode öffentlich unter einer benannten Open-Source-Lizenz, Vertrieb ausschließlich über Vendoren, keine Abgabe unter eigenem Namen. Der Verwalterstatus stand fest, wurde projektbezogen dokumentiert – und diese Organisation hat vor Dezember 2027 nichts zu melden.

Das Muster ist beständig: Entschieden wird selten über die Sicherheitsorganisation, sondern über Lizenz- und Vertriebsgestaltung – Dokumente, die Jahre zuvor aus ganz anderen Gründen entworfen wurden. Und wo der Status feststeht, richtet sich der Pflichtenumfang weiterhin nach der Unterstützungstiefe: rein nicht-technische Unterstützung löst keine Meldepflicht aus, das Bereitstellen der Entwicklungsinfrastruktur eine Meldepflicht für diese Infrastruktur, eigene Entwicklerressourcen die volle Erstreckung des Art. 24 Abs. 3.

2. Wenn Sie Verwalter sind – ab wann müssen Sie melden?

Das ist die Frage, die die neue FAQ-Eintragung offen gemacht hat. Beide Lesarten sind vertretbar.

Nach der Lesart der Ziffer 5.5 liegt der Pflichtengrund in Art. 24 Abs. 3. Art. 71 Abs. 2 zieht nur Kapitel IV und Art. 14 vor, Art. 24 ist dort nicht genannt; Art. 14 Abs. 1 richtet sich an den „Hersteller“, während Art. 3 Nr. 14 den Verwalter als juristische Person definiert, „die kein Hersteller ist“. Die Pflicht könne deshalb nicht in Art. 14 selbst verortet werden und folge dem Geltungsbeginn des Art. 24, also dem 11. Dezember 2027.

Nach der Lesart, die wir bisher zugrunde gelegt haben, zieht Art. 71 Abs. 2 „Artikel 14“ als Vorschrift vor und nicht einen bestimmten Adressatenkreis. Art. 24 Abs. 3 begründet keine eigene Pflicht, sondern erstreckt die „in Artikel 14 Absatz 1 festgelegten Verpflichtungen“; damit ist die Pflicht in Art. 14 verortet und Art. 24 Abs. 3 lediglich eine Erweiterung des persönlichen Anwendungsbereichs, die mit der vorgezogenen Norm mitläuft. Dafür sprechen drei Punkte. Art. 69 Abs. 3 fasst den zeitlichen Anwendungsbereich des Art. 14 gesondert und weit. Die Art. 14 bis 16 bilden eine einheitliche Meldearchitektur, die zum 11. September 2026 als Einheit in Betrieb geht – und die Komponenten, an denen eine aktiv ausgenutzte Schwachstelle am ehesten zutage tritt, sind gerade die quelloffenen. Und Art. 64 Abs. 10 lit. b stellt Verwalter nur von den Geldbußen der Absätze 3 bis 9 frei, so dass Art. 64 Abs. 2, der Art. 14 erfasst, auf sie anwendbar bleibt.

Drei Dinge sind zum Status dieser Eintragung zu wissen. Sie ist neu, veröffentlicht am 4. September 2026. Sie ist ausdrücklich unverbindlich: Die FAQ ist von den Dienststellen der Kommission erstellt, gibt nicht die offizielle Position der Kommission wieder, erweitert und beschränkt weder Rechte noch Pflichten und greift einer Auslegung durch den Gerichtshof nicht vor. Und der Vollzug ist national: Marktüberwachungsbehörde nach dem deutschen CRA-Durchführungsgesetz ist das BSI, das bei Rechtsfragen und Verwaltungsvorgaben auf das Bundesministerium des Innern verweist – und das Ministerium hat auf unsere Anfrage genau auf jenes ENISA-Material verwiesen, das bei den Fristen nicht zwischen Herstellern und Verwaltern unterschied – Material, das inzwischen geändert worden ist, so dass sich die nationale Einschätzung voraussichtlich mitbewegt.

Wir haben die Frage sowohl dem Ministerium als auch der ENISA vorgelegt und berichten hier über die Antworten.

Was das praktisch bedeutet

  • Zuerst die Statusfrage klären. Von ihr hängt ab, ob das Datum überhaupt streitig ist. Steht der Verwalterstatus für ein Projekt nicht fest, greift die Meldepflicht über die Herstellereigenschaft in jedem Fall ab dem 11. September 2026.
  • Meldebereitschaft zum 11. September 2026 herstellen. Benannte Sicherheitsansprechstelle mit Vertretung, funktionierende Meldeadresse, dokumentierter Entscheidungsweg innerhalb von 24 Stunden, Registrierung auf der Meldeplattform. Die Kosten der Vorhaltung sind gering; das Risiko nach Art. 64 Abs. 2 reicht bis zu 15 Mio. EUR oder 2,5 % des weltweiten Jahresumsatzes.
  • Die FAQ-Fassung zur Akte nehmen. Ziffer 5.5 in der Fassung 1.4 vom 4. September 2026 ist Material für die Verteidigung im Einzelfall – keine Grundlage, auf die ein Compliance-Termin gestellt werden kann.
  • Die Entwicklung beobachten. Die FAQ ist ein fortlaufend gepflegtes Dokument. Die ENISA hat ihre FAQ zur Meldeplattform am 9. September 2026 angeglichen; ob das Informationsblatt folgt, bleibt abzuwarten.

Vorschriften

  • Art. 3 Nr. 13, 14, 48 CRA – Hersteller, Verwalter quelloffener Software, freie und quelloffene Software
  • Art. 14 CRA – Meldepflichten, Fristen von 24 Stunden, 72 Stunden, 14 Tagen und einem Monat
  • Art. 24 CRA – Pflichten der Verwalter quelloffener Software, Erstreckung der Meldepflichten in Absatz 3
  • Art. 64 CRA – Geldbußen, Absatz 2 und die begrenzte Freistellung in Absatz 10 lit. b
  • Art. 71 Abs. 2 CRA – Geltung ab 11. Dezember 2027, Art. 14 ab 11. September 2026, Kapitel IV ab 11. Juni 2026

Mehr zum CRA

Über SES Berlin

SES Berlin ist eine Kanzlei aus Rechtsanwälten und Notaren in Berlin. Unsere IT- und Technologiepraxis berät Hersteller, Importeure, Konsortien, Standardisierungsgremien und Open-Source-Organisationen zum Cyber Resilience Act – von der Einordnung als Hersteller oder Verwalter über Lizenz- und Beitragsstrukturen bis zu Offenlegungsstrategie, Meldeprozess und Governance. Roman Ronneburger, Rechtsanwalt und Fachanwalt für Urheber- und Medienrecht, führt die CRA-Beratung der Kanzlei und begleitet internationale Konsortien bei ihren europäischen Produktsicherheitspflichten. Wir arbeiten projektbezogen, dokumentieren jede Statusfeststellung nachvollziehbar und liefern die Dokumente mit, die daraus folgen.

Wir prüfen den Verwalterstatus projektbezogen und stellen die Meldebereitschaft her – Lizenzierung, Offenlegungsstrategie, Meldeprozess und Governance. Ihr Ansprechpartner: Roman Ronneburger, oder über unsere Kontaktseite.

CRA: Meldepflicht für Verwalter quelloffener Software – ab wann?

Berlin, 9. September 2026

Aktualisierung vom 9. September 2026, abends: Die ENISA hat ihre FAQ zur Single Reporting Platform heute geändert. Die Antworten 27, 29 und 30 – zwei davon neu – halten nunmehr fest, dass die Meldepflichten der Verwalter quelloffener Software nach Art. 24 Abs. 3 CRA erst ab dem 11. Dezember 2027 gelten, und dass die Plattform derzeit nur Pflichtmeldungen von Herstellern annimmt; alle anderen werden an das zuständige nationale CSIRT verwiesen, eine gleichwohl eingereichte Meldung kann als ungültig gekennzeichnet werden. Damit folgt auch die Agentur, die die Meldeplattform betreibt, der Lesart der Kommissions-FAQ Ziff. 5.5; dass die nationalen Marktüberwachungsbehörden dem folgen, ist zu erwarten. Die nachstehende Darstellung beider Lesarten bleibt unverändert; geändert hat sich die praktische Erwartung – und die Statusfrage unter Ziffer 1 wird dadurch wichtiger, nicht unwichtiger.

Zwei Tage vor Wirksamwerden der Meldepflichten des Cyber Resilience Act ist die Lage für Verwalter quelloffener Software unklar geworden. Die Europäische Kommission hat ihre FAQ zur Umsetzung des CRA am 4. September 2026 auf die Fassung 1.4 aktualisiert. Einzige Änderung dieser Fassung ist die neu eingefügte Ziffer 5.5, nach der die über Art. 24 Abs. 3 auf Verwalter erstreckten Meldepflichten erst ab dem 11. Dezember 2027 gelten. Das Informationsblatt der ENISA zur einheitlichen Meldeplattform nennt Hersteller und Verwalter quelloffener Software dagegen gemeinsam unter dem Stichtag 11. September 2026 und differenziert bei den Fristen nicht – die FAQ der ENISA zur Meldeplattform ist allerdings noch am selben Tag an die Lesart der Kommission angeglichen worden (siehe die Aktualisierung oben).

Für eine Organisation, die quelloffene Entwicklung unterstützt, folgen daraus zwei Fragen. Sie werden regelmäßig vermengt, und nur die zweite ist wirklich offen.

1. Sind Sie überhaupt Verwalter quelloffener Software?

Art. 3 Nr. 14 CRA verlangt drei Voraussetzungen kumulativ: eine juristische Person; keinen Hersteller im Sinne des Art. 3 Nr. 13; und die systematische und nachhaltige Unterstützung der Entwicklung freier und quelloffener Software, die für kommerzielle Tätigkeiten bestimmt ist, einschließlich der Sicherstellung ihrer Brauchbarkeit. In den von uns geführten Prüfungen scheitert es an der zweiten Voraussetzung – und zwar meist aus Gründen, die die Organisation selbst nicht mit dem CRA in Verbindung gebracht hatte.

  • Auslieferungsmodell und Vertriebswege. Wer gibt die kompilierte Fassung an den Endnutzer ab – die Organisation selbst über eigene Website, eigene Paketquellen oder eigene Installationsprogramme, oder ausschließlich Vendoren und Mitglieder? Das Bereitstellen eines Repositoriums ist kein Inverkehrbringen; die Abgabe eines Installationsprogramms unter eigenem Namen kann eines sein.
  • Lizenzbedingungen. Art. 3 Nr. 48 verlangt, dass der Quellcode offen geteilt und so lizenziert wird, dass er frei zugänglich, nutzbar, veränderbar und weiterverbreitbar ist. Ein Kündigungsrecht im Ermessen des Lizenzgebers, eine Pflicht zur Vernichtung von Kopien oder „angemessene und faire Bedingungen“ anstelle einer benannten Open-Source-Lizenz zerstören diese Einordnung jeweils.
  • Mitgliederbeschränkter Quellcodezugang. Quellcode für Mitglieder, Objektcode für alle ist der häufigste Befund überhaupt. Er betrifft die Qualifikation als freie und quelloffene Software und stellt sich damit vor jeder Frage der Herstellereigenschaft.
  • Eigener Name, eigene Marke. Eine für Software eingetragene Marke, die an der Komponente selbst geführt wird, begründet zusammen mit einer kommerziellen Tätigkeit die Herstellereigenschaft nach Art. 3 Nr. 13. Beide Merkmale sind kumulativ – der Markenauftritt allein genügt nicht, und die Verwaltung von Marken zählt ausdrücklich zu den verwaltertypischen Aufgaben.
  • Rechtekette aus Beitrags- und Vendorverträgen. Ob die Rechte unbefristet und ohne Lizenzgebühren eingeräumt sind, oder ob Gebühren oder ein Wahlrecht für implementierungsnotwendige Patente bestehen bleiben.

Zwei methodische Punkte sind hier wesentlich. Der Status ist projekt- oder repositoriumsbezogen festzustellen und nicht einmalig für die Entität, wie die Leitlinien der Kommission ausdrücklich vorgeben; ein Register der Projekte mit Lizenz, Publizität, kommerzieller Bestimmung und Unterstützungstiefe ist das brauchbare Instrument, und es ist fortzuschreiben. Und wo der Verwalterstatus nicht feststeht, ist die Organisation für die betreffende Komponente Hersteller: Art. 14 gilt dann unmittelbar ab dem 11. September 2026, ohne jede Verweisung und ohne jede Datumsfrage.

Was das in der Praxis heißt – sechs Befunde aus unseren Prüfungen

Die Beispiele sind anonymisiert und stammen aus verschiedenen Mandaten. In jedem Fall hatte die Organisation eine feste Vorstellung von ihrem Status; in fünf von sechs Fällen hat die Prüfung sie geändert.

  • Beispiel 1 – Abgabe unter eigenem Namen. Ein Konsortium stellte seine Referenzimplementierung auf der eigenen Website als signiertes Installationsprogramm mit der eigenen eingetragenen Wortmarke bereit. Das bloße Vorhalten eines Repositoriums wäre unbedenklich gewesen; die Abgabe unter eigenem Namen neben der kostenpflichtigen Mitgliedschaft machte die Organisation für diese Komponente zur Herstellerin.
  • Beispiel 2 – Quellcode nur für Mitglieder. Eine Foundation lizenzierte den Quellcode nur an Mitglieder, während die Binaries allen offenstanden. Die Prüfung endete bei Art. 3 Nr. 48: Ohne freien Zugang zum Quellcode fehlt es an freier und quelloffener Software – und damit an jeder Grundlage für den Verwalterstatus.
  • Beispiel 3 – gebührenpflichtiges Wahlrecht bei Patenten. Eine IPR-Policy eröffnete den Beitragenden die Wahl gebührenpflichtiger Bedingungen für implementierungsnotwendige Patente. Die Rechtekette war damit nicht gebührenfrei, die Weiterverbreitung nicht frei im geforderten Sinn – ein Lizenzproblem, das keine technische Sicherheitsmaßnahme heilt.
  • Beispiel 4 – Kündigungsrecht in der Lizenz. Eine Lizenz behielt dem Lizenzgeber ein freies Kündigungsrecht vor und verpflichtete die Nutzer zur Vernichtung ihrer Kopien, während sich das Projekt durchgehend als Open Source bezeichnete – unvereinbar mit der dauerhaften, unwiderruflichen Rechteeinräumung, die eine Open-Source-Lizenz verlangt. In einem anderen Fall enthielt das öffentliche Repositorium überhaupt keine Lizenzdatei.
  • Beispiel 5 – Konformitätszeichen und eigenes Werkzeug. Ein Konformitätsprogramm arbeitete mit einem privaten Zeichen und einem öffentlichen Register. Das Zeichen allein begründete keine Herstellereigenschaft – die Verwaltung von Marken zählt ausdrücklich zu den verwaltertypischen Aufgaben – wohl aber zusammen mit der Abgabe des Testwerkzeugs durch die Organisation selbst, und zwar für dieses Werkzeug.
  • Beispiel 6 – Status bestätigt. Quellcode öffentlich unter einer benannten Open-Source-Lizenz, Vertrieb ausschließlich über Vendoren, keine Abgabe unter eigenem Namen. Der Verwalterstatus stand fest, wurde projektbezogen dokumentiert – und diese Organisation hat vor Dezember 2027 nichts zu melden.

Das Muster ist beständig: Entschieden wird selten über die Sicherheitsorganisation, sondern über Lizenz- und Vertriebsgestaltung – Dokumente, die Jahre zuvor aus ganz anderen Gründen entworfen wurden. Und wo der Status feststeht, richtet sich der Pflichtenumfang weiterhin nach der Unterstützungstiefe: rein nicht-technische Unterstützung löst keine Meldepflicht aus, das Bereitstellen der Entwicklungsinfrastruktur eine Meldepflicht für diese Infrastruktur, eigene Entwicklerressourcen die volle Erstreckung des Art. 24 Abs. 3.

2. Wenn Sie Verwalter sind – ab wann müssen Sie melden?

Das ist die Frage, die die neue FAQ-Eintragung offen gemacht hat. Beide Lesarten sind vertretbar.

Nach der Lesart der Ziffer 5.5 liegt der Pflichtengrund in Art. 24 Abs. 3. Art. 71 Abs. 2 zieht nur Kapitel IV und Art. 14 vor, Art. 24 ist dort nicht genannt; Art. 14 Abs. 1 richtet sich an den „Hersteller“, während Art. 3 Nr. 14 den Verwalter als juristische Person definiert, „die kein Hersteller ist“. Die Pflicht könne deshalb nicht in Art. 14 selbst verortet werden und folge dem Geltungsbeginn des Art. 24, also dem 11. Dezember 2027.

Nach der Lesart, die wir bisher zugrunde gelegt haben, zieht Art. 71 Abs. 2 „Artikel 14“ als Vorschrift vor und nicht einen bestimmten Adressatenkreis. Art. 24 Abs. 3 begründet keine eigene Pflicht, sondern erstreckt die „in Artikel 14 Absatz 1 festgelegten Verpflichtungen“; damit ist die Pflicht in Art. 14 verortet und Art. 24 Abs. 3 lediglich eine Erweiterung des persönlichen Anwendungsbereichs, die mit der vorgezogenen Norm mitläuft. Dafür sprechen drei Punkte. Art. 69 Abs. 3 fasst den zeitlichen Anwendungsbereich des Art. 14 gesondert und weit. Die Art. 14 bis 16 bilden eine einheitliche Meldearchitektur, die zum 11. September 2026 als Einheit in Betrieb geht – und die Komponenten, an denen eine aktiv ausgenutzte Schwachstelle am ehesten zutage tritt, sind gerade die quelloffenen. Und Art. 64 Abs. 10 lit. b stellt Verwalter nur von den Geldbußen der Absätze 3 bis 9 frei, so dass Art. 64 Abs. 2, der Art. 14 erfasst, auf sie anwendbar bleibt.

Drei Dinge sind zum Status dieser Eintragung zu wissen. Sie ist neu, veröffentlicht am 4. September 2026. Sie ist ausdrücklich unverbindlich: Die FAQ ist von den Dienststellen der Kommission erstellt, gibt nicht die offizielle Position der Kommission wieder, erweitert und beschränkt weder Rechte noch Pflichten und greift einer Auslegung durch den Gerichtshof nicht vor. Und der Vollzug ist national: Marktüberwachungsbehörde nach dem deutschen CRA-Durchführungsgesetz ist das BSI, das bei Rechtsfragen und Verwaltungsvorgaben auf das Bundesministerium des Innern verweist – und das Ministerium hat auf unsere Anfrage genau auf jenes ENISA-Material verwiesen, das bei den Fristen nicht zwischen Herstellern und Verwaltern unterschied – Material, das inzwischen geändert worden ist, so dass sich die nationale Einschätzung voraussichtlich mitbewegt.

Wir haben die Frage sowohl dem Ministerium als auch der ENISA vorgelegt und berichten hier über die Antworten.

Was das praktisch bedeutet

  • Zuerst die Statusfrage klären. Von ihr hängt ab, ob das Datum überhaupt streitig ist. Steht der Verwalterstatus für ein Projekt nicht fest, greift die Meldepflicht über die Herstellereigenschaft in jedem Fall ab dem 11. September 2026.
  • Meldebereitschaft zum 11. September 2026 herstellen. Benannte Sicherheitsansprechstelle mit Vertretung, funktionierende Meldeadresse, dokumentierter Entscheidungsweg innerhalb von 24 Stunden, Registrierung auf der Meldeplattform. Die Kosten der Vorhaltung sind gering; das Risiko nach Art. 64 Abs. 2 reicht bis zu 15 Mio. EUR oder 2,5 % des weltweiten Jahresumsatzes.
  • Die FAQ-Fassung zur Akte nehmen. Ziffer 5.5 in der Fassung 1.4 vom 4. September 2026 ist Material für die Verteidigung im Einzelfall – keine Grundlage, auf die ein Compliance-Termin gestellt werden kann.
  • Die Entwicklung beobachten. Die FAQ ist ein fortlaufend gepflegtes Dokument. Die ENISA hat ihre FAQ zur Meldeplattform am 9. September 2026 angeglichen; ob das Informationsblatt folgt, bleibt abzuwarten.

Vorschriften

  • Art. 3 Nr. 13, 14, 48 CRA – Hersteller, Verwalter quelloffener Software, freie und quelloffene Software
  • Art. 14 CRA – Meldepflichten, Fristen von 24 Stunden, 72 Stunden, 14 Tagen und einem Monat
  • Art. 24 CRA – Pflichten der Verwalter quelloffener Software, Erstreckung der Meldepflichten in Absatz 3
  • Art. 64 CRA – Geldbußen, Absatz 2 und die begrenzte Freistellung in Absatz 10 lit. b
  • Art. 71 Abs. 2 CRA – Geltung ab 11. Dezember 2027, Art. 14 ab 11. September 2026, Kapitel IV ab 11. Juni 2026

Mehr zum CRA

Über SES Berlin

SES Berlin ist eine Kanzlei aus Rechtsanwälten und Notaren in Berlin. Unsere IT- und Technologiepraxis berät Hersteller, Importeure, Konsortien, Standardisierungsgremien und Open-Source-Organisationen zum Cyber Resilience Act – von der Einordnung als Hersteller oder Verwalter über Lizenz- und Beitragsstrukturen bis zu Offenlegungsstrategie, Meldeprozess und Governance. Roman Ronneburger, Rechtsanwalt und Fachanwalt für Urheber- und Medienrecht, führt die CRA-Beratung der Kanzlei und begleitet internationale Konsortien bei ihren europäischen Produktsicherheitspflichten. Wir arbeiten projektbezogen, dokumentieren jede Statusfeststellung nachvollziehbar und liefern die Dokumente mit, die daraus folgen.

Wir prüfen den Verwalterstatus projektbezogen und stellen die Meldebereitschaft her – Lizenzierung, Offenlegungsstrategie, Meldeprozess und Governance. Ihr Ansprechpartner: Roman Ronneburger, oder über unsere Kontaktseite.