STEFAN MÜLLER// EMBEDDED SYSTEMS

Was die CRA-Meldepflicht ab September konkret verlangt

  • cyber-resilience-act
  • embedded
  • compliance
  • prozesse

Der Cyber Resilience Act gilt in vollem Umfang ab dem 11. Dezember 2027. Ein Teil davon greift jedoch deutlich früher: Die Meldepflichten nach Artikel 14 gelten bereits ab dem 11. September 2026.

Sie unterscheiden sich von den übrigen Herstellerpflichten in einem wesentlichen Punkt. Konformitätsbewertung, SBOM und CE-Kennzeichnung betreffen Produkte, die ab Dezember 2027 neu in Verkehr gebracht werden. Die Meldepflichten knüpfen dagegen nicht am Inverkehrbringen an, sondern an der Kenntniserlangung. Wer ab September von einer aktiv ausgenutzten Schwachstelle in einem Produkt erfährt, das seit acht Jahren im Feld läuft, ist meldepflichtig. Das Bestandsportfolio ist also von Anfang an betroffen.

Entsprechend gross ist die Verunsicherung. Was genau ist zu melden, in welcher Form, und was muss dafür im Unternehmen vorbereitet sein?

Auf die letzte Frage gibt es inzwischen eine überraschend konkrete Antwort. Die ENISA hat in ihrer FAQ zur Meldeplattform aufgeschlüsselt, welche Angaben in jeder der drei Meldestufen verlangt werden und welche davon verpflichtend sind. Diese Aufstellung lässt sich lesen wie ein Lastenheft: Aus ihr ergibt sich, welche Informationen wie schnell verfügbar sein müssen und welche Abläufe bis September stehen sollten. Darum geht es im Folgenden.

Der Rahmen in Kürze

Meldepflichtig sind genau zwei Sachverhalte.

Aktiv ausgenutzte Schwachstellen. Nach der Definition der Verordnung liegt eine solche vor, wenn verlässliche Belege dafür existieren, dass ein böswilliger Akteur die Schwachstelle in einem System ohne Erlaubnis des Systeminhabers ausgenutzt hat. Massgeblich ist also die belegte Ausnutzung, nicht die theoretische Ausnutzbarkeit.

Schwerwiegende Sicherheitsvorfälle. Ereignisse, die die Fähigkeit des Produkts beeinträchtigen, Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit von Daten oder Funktionen zu schützen, oder die zur Einbringung beziehungsweise Ausführung von Schadcode geführt haben oder führen können.

Nicht meldepflichtig sind Schwachstellen, die man selbst findet und behebt, bevor sie ausgenutzt werden. Ebenso wenig Fälle, deren aktive Ausnutzung bereits vor Anwendbarkeit der Meldepflicht bekannt war. Der Stichtag schafft keine rückwirkende Nachmeldepflicht.

Gemeldet wird in drei Stufen über die von der ENISA betriebene Single Reporting Platform. Eine einzige Einreichung genügt dabei: Die Meldung geht an das koordinierende CSIRT und an die ENISA, und von dort an die weiteren betroffenen Stellen. Es ist also nicht erforderlich, jeden Mitgliedstaat einzeln zu benachrichtigen.

Die folgenden Kapitel gehen die drei Stufen einzeln durch: erst die Angaben, die verlangt werden, dann das, was der Prozess dafür leisten muss.

Die im Folgenden aufgeführten Meldeinhalte stammen aus der FAQ der ENISA zur Single Reporting Platform, Stand 31. Juli 2026, hier ins Deutsche übertragen.

Stufe 1: Die Frühwarnung, 24 Stunden

Was auszufüllen ist

Verpflichtend:

  • Meldungstyp: Schwachstelle oder Sicherheitsvorfall
  • Name des Herstellers beziehungsweise Open-Source-Verwalters
  • Produkt
  • Titel
  • bei Sicherheitsvorfällen zusätzlich: ob der Vorfall auf unrechtmässige oder böswillige Handlungen zurückgeführt wird

Verpflichtend, sofern die Information vorliegt:

  • Mitgliedstaaten, in denen das Produkt verfügbar ist

Optional, aber bereits hier befüllbar:

  • Produkttyp: Standardprodukt, wichtiges oder kritisches Produkt
  • Produktkategorie: nur bei wichtigen und kritischen Produkten relevant; die Kategorien sind in Anhang III und IV der Verordnung aufgelistet
  • bei Schwachstellen: CVE- und EUVD-ID

Dazu kommt die Angabe, um welche der drei Meldestufen es sich handelt, ein reines Formularfeld ohne Vorbereitungsaufwand. Zeitstempel und die Angabe des Meldenden erfasst die Plattform selbst.

Das ist bemerkenswert wenig Text. Der Umfang ist bewusst schmal gehalten: Die Frühwarnung soll die CSIRTs in Kenntnis setzen, nicht analysieren. Der Aufwand liegt entsprechend nicht im Schreiben.

Was der Prozess dafür leisten muss

Die Meldeentscheidung. Hinter dem Auswahlfeld „Meldungstyp“ steckt die eigentliche Arbeit dieser Stufe: Ist der Fall überhaupt meldepflichtig, und wenn ja, als Schwachstelle oder als Sicherheitsvorfall? Diese Entscheidung muss gegen ein schriftliches Kriterium fallen, nicht nach Gefühl, und sie muss innerhalb weniger Stunden fallen.

Entlastend wirkt, dass die Verordnung in Artikel 17 Absatz 4 klarstellt, dass allein die Abgabe einer Meldung keine erhöhte Haftung begründet. Zusammen mit der Möglichkeit der freiwilligen Meldung nach Artikel 15 ist die Meldung im Zweifelsfall der günstigere Fehler. Aber auch die begründete Entscheidung, nicht zu melden, gehört dokumentiert. Sie ist der Nachweis gegenüber der Marktüberwachung.

Ein Produktinventar, das Baustände kennt. Das Feld „Produkt“ wirkt trivial und ist es nicht. Die Frage lautet nicht „betrifft es Produkt X“, sondern „welche ausgelieferten Stände von X enthalten die betroffene Komponente“. Die Einstufung nach Anhang III beziehungsweise IV gehört ebenfalls vorher geklärt; sie hat ohnehin Auswirkungen auf die Konformitätsbewertung ab 2027, und unter Zeitdruck darüber zu diskutieren, ist der falsche Moment.

Gepflegte Vertriebsdaten. Die Liste der Mitgliedstaaten ist das einzige Feld dieser Stufe, das echte Vorarbeit verlangt, und sie steuert die Verteilung: Das empfangende CSIRT leitet die Meldung an die CSIRTs derjenigen Mitgliedstaaten weiter, in denen das Produkt verfügbar ist. Bei Direktvertrieb ist das beantwortbar. Bei mehrstufigem Vertrieb über Distributoren und Systemintegratoren oft nicht, und niemand beantwortet es aus dem Kopf. Wer diese Liste erst am Samstagmorgen zusammensucht, verbrennt einen halben Tag mit Recherche statt mit Analyse.

Zugang zur Plattform. Für den initialen Rollout sind keine Schnittstellen vorgesehen; die Eingabe erfolgt manuell über das Portal. Und die ENISA empfiehlt ausdrücklich, sich erst dann zu registrieren und die Validierung anzustossen, wenn eine konkrete Meldung ansteht, um die Validierungslast der CSIRTs nicht unnötig zu erhöhen. Die Validierung läuft danach parallel und blockiert die Einreichung nicht. Praktisch heisst das: Der erste Login findet unter laufender Uhr statt. Vorbereitbar ist genau eines: das EU-Login-Konto, das sich jederzeit vorab anlegen lässt.

Die Kenntnis, an welches CSIRT die Meldung geht. Die Meldung wird zwar über die zentrale Plattform eingereicht, aber über den Meldeendpunkt eines bestimmten CSIRT, nämlich desjenigen Mitgliedstaats, dessen CSIRT für den Hersteller als Koordinator benannt ist. Dieses CSIRT ist der Empfänger und verteilt die Meldung anschliessend weiter. Welches es ist, legt Artikel 14 Absatz 7 fest.

Massgeblich ist zunächst die Hauptniederlassung in der Union: der Mitgliedstaat, in dem die Entscheidungen zur Cybersicherheit der Produkte überwiegend getroffen werden. Lässt sich das nicht bestimmen, ist es der Mitgliedstaat mit der höchsten Beschäftigtenzahl in der Union.

Besteht keine Hauptniederlassung in der Union, was für Schweizer Hersteller ohne EU-Tochtergesellschaft der Regelfall ist, greift eine feste Reihenfolge, jeweils auf Grundlage der dem Hersteller verfügbaren Informationen:

  1. falls vorhanden: der Mitgliedstaat des Bevollmächtigten, der für die meisten Produkte des Herstellers handelt
  2. der Mitgliedstaat des Händlers, der die meisten Produkte des Herstellers auf dem Markt bereitstellt
  3. der Mitgliedstaat des Einführers, der die meisten Produkte des Herstellers in Verkehr bringt
  4. der Mitgliedstaat, in dem sich die meisten Nutzer der Produkte befinden

Diese Frage sollte einmal vorab beantwortet und festgehalten sein, nicht erst im Ernstfall, während die Frist läuft.

Stufe 2: Die Meldung mit Erstbewertung, 72 Stunden

Eine Vorbemerkung, die leicht überlesen wird: Die 72 Stunden laufen nicht ab der Frühwarnung, sondern ab derselben Kenntniserlangung wie die 24 Stunden. Nach abgesetzter Frühwarnung bleiben also faktisch 48 Stunden, nicht drei Tage.

Was auszufüllen ist

Die Angaben aus der Frühwarnung werden übernommen und können aktualisiert werden. Man schreibt die Meldung also nicht neu, sondern ergänzt sie. Neu verpflichtend kommen hinzu:

Bei Schwachstellen:

  • allgemeine Angaben, insbesondere zur Art der Schwachstelle und zur Art des Exploits
  • bereits ergriffene Korrektur- oder Abhilfemassnahmen
  • Massnahmen, die Nutzer selbst ergreifen können

Bei Sicherheitsvorfällen:

  • allgemeine Angaben zur Art des Vorfalls
  • Datum und Uhrzeit der Entdeckung
  • Datum und Uhrzeit des Eintritts
  • eine Erstbewertung des Sicherheitsvorfalls
  • bereits ergriffene Korrektur- oder Abhilfemassnahmen
  • Massnahmen, die Nutzer selbst ergreifen können

In beiden Fällen verpflichtend, sofern verfügbar: die eingeschätzte Sensitivität der Information. Über dieses Feld kann in eng begrenzten Ausnahmefällen eine verzögerte Weitergabe an weitere CSIRTs angestossen werden; für die allermeisten Meldungen ist es schlicht zu befüllen.

Praktisch alles, was in der Frühwarnung optional war, wird hier zur Pflicht. Das ist die Stufe, in der die inhaltliche Arbeit liegt.

Was der Prozess dafür leisten muss

Für jedes Produkt eine Person, die es untersuchen kann. Um „Art der Schwachstelle“ und „Art des Exploits“ zu beschreiben, muss jemand das Produkt technisch durchdringen, und zwar unter Zeitdruck, ohne Einarbeitung. Diese Zuordnung ist der wichtigste Punkt der gesamten Vorbereitung, und sie ist für jedes ausgelieferte Produkt zu klären, nicht nur für die aktuell entwickelten.

Die kritischen Fälle sind absehbar: Der ursprüngliche Entwickler hat das Unternehmen verlassen. Die Komponente wurde extern beauftragt. Das Projekt liegt Jahre zurück und niemand hat es seither angefasst. Wo sich beim Durchgehen der Produktliste keine Person benennen lässt, ist das kein Dokumentationsproblem, sondern ein Prozessrisiko, und es lässt sich nur vorher lösen. Liegt die Zuständigkeit ausserhalb des eigenen Unternehmens, hängt die Frist an der Erreichbarkeit und Reaktionszeit eines Dritten. Auch das sollte man wissen, bevor die Uhr läuft, und nicht erst dann.

Eine Übersicht der verbauten Komponenten. Zwingend erforderlich ist eine SBOM für die Meldung nicht; verlangt wird eine Beschreibung, kein Stücklistenauszug. Sehr hilfreich ist sie trotzdem, weil sich die vorgelagerte Frage damit in Minuten statt in Stunden beantworten lässt: Betrifft uns diese Schwachstelle überhaupt, und wenn ja, in welchen Produkten und Bauständen? Formal vorgeschrieben ist die Software Bill of Materials ohnehin erst ab Dezember 2027; wer sie früher aufbaut, hat den Nutzen bereits ab September.

Eine Priorisierungsregel, die vorher feststeht. Das Feld zu den bereits ergriffenen Massnahmen setzt voraus, dass zwischen Kenntniserlangung und Stunde 72 tatsächlich jemand gearbeitet hat. Die Person, die dafür in Frage kommt, ist aber im Normalfall eingeplant: in einem Projekt, an einer Auslieferung, bei einem Kunden. Ohne vorher vereinbarte Regel beginnt an dieser Stelle eine Aushandlung darüber, was liegen bleiben darf, und die kostet Stunden, die es nicht gibt. Was es braucht, ist eine schriftlich festgehaltene Vorrangregel für meldepflichtige Fälle und eine benannte Person, die im Zweifel entscheidet.

Arbeitsfähigkeit am betroffenen Produkt. Bei einem Feldgerät heisst untersuchen können mehr als Quellcode lesen. Lässt sich der ausgelieferte Stand überhaupt noch bauen? Existieren Toolchain, Buildumgebung und der passende Compiler noch? Ist ein Gerät zum Testen greifbar oder müsste erst eines beschafft oder beim Kunden zugänglich gemacht werden? Das sind Fragen, die sich an einem ruhigen Nachmittag beantworten lassen und die unter Zeitdruck den Unterschied machen.

Eine Kommunikationsvorlage. „Massnahmen, die Nutzer selbst ergreifen können“ ist der aufwendigste und am häufigsten unterschätzte Punkt der gesamten Meldung. Das ist kein technisches Feld, sondern eine kundentaugliche Handlungsempfehlung: verständlich, belastbar, abgestimmt.

Denn dieselbe Aussage geht parallel an die Anwender. Die Informationspflicht gegenüber den Nutzern besteht eigenständig neben der Behördenmeldung. Sie ergibt sich nicht aus ihr und wird von ihr nicht erfüllt. Wer beides getrennt angeht, macht die Arbeit zweimal und riskiert widersprüchliche Aussagen. Was vorher geklärt sein sollte: wie viel man sagt, solange kein Patch existiert.

Stufe 3: Der Abschlussbericht

Was auszufüllen ist

Bei Schwachstellen: spätestens 14 Tage nach Verfügbarkeit einer Korrekturmassnahme.

  • Datum der Verfügbarkeit der Korrekturmassnahme
  • vollständige Beschreibung, einschliesslich Schweregrad und Auswirkung
  • Details zum Sicherheitsupdate beziehungsweise zu den Korrekturmassnahmen
  • sofern verfügbar: Angaben zum böswilligen Akteur, der die Schwachstelle ausgenutzt hat

Bei schwerwiegenden Sicherheitsvorfällen: innerhalb eines Monats nach der Meldung.

  • detaillierte Beschreibung einschliesslich Schweregrad und Auswirkung des Sicherheitsvorfalls
  • Bedrohungsart beziehungsweise wahrscheinliche Ursache
  • ergriffene und laufende Gegenmassnahmen

Was der Prozess dafür leisten muss

Der Release-Prozess muss die Frist auslösen. Das Datum der Verfügbarkeit der Korrekturmassnahme ist Pflichtfeld und zugleich Fristanker für die 14 Tage. Es sollte im internen Vorgang gesetzt werden, sobald der Patch freigegeben ist, nicht erst beim Verfassen des Berichts. Andernfalls läuft die Frist, ohne dass jemand sie bemerkt, und zwar in genau dem Moment, in dem der Druck nachgelassen hat und alle Beteiligten sich wieder ihrer eigentlichen Arbeit zuwenden. Von allen drei Fristen ist diese die am leichtesten zu übersehende.

Dokumentation muss unterwegs entstehen, nicht rückwirkend. Schweregrad, Auswirkung und wahrscheinliche Ursache sind zwei Wochen nach dem Patch nur dann günstig zu beschaffen, wenn sie während der Analyse festgehalten wurden. Wer sie rekonstruieren muss, zahlt doppelt: einmal für die Rekonstruktion und einmal für deren Unsicherheit. Ein einfaches Ereignisprotokoll im laufenden Vorgang reicht dafür aus: was wann festgestellt, entschieden und verworfen wurde.

Die Ursachenanalyse muss eingeplant sein. Der Abschlussbericht verlangt bei Sicherheitsvorfällen die wahrscheinliche Ursache, bei Schwachstellen eine vollständige Beschreibung. Das ist Arbeit, die nach dem Patch anfällt und in keiner Planung steht. Sie gehört als Aufgabe mit eigenem Termin im Vorgang hinterlegt, sonst konkurriert sie mit allem, was während der Störung liegen geblieben ist.

Was das Formular nicht verrät

So weit die ableitbare Hälfte. Die andere steht nirgends im Formular, und dort scheitern Prozesse in der Praxis häufiger.

Wann die Uhr startet. Die Frist beginnt mit der Kenntniserlangung, nicht mit der Entscheidung zu melden. Kenntnis entsteht aber selten dort, wo entschieden wird: in einer Support-Anfrage, über die Kontaktstelle für Sicherheitsforscher, in einem Advisory des SoC-Herstellers oder BSP-Lieferanten, über einen KEV- oder EUVD-Eintrag zu einer verbauten Komponente, im Pentest-Bericht eines Kunden, in einer Rückmeldung aus der Inbetriebnahme, oder schlicht öffentlich über eine Mailingliste.

Support-Adresse, allgemeines Postfach, Telefon: Wer einen dieser Kanäle zuerst liest, sollte keine Bewertung vornehmen müssen. Es braucht ein Auslösekriterium: eine kurze, konkrete Liste von Anhaltspunkten, bei denen ohne Vorprüfung eskaliert wird. Jede Vorprüfung an dieser Stelle kostet Stunden, die später fehlen. Und jeder Kanal, der nur unregelmässig gelesen wird, ist eine Verzögerung, die in die Frist hineinläuft, bevor überhaupt jemand vom Fall weiss.

Unabhängig vom Kanal gehören Zeitpunkt, Quelle und Wortlaut schriftlich festgehalten. Ohne dokumentierten Nullpunkt lässt sich weder die Fristeinhaltung belegen noch der Prozess steuern.

Dass 24 Stunden auch am Wochenende 24 Stunden sind. Eine Meldung, die Freitag um 18:00 Uhr eingeht, ist Samstag um 18:00 Uhr fällig. Die Frage dahinter lautet: Wer setzt die Meldung ab, wenn die Person, die das üblicherweise tut, nicht erreichbar ist? Urlaub, Krankheit, eine Woche ohne Empfang: Die Frist läuft weiter. Ob die Antwort ein Bereitschaftsplan ist oder eine feste Absprache mit einem Kollegen oder Dienstleister, spielt keine Rolle. Wichtig ist nur, dass diese Person vorbereitet ist und Zugriff auf Inventar, Meldevorlage und Zugangsdaten hat.

Die Plattform sieht diesen Fall übrigens selbst vor: Sie unterscheidet einen primären Nutzer und einen Backup-Nutzer, wobei der zweite über eine Einladung des ersten hinzukommt. Die Einladung verfällt nach sieben Tagen. Der Vertretungsfall lässt sich dort also abbilden, aber nur, wenn beide Konten eingerichtet sind, bevor sie gebraucht werden.

Dass die Entscheidungsbefugnis vorher geklärt sein muss. Wenn die Meldeentscheidung faktisch an einer Freigabe von oben hängt, hängt die Frist an deren Erreichbarkeit. Wo delegiert wird, muss die Freigabe vorab schriftlich erteilt sein, mit klar definiertem Rahmen. Wo nicht delegiert wird, fehlt der zweite Blick, der eine Fehleinschätzung abfängt; dann ersetzt ihn ein schriftliches Triage-Kriterium zumindest teilweise, weil es die Entscheidung von der Tagesform ablöst.

Dass Endfristen als Steuerungsgrösse nicht ausreichen. Was funktioniert, ist eine Taktung in Zwischenzielen mit Puffer, jedes mit einem Namen dahinter:

Zeitpunkt Zwischenziel
T+4 h Meldeentscheidung getroffen und dokumentiert
T+20 h Frühwarnung abgesetzt
T+36 h technische Erstbewertung liegt vor
T+52 h Entwurf der 72-Stunden-Meldung inklusive Nutzerempfehlung
T+64 h Review, Freigabe, Einreichung

Der Puffer ist Absicht. Er ist der Unterschied zwischen einem Prozess, der eine Verzögerung verkraftet, und einem, der bei der ersten Unwägbarkeit die Frist reisst.

Dass man den Ernstfall einmal geprobt haben sollte. Ein Tabletop deckt in zwei Stunden mehr auf als jedes Konzeptpapier. Ein realistisches Szenario dafür: Freitagabend, Advisory eines Zulieferers, zuständige Person nicht erreichbar. Die ENISA plant zudem ein Webinar rund zwei Wochen vor Inbetriebnahme der Plattform.

Bis September

  1. Produktinventar mit Bauständen, CRA-Einstufung und Zuordnung der Vertriebsländer
  2. Für jedes ausgelieferte Produkt benannt, wer es im Ernstfall untersuchen kann, inklusive externer Beteiligter
  3. Bei extern verantworteten Komponenten geklärt, wie schnell dort reagiert wird; SBOM je Baustand, soweit vorhanden
  4. Vorrangregel für meldepflichtige Fälle schriftlich festgehalten; Buildumgebung und Testgerät je Produkt geprüft
  5. Zuständigkeit und Vertretung geklärt, Meldeentscheidung vorab schriftlich freigegeben
  6. Auslösekriterien für alle Kanäle mit Erstkontakt, kurz und ohne Bewertungsspielraum
  7. Meldevorlage nach den ENISA-Pflichtfeldern: ein Dokument über alle drei Stufen, nicht drei
  8. Kommunikationsvorlage und Nutzerverteiler für die parallele Informationspflicht
  9. EU-Login-Konto angelegt, zuständiges CSIRT nach Artikel 14 Absatz 7 einmal bestimmt
  10. Zwischenziel-Taktung mit benannten Verantwortlichen, inklusive der leicht übersehenen Abschlussfrist
  11. Ein Testdurchlauf vor dem 11. September

Bei Verstössen gegen die Meldepflichten sieht die Verordnung Bussgelder von bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes vor, je nachdem, welcher Betrag höher ist. Das ist der eine Grund, sich damit zu befassen.

Der bessere: Die Meldepflicht zwingt dazu, einmal durchzuspielen, wie das eigene Unternehmen reagiert, wenn etwas schiefgeht: wer es erfährt, wer entscheidet, wer daran arbeitet, wer mit dem Kunden spricht. Diese Fragen zu beantworten lohnt sich auch ohne Regulierung. Der Unterschied ist nur, dass sie ab September eine Frist haben.

Quellen

Stand der Angaben zu den Meldeinhalten: 31. Juli 2026. Die ENISA-FAQ wird laufend fortgeschrieben; vor dem Anlegen einer eigenen Vorlage lohnt ein Blick auf die aktuelle Fassung.

Entstanden unter Mitwirkung von KI. Recherche, Auswahl und Prüfung der Inhalte anhand der genannten Quellen stammen von mir.

Dieser Beitrag ist eine technische Einordnung und keine Rechtsberatung. Verbindlich sind der Verordnungstext und die Leitlinien der zuständigen Behörden.

← Alle Beiträge