Europäische Plattform zur Meldung von Schwachstellen in digitalen Produkten ist jetzt in Betrieb

Die Agentur der Europäischen Union für Cybersicherheit (ENISA) gab am 11. September 2026 bekannt, dass sie die anfängliche Betriebsfähigkeit der Single Reporting Platform (SRP) bereitgestellt hat. Nach Angaben der Agentur wird das Instrument Herstellern und Verwaltern von Open-Source-Software ermöglichen, Meldepflichten nach dem Cyberresilienzgesetz (CRA) zu erfüllen. Dies ist ein konkreter Umsetzungsschritt, keine Änderung des Gesetzes und auch keine Erklärung, dass alle seine Vorschriften an diesem Tag in Kraft getreten seien.

Die Abgrenzung ist wichtig, denn der Name der Plattform könnte den Eindruck erwecken, es handle sich um ein allgemeines System, über das jeder Nutzer jeden Fehler melden kann. Die Mitteilung von ENISA ordnet sie den Meldepflichten des CRA zu und bezieht sich auf Hersteller und Verwalter von Open-Source-Software. Die Ankündigung bestätigt die Bereitstellung einer anfänglichen Funktionalität; aus den verfügbaren Informationen geht jedoch weder hervor, dass die Plattform sämtliche Prozesse des Schwachstellenmanagements abdeckt, noch dass alle Akteure sie bereits nutzen müssen oder ein öffentliches Melderegister veröffentlicht wurde.

Die Nachricht liefert ein überprüfbares Datum für einen betrieblichen Meilenstein. Für sich genommen lässt sich daraus jedoch nicht ableiten, dass digitale Produkte, die in der EU vermarktet werden, bereits anhand sämtlicher Anforderungen der Verordnung bewertet wurden. In der Praxis empfiehlt es sich, drei Fragen auseinanderzuhalten: die Existenz des Gesetzes, den Zeitplan seiner Pflichten und die Verfügbarkeit von Werkzeugen zur Unterstützung seiner Umsetzung. Diese Ereignisse sind nicht austauschbar.

Das CRA legt Cybersicherheitsanforderungen für Produkte mit digitalen Elementen fest, einschließlich Hardware und Software. Die Europäische Kommission beschreibt das Gesetz als einen Rahmen für Entwicklung, Gestaltung und Wartung solcher Produkte, der Herstellern Pflichten zum Umgang mit Schwachstellen über den gesamten Lebenszyklus auferlegt. Zu den allgemeinen Beispielen für erfasste Produkte zählen vernetzte Geräte und Software; der genaue Anwendungsbereich hängt von den Begriffsbestimmungen, Ausnahmen und Bedingungen des Rechtstextes ab.

Die Verordnung beschränkt Sicherheit nicht auf eine Prüfung beim Verkauf, sondern befasst sich auch damit, wie später erkannte Probleme behandelt werden. Das erklärt, weshalb Meldungen und Schwachstellenmanagement Teil der Umsetzung sind. Die Pflicht ist keine Zusage, dass ein Produkt niemals Fehler haben wird: Vielmehr geht es darum, im jeweils geltenden Rechtsrahmen Anforderungen und Abläufe festzulegen, auch für die Reaktion auf Schwachstellen.

Die Kommission weist außerdem darauf hin, dass für einige Produkte, die als besonders wichtig für die Cybersicherheit gelten, besondere Bewertungsverfahren vorgesehen sein können. Es wäre daher falsch anzunehmen, dass jedes Gerät genau denselben Bewertungs- oder Zertifizierungsweg durchlaufen muss. Für eine Entscheidung über die Konformität ersetzt die allgemeine politische Beschreibung nicht die Lektüre der einschlägigen Produktkategorien und Anforderungen der Verordnung.

Das Cyberresilienzgesetz wurde 2024 verabschiedet und sieht eine schrittweise Anwendung vor. Laut der Umsetzungsseite der Kommission ist die allgemeine Anwendung ab dem 11. Dezember 2027 vorgesehen; bestimmte Meldepflichten beginnen früher, am 11. September 2026. Dieses zweite Datum fällt mit der Ankündigung der anfänglichen Betriebsfähigkeit der SRP durch ENISA zusammen. Dass der Beginn einer konkreten Pflicht zeitlich mit dem Start eines Werkzeugs zusammenfällt, zieht nicht die vorzeitige Anwendung der gesamten Verordnung nach sich.

Diese Unterscheidung ist für Hersteller, Entwickler und Käufer hilfreich. Manche Anforderungen können Vorbereitungen vor ihrem vollständigen Anwendungsdatum erfordern; zugleich darf die Gesamtheit der Pflichten nicht so dargestellt werden, als sei sie bereits vollständig in Kraft. Das Datum 2027 entspricht dem von der Kommission beschriebenen allgemeinen Zeitplan und ist keine Garantie dafür, dass für jede Produktkategorie in jeder Hinsicht dieselben Bedingungen oder Fristen gelten.

Die Mitteilung von ENISA dokumentiert einen Inbetriebnahmeschritt, liefert aber für sich genommen weder ein vollständiges Verzeichnis der Funktionen noch Anweisungen für jede Gruppe von Meldenden oder Angaben zur Zahl eingegangener Meldungen. Für solche Einzelheiten sollten Hersteller und Verwalter die Hinweise und häufig gestellten Fragen zur SRP sowie den Rechtstext konsultieren. Eine spätere betriebliche Aktualisierung wäre von den bereits festgelegten rechtlichen Meilensteinen zu unterscheiden.

Auf Grundlage der verfügbaren offiziellen Quellen sind dokumentarische Prüfungen angemessen. Ein Hersteller kann untersuchen, ob seine Produkte in den Anwendungsbereich des CRA fallen, ermitteln, welche Pflichten für ihn gelten, und die maßgeblichen Termine abgleichen. Außerdem kann er überprüfen, ob ein Verfahren zum Umgang mit Schwachstellen vorhanden ist und ob die aktuellen Anweisungen von ENISA zur Einreichung und Aktualisierung von Meldungen bekannt sind. Die SRP ist ein diesem Verfahren zugeordnetes Instrument und kein Ersatz für die Verantwortung des verpflichteten Akteurs.

Verwalter von Open-Source-Projekten sollten geschäftliche Pflichten nicht automatisch auf alle Personen übertragen, die Code veröffentlichen. ENISA erwähnt in der Mitteilung zur Plattform open-source software stewards; die rechtliche Rolle einer bestimmten Einrichtung lässt sich jedoch nur unter Berücksichtigung der Begriffsbestimmungen und Bedingungen der Verordnung bestimmen. Der Begriff „Open Source“ allein beantwortet nicht, wer welcher Pflicht unterliegt.

Für Käufer und Nutzer führt die Ankündigung weder ein neues Sicherheitskennzeichen ein noch bescheinigt sie die Konformität eines bestimmten Produkts. Eine praktische Prüfung kann sich auf bereits vom Anbieter bereitgestellte Informationen konzentrieren: Aktualisierungsrichtlinie, angegebener Supportzeitraum, Meldekanal für Schwachstellen und Sicherheitsdokumentation. Diese Anhaltspunkte können beim Vergleich von Transparenz und Wartung helfen, stellen jedoch keine Bescheinigung der CRA-Konformität dar.

Die Belege erlauben die Aussage, dass ENISA zu einem bestimmten Datum die Bereitstellung der anfänglichen Betriebsfähigkeit der Plattform angekündigt und sie mit Meldepflichten des CRA verknüpft hat. Sie erlauben außerdem eine allgemeine Beschreibung von Zweck und Zeitplan des Gesetzes nach Angaben der Europäischen Kommission. Sie reichen jedoch nicht aus, um zu behaupten, die Plattform sei bereits in sämtlichen Funktionen vollständig betriebsbereit, alle Unternehmen hätten ihre Registrierung abgeschlossen oder eingereichte Meldungen seien öffentlich.

Aus diesen Seiten lässt sich ebenso wenig ableiten, dass der Kauf eines erfassten Produkts rechtzeitige Aktualisierungen garantiert oder dass eine gesetzliche Pflicht Schwachstellen beseitigt. Die Verordnung legt Anforderungen und Verantwortlichkeiten fest; für die Bewertung eines bestimmten Produkts braucht es Nachweise zu diesem Produkt und zu dem Akteur, der es vermarktet. Anfängliche Betriebsfähigkeit bezeichnet den angekündigten Meilenstein und keine unabhängige Prüfung der Verfügbarkeit oder Leistung.

Die redaktionelle Schlussfolgerung ist begrenzter, aber dennoch nützlich: Ein Umsetzungsschritt ist bestätigt, und er fällt in den Zeitplan der Meldepflichten. Die Ankündigung zieht die allgemeine Anwendung des CRA nicht vor und ermöglicht keine Zertifizierung einzelner Produkte. Leser und Käufer sollten die Nachricht als Beginn eines regulatorischen Instruments verstehen und weiterhin die offiziellen Angaben zu Fristen, Anwendungsbereich und Verfahren heranziehen, ohne Vorbereitung mit nachgewiesener Konformität zu verwechseln.