Zusammenfassung

  • Seit dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle zu einem Produkt melden. Die erste Warnung ist binnen 24 Stunden fällig, die vollständige Meldung binnen 72 Stunden.
  • Mandalari wollte bei RIPE 93 echte Beispiele zu Netzwerkgeräten, Softwarevertrieb und Supportzyklen in die CRA-Normung einbringen.

Der Cyber Resilience Act setzt Hersteller unter eine 24-Stunden-Uhr. Er macht nicht automatisch jedes Unternehmen, das ein Netz betreibt, zum Meldepflichtigen. Genau diese Grenze stellte Anna Maria Mandalari bei RIPE 93 in den Mittelpunkt: Vor einem Vorfall muss eine Organisation wissen, welche Produkte sie auf dem EU-Markt bereitstellt, welche Rolle sie in der Lieferkette hat und wer die Meldung absenden kann.

Das offizielle Transkript der RIPE-93-IoT-Sitzung führt Mandalari als zugeschaltete Rednerin des letzten Vortrags. Sie verband den CRA mit vertrauter Netzinfrastruktur – Routern, Modems und Switches – sowie mit der Software, auf die der Betrieb angewiesen ist. Ihre Bitte an die RIPE-Community war konkret: Sie solle Beispiele aus dem Betrieb in die Normungsarbeit tragen. Wie lange bleiben Geräte im Einsatz? Wer liefert Sicherheitsupdates? An welcher Stelle wechseln Verantwortung und Kontrolle zwischen Hersteller, Händler und Kunde?

Der Zeitplan macht die Frage akut. Die wichtigsten CRA-Vorschriften gelten ab dem 11. Dezember 2027; die Meldepflicht aus Artikel 14 gilt bereits seit dem 11. September 2026. Erfährt ein Hersteller von einer aktiv ausgenutzten Schwachstelle oder einem schweren Vorfall, der die Produktsicherheit beeinträchtigt, muss er binnen 24 Stunden eine Frühwarnung und binnen 72 Stunden eine ausführlichere Meldung einreichen. Der Abschlussbericht zu einer aktiv ausgenutzten Schwachstelle ist spätestens 14 Tage nach Verfügbarkeit einer Korrekturmaßnahme fällig. Bei einem schweren Vorfall muss er binnen eines Monats nach der 72-Stunden-Meldung vorliegen.

Die Meldung läuft über die CRA-Meldeplattform.

Verpflichtet ist der Hersteller, nicht automatisch jedes Unternehmen, das einen Router kauft oder ein Netz betreibt. Die im Juli veröffentlichten Leitlinien der Europäischen Kommission behandeln unter anderem den Anwendungsbereich und wesentliche Änderungen. Laut Kommissionszusammenfassung ist Hersteller, wer ein Produkt entwickelt oder fertigt – oder fertigen lässt – und es unter eigenem Namen oder eigener Marke auf dem EU-Markt bereitstellt. Ein unverändertes Gerät zu kaufen, macht einen Betreiber allein dadurch nicht zum Hersteller.

Der Verkauf unter eigener Marke oder eine wesentliche Änderung kann die Einordnung ändern; entscheidend sind Produkt und Vertriebsmodell.

Hier treffen Recht und Betrieb aufeinander. ETSI teilte am 13. August mit, dass 17 vertikale endgültige Normenentwürfe zur öffentlichen Konsultation vorlagen. Sie sollen zu harmonisierten Normen werden, waren aber noch Entwürfe. Je nach Produktbereich sollte das Genehmigungsverfahren von Mitte September bis Mitte November 2026 laufen. Mandalari rief die RIPE-Teilnehmer dazu auf, Beispiele zu Supportzeiten, Netzgeräten, Softwarevertrieb und Update-Prozessen einzureichen.

Die Zusage eines Lieferanten, Updates bereitzustellen, reicht nicht. Betreiber müssen wissen, wie ein Sicherheitsupdate getestet, geprüft, ausgerollt und auf seine Folgen bewertet wird. Der CRA verlangt von Herstellern, eine Supportdauer festzulegen und anzugeben. Ein Netzgerät kann jedoch länger im Einsatz bleiben. Endet der Support vor dem geplanten Austausch, wird aus einer Beschaffungsentscheidung eine kurzfristige Migration.

Mandalari arbeitet an der Schnittstelle von Forschung, Netzbetrieb und Normung. UCL führt sie als stellvertretende Direktorin des Institute of Communications and Connected Systems; ETSI nennt sie als Sekretärin der Arbeitsgruppe CYBER EUSR und Vorsitzende der RIPE-IoT-Arbeitsgruppe. Ihre Frage an die Community ist eine Betriebsfrage: Wer verantwortet das nächste Update und wer meldet zuerst, wenn das Produkt versagt?

Die Kommission hat Umsetzungshinweise veröffentlicht, und die Meldeplattform ist in Betrieb. Jetzt müssen Produktidentität, Lieferantenrolle, Supportdauer und Incident-Verantwortung verbunden werden, bevor ein echter Vorfall die Suche danach in einen 24-Stunden-Sprint verwandelt.

Quellen