
In diesem Artikel (4)
Analyse der Meldepflichten nach Artikel 14 des EU Cyber Resilience Act
Kernaussagen
- Behandeln Sie das Bewusstsein über Exploits als Auslöser für eine Meldung, nicht nur als Engineering-Ticket.
- Bereiten Sie Vorlagen vor, die Produktauswirkungen, Exploit-Details, ergriffene Abhilfemaßnahmen und Nutzeraktionen erfassen.
- Halten Sie die heutige Meldepflicht nach Artikel 14 von den vollständigen CRA-Pflichten getrennt, die später fällig werden.
Der CRA ist noch nicht vollständig anwendbar, aber die Frist für die Meldung von Vorfällen und Schwachstellen läuft jetzt für abgedeckte Produkte.
Der CRA ist noch nicht vollständig anwendbar, aber seine Frist für die Meldung von Vorfällen und Schwachstellen läuft nun für erfasste Produkte.
Ein Vulnerability-Ticket war früher ein Eintrag in einer Warteschlange. Seit dem 11. September kann es für Produkte mit digitalen Elementen, die in der Europäischen Union verkauft werden, auch eine regulatorische Uhr sein. Der Cyber Resilience Act wartet größtenteils noch im Hintergrund, und genau deshalb ist Artikel 14 wichtig: Ein Teil des Gesetzes ist frühzeitig angekommen, und er landet direkt im Incident Response. Die praktische Frage ist nicht, ob ein Produktteam den CRA gelesen hat. Sie lautet, ob jemand innerhalb von 24 Stunden entscheiden kann, ob eine aktiv ausgenutzte Schwachstelle oder ein schwerwiegender Vorfall gemeldet werden muss, wer die Meldung einreicht und welche Nachweise dazugehören. Juristen nennen das eine Meldepflicht. Entwickler sollten es einen Produktions-Workflow mit einer Regulierungsbehörde am Ende nennen.
Der Teil des
CRA, der bereits im Kalender steht Pearl Cohen beschreibt, dass der CRA in drei Phasen umgesetzt wird: Pflichten für Konformitätsbewertungsstellen ab dem 11. Juni 2026, die Meldung von Schwachstellen nach Artikel 14 ab dem 11. September 2026 und der vollständige CRA ab dem 11. Dezember 2027. Cybersecurity Time ergänzt die nützliche Klarstellung, dass der Rechtsakt am 10. Dezember 2024 in Kraft getreten ist, während seine wichtigsten Pflichten erst später gelten. Dieser Unterschied ist nicht akademisch; er bedeutet, dass Teams heute außerhalb des Geltungsbereichs der vollständigen Produktanforderungen liegen können und trotzdem für Meldungen im Geltungsbereich sind.
Pearl Cohen sagt, dass der CRA sowohl Hardware- als auch Softwareprodukte mit digitalen Elementen abdeckt, die auf dem EU-Markt bereitgestellt werden. Das ist die Formulierung, die Softwareanbieter unterstreichen sollten, am besten bevor der Vertrieb an einem Freitagnachmittag einen weiteren EU-Kunden unterschreibt. Es geht nicht nur um ein Problem mit vernetzten Thermostaten; es kann auch Softwareprodukte betreffen, wenn sie abgedeckte Produkte mit digitalen Elementen sind.
Was Artikel 14 tatsächlich verlangt
Crowell sagt, dass die Meldepflicht nach Artikel 14 des CRA ab dem 11. September 2026 gilt und ab diesem Datum durchgesetzt werden kann, während der übrige CRA im Allgemeinen ab dem 11. Dezember 2027 gilt. Die Kanzlei sagt außerdem, dass Hersteller eine einzige Meldung über die zentrale Meldeplattform an das zuständige Computer Security Incident Response Team, das als Koordinator benannt ist, und an ENISA übermitteln. Diese Meldung wird dann gegebenenfalls mit anderen relevanten CSIRTs geteilt, was erfreulicherweise anders ist als bei Regelwerken, bei denen die Zuständigkeitskarte für die Einreichung zum eigenen Vorfall wird.
Der Rechtstext von Artikel 14 besagt, dass ein Hersteller jede aktiv ausgenutzte Schwachstelle in einem Produkt mit digitalen Elementen melden muss, sobald er davon Kenntnis erlangt, und zwar gleichzeitig an den CSIRT-Koordinator und ENISA über die zentrale Meldeplattform. Außerdem verlangt er eine Frühwarnung innerhalb von 24 Stunden nach Kenntniserlangung und eine weitere Schwachstellenmeldung innerhalb von 72 Stunden, sofern die relevanten Informationen nicht bereits bereitgestellt wurden. Die 72-Stunden-Meldung muss, soweit verfügbar, allgemeine Informationen über das Produkt, die Art des Exploits und der Schwachstelle, ergriffene Korrektur- oder Minderungsmaßnahmen sowie Maßnahmen enthalten, die Nutzer ergreifen können.
In operative Abläufe übersetzt bedeutet Artikel 14, dass euer Incident-Workflow mindestens vier Felder braucht, die Security-Tickets oft über Chats, Postmortems und Release Notes verstreuen. Ihr braucht das betroffene Produkt, die allgemeine Beschreibung von Exploit und Schwachstelle, was das Unternehmen getan hat und was Nutzer tun können. Wenn diese Informationen nicht schnell erfassbar sind, ist das Meldeproblem bereits sichtbar.
Wer darauf achten sollte, einschließlich Nicht-EU-Verkäufern
Faegre Drinker beschreibt die Fristen im September 2026 als anwendbar auf Hersteller vernetzter Produkte und weist auf die extraterritoriale Reichweite für US-Unternehmen hin. Pearl Cohens Zusammenfassung der Leitlinien der Kommission bestätigt, dass der CRA für Hardware- und Softwareprodukte gilt, die auf dem EU-Markt bereitgestellt werden. Klar gesagt: Außerhalb der EU gegründet zu sein, ist kein magischer Tarnumhang, wenn das Produkt dort verfügbar gemacht wird.
Hier werden Lieferantenverträge und interne Zuständigkeiten wichtig. Wenn ein Hersteller auf einen Managed Service Provider, Wiederverkäufer, Schwachstellenforscher, Cloud-Host oder Komponentenlieferanten angewiesen ist, um von einer Ausnutzung zu erfahren, braucht das Unternehmen trotzdem einen Weg von diesem Signal zur entscheidungsbefugten Person für Artikel 14. Die hier vorliegenden Nachweise sagen nicht, dass jeder Lieferant melden muss; also lasst Compliance-Gerüchte nicht schneller laufen als den Text. Der sicherere operative Schritt ist, sicherzustellen, dass Verträge eine schnelle Sicherheitsbenachrichtigung, nutzbare technische Details und Zusammenarbeit bei Mitteilungen zu Minderungsmaßnahmen verlangen.
Crowell weist außerdem auf Bevollmächtigte und Eskalationsprozesse hin, die gegen die 24-Stunden-Uhr laufen können. Das ist eine höfliche Art zu sagen, dass der Meldeweg nicht im Posteingang einer einzelnen Person leben darf. Produkt, Security, Rechtsabteilung, Support und Kundenkommunikation brauchen eine geprobte Übergabe, denn die Uhr startet, wenn der Hersteller Kenntnis erlangt, nicht wenn der perfekte Postmortem-Entwurf fertig ist.
Was ihr diese Woche operationalisieren solltet
Crowell empfiehlt Tabletop-Übungen, Mitarbeiterschulungen und Aktualisierungen von Cyber-Richtlinien als Reaktion auf die Uhr nach Artikel 14. Das sind keine zeremoniellen Compliance-Objekte, wenn sie die richtigen Fehlermodi testen: Wer erkennt aktive Ausnutzung, wer entscheidet über den Schweregrad, wer eröffnet den Prozess auf der zentralen Meldeplattform und wer genehmigt Formulierungen zu Minderungsmaßnahmen für Nutzer. Eine Tabletop-Übung, die damit endet, dass alle einer weiteren Untersuchung zustimmen, ist keine Einsatzbereitschaft; sie ist ein Meeting mit Snacks.
Die nützliche Trennung liegt zwischen dem, was das Gesetz jetzt verlangt, und dem, was das Internet behaupten wird, dass es verlangt. Jetzt: Meldung aktiv ausgenutzter Schwachstellen und schwerwiegender Vorfälle nach Artikel 14, mit einer Frühwarnung innerhalb von 24 Stunden und einem Follow-up-Weg innerhalb von 72 Stunden, laut Crowell und dem Text von Artikel 14. Später: der vollständige Satz wesentlicher Cybersicherheitsanforderungen des CRA, der laut Pearl Cohen ab dem 11. Dezember 2027 gilt.
Für Entwickler ist die unmittelbare Arbeit klein, aber gnadenlos. Ordnet Produkte zu, die auf dem EU-Markt verkauft oder bereitgestellt werden, definiert Auslöser für Kenntniserlangung, bereitet Meldevorlagen vor, benennt bei Bedarf einen Bevollmächtigten und probt den Weg zur zentralen Meldeplattform. Beobachtet dann weiter die Lücke zwischen der Durchsetzung von Artikel 14 und dem Datum des vollständigen CRA, denn Regulierungsbehörden lernen meist aus den ersten Meldungen, lange bevor die erste Geldbuße erscheint.