BSI KI-Agenten: Neue Prüfanforderungen für mehr Sicherheit
PRAKI soll neue Prüfanforderungen entwickeln und die Sicherheit agentischer KI systematisch bewerten.
ENISA-Meldeplattform ist live. Hersteller müssen Sicherheitsvorfälle und ausgenutzte Lücken melden.

Die Meldepflichten des Cyber Resilience Act gelten seit dem 11. September 2026. Gleichzeitig hat ENISA die zentrale Plattform für Meldungen zu aktiv ausgenutzten Schwachstellen und schweren Sicherheitsvorfällen in Betrieb genommen.
Damit ist aus der bereits angekündigten CRA-Meldepflicht ab September 2026 ein operativer Prozess geworden. Hersteller betroffener Hard- und Software müssen ihre internen Abläufe nun auf feste Fristen, Zuständigkeiten und die neue Single Reporting Platform ausrichten.
Der Cyber Resilience Act gilt noch nicht in allen Teilen. Die zentralen Cybersicherheitsanforderungen für Produkte mit digitalen Elementen werden überwiegend erst ab dem 11. Dezember 2027 anwendbar.
Die Meldepflichten nach Artikel 14 gelten dagegen bereits seit dem 11. September 2026. Sie betreffen Hersteller von Produkten mit digitalen Elementen, die unter den Anwendungsbereich des CRA fallen.
Damit beginnt ein wesentlicher Teil der praktischen Umsetzung deutlich vor den übrigen Produktpflichten. Parallel laufen weitere Vorbereitungen, etwa bei den technischen Cyber Resilience Act Sicherheitsstandards.
Für Open-Source-Software-Stewards greifen die entsprechenden Meldepflichten nach Artikel 24 Absatz 3 erst am 11. Dezember 2027.
Der CRA unterscheidet zwei meldepflichtige Ereignistypen. Hersteller müssen aktiv ausgenutzte Schwachstellen sowie schwerwiegende Sicherheitsvorfälle melden, die sich auf die Sicherheit eines Produkts mit digitalen Elementen auswirken.
Eine bekannte Sicherheitslücke löst damit nicht automatisch eine verpflichtende Meldung aus. Für eine aktiv ausgenutzte Schwachstelle müssen nach der CRA-Definition belastbare Hinweise vorliegen, dass ein Angreifer sie ohne Erlaubnis tatsächlich ausgenutzt hat.
Bei Sicherheitsvorfällen kommt es darauf an, ob die Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit von Daten oder Funktionen erheblich betroffen ist.
Die Abgrenzung ist für Unternehmen entscheidend. Sicherheits- und Produktteams müssen nicht nur Schwachstellen erkennen, sondern auch schnell bewerten können, ob die gesetzlichen Meldekriterien erfüllt sind.
Nach Kenntnis eines meldepflichtigen Ereignisses läuft zunächst eine Frist von höchstens 24 Stunden. Innerhalb dieses Zeitraums muss eine Frühwarnung übermittelt werden.
Spätestens innerhalb von 72 Stunden folgt eine ausführlichere Meldung mit verfügbaren Informationen und einer ersten Bewertung.
Danach unterscheiden sich die Fristen. Bei aktiv ausgenutzten Schwachstellen ist ein Abschlussbericht spätestens 14 Tage nach Bereitstellung einer Korrektur- oder Minderungsmaßnahme erforderlich. Bei schweren Sicherheitsvorfällen gilt dafür eine Frist von einem Monat nach der 72-Stunden-Meldung.
Die Fristen erinnern teilweise an andere regulatorische Meldeverfahren. Sie sollten jedoch nicht mit den Anforderungen aus NIS2 für Industrie und KMU gleichgesetzt werden. Rechtsgrundlage, Anwendungsbereich und Meldekriterien unterscheiden sich.
ENISA betreibt für die Meldungen die Single Reporting Platform, kurz SRP. Hersteller reichen dort ihre Meldung ein und wählen das zuständige koordinierende nationale CSIRT aus.
Grundsätzlich richtet sich die Zuständigkeit nach dem Hauptsitz des Herstellers innerhalb der EU. Maßgeblich ist dabei der Ort, an dem überwiegend Entscheidungen zur Cybersicherheit der betroffenen Produkte getroffen werden.
Nach Eingang steht die Meldung zugleich ENISA zur Verfügung. Das koordinierende CSIRT kann die Informationen an weitere relevante CSIRTs und gegebenenfalls Marktüberwachungsbehörden weitergeben.
Für den Zugriff benötigen benannte Vertreter ein persönliches EU-Login-Konto mit aktivierter Mehrfaktor-Authentifizierung. Ein Hersteller kann aktuell einen primären Vertreter sowie bis zu 20 sekundäre Vertreter hinterlegen. Beide Rollen können Meldungen einreichen.
Zum Start stellt ENISA keine API für die Single Reporting Platform bereit. Unternehmen können ihre internen Abläufe zwar automatisieren, die eigentliche Meldung muss derzeit jedoch über die Benutzeroberfläche erfolgen. ENISA schließt eine API für eine spätere Ausbaustufe nicht aus.
Für Hersteller mit vielen Produkten oder einem hohen Schwachstellenaufkommen entsteht dadurch zunächst ein manueller Übergabepunkt. Incident-Response-, Vulnerability-Management- und Compliance-Prozesse lassen sich noch nicht vollständig technisch mit der SRP verbinden.
Hinzu kommt ein Detail der aktuellen Plattformversion. Der integrierte Zähler für die 72-Stunden-Meldung berechnet die Frist derzeit auf Basis der eingereichten Frühwarnung. Dadurch kann das System eine Meldung unter Umständen bereits als überfällig anzeigen, obwohl seit Bekanntwerden des Ereignisses noch keine 72 Stunden vergangen sind. ENISA kündigt eine Anpassung der Berechnungslogik für eine spätere Version an. Entscheidend bleiben die gesetzlichen Fristen.
Für Hersteller reicht es nicht aus, einen Zugang zur Plattform einzurichten. Die 24-Stunden-Frist setzt voraus, dass technische und organisatorische Prozesse bereits vor einem konkreten Sicherheitsfall definiert sind.
Unternehmen sollten insbesondere klären:
Gerade bei Drittanbieter-Komponenten ist zudem eine belastbare Übersicht über eingesetzte Bibliotheken, Firmware und weitere Softwarebestandteile relevant. Nur so lässt sich bei einer bekannt gewordenen Ausnutzung schnell feststellen, welche eigenen Produkte betroffen sein könnten.
Mit dem Start der Single Reporting Platform ist der Cyber Resilience Act für Hersteller erstmals unmittelbar im täglichen Sicherheitsbetrieb angekommen. Die vollständigen Produktanforderungen folgen erst Ende 2027, die Meldefristen gelten jedoch bereits heute.
Für Unternehmen liegt die zentrale Aufgabe deshalb weniger in der Plattform selbst. Entscheidend ist, dass Erkennung, Bewertung, Eskalation und Meldung innerhalb kurzer Fristen ineinandergreifen.
Weitere Entwicklungen rund um Regulierung, Security und IT-Infrastruktur ordnet der IT-Dock-Newsletter regelmäßig ein: https://it-dock.de/#newsletter.
Kommentare (0)
Noch keine Kommentare vorhanden.