CRA-Konformität

Ausnutzbar vs. ausgenutzt: Die rechtliche Unterscheidung, die Ihre CRA-Konformität bestimmt

Von Das CVD-Portal-Team
9 Min. Lesezeit

Der EU Cyber Resilience Act (CRA) führt einen strukturierten, rechtsverbindlichen Rahmen dafür ein, wie Hersteller von Produkten mit digitalen Elementen Schwachstellen handhaben müssen. Während sich viel Aufmerksamkeit auf die Anforderungen der Konformitätsbewertung richtet, haben die Pflichten zur Schwachstellenbehandlung und Meldung eigene, eigenständige Fristen, und die erste davon rückt bereits näher.

Hersteller müssen die Meldepflichten des CRA ab dem 11. September 2026 erfüllen, mehr als ein Jahr vor dem 11. Dezember 2027, ab dem die übrige Verordnung gilt. Entscheidend ist, dass diese Pflichten Produkte erfassen, die bereits auf dem Markt sind. Artikel 69 Absatz 2 nimmt Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, grundsätzlich aus, sofern sie keine wesentliche Veränderung erfahren, und Artikel 69 Absatz 3 weicht davon eigens für Artikel 14 ab. Die Meldepflicht gilt daher für jedes in den Anwendungsbereich fallende Produkt, das vor diesem Datum in Verkehr gebracht wurde, was dem üblichen Bild von Bestandsportfolios genau entgegensteht.

Woher Schwachstellen kommen: Drei Zuflüsse

Wirksame CRA-Konformität beginnt mit der Erkenntnis, dass Schwachstellen Hersteller über mehrere Kanäle erreichen, jeder mit eigenen operativen Auswirkungen.

Feldmeldungen treffen ein, wenn Schwachstellen in bereits eingesetzten Produkten entdeckt werden. Diese zuverlässig zu erhalten, erfordert eine dokumentierte Richtlinie zur koordinierten Offenlegung von Schwachstellen, einen Mechanismus, über den externe Forscher, Kunden und Sicherheitsfachleute Funde strukturiert an den Hersteller melden können. Anhang I Teil II Nummer 5 macht das Einrichten und Durchsetzen einer solchen Richtlinie zur gesetzlichen Anforderung, und Anhang II Nummer 2 verlangt, dass die zentrale Anlaufstelle für Meldungen und der Fundort der Richtlinie mit dem Produkt bereitgestellt werden.

Lieferantenbenachrichtigungen spiegeln die zusammengesetzte Natur der meisten Produkte wider. Nur wenige Hersteller bauen jede Komponente selbst. Identifiziert ein Komponentenlieferant eine Schwachstelle in etwas, das er an Sie liefert, ist er verpflichtet, nachgelagerte Nutzer zu informieren. Diese Benachrichtigungen fließen direkt in den eigenen Schwachstellenmanagement-Prozess des Herstellers ein.

Proaktive Entdeckung ist der dritte Zufluss, und derjenige, den Hersteller nicht allein durch reaktive Prozesse ersetzen können. Regelmäßige Penetrationstests und interne Sicherheitsüberprüfungen sind anerkannte Ansätze, um ein aktives Bewusstsein für die Schwachstellenlandschaft eines Produkts zu erhalten, bevor andere sie zuerst entdecken.

Ein dreistufiger Pflichtenrahmen

Der CRA legt keine einzige, undifferenzierte Pflicht auf. Er etabliert drei eigenständige Pflichtenstufen, von denen jede unterschiedliche Anforderungen auslöst.

Stufe 1: Alle Schwachstellen bewerten. Hersteller müssen jede Schwachstelle, die für ihr Produkt relevant sein könnte, aktiv handhaben und ihr Risiko bewerten. Es gibt keine Schwelle, unterhalb derer eine Schwachstelle von vornherein ignoriert werden dürfte. Die Pflicht besteht darin, hinzusehen und zu bewerten.

Stufe 2: Bekannte, ausnutzbare Schwachstellen vor der Markteinführung bis zur Behebung verfolgen. Sobald eine Schwachstelle im Kontext des spezifischen Produkts als ausnutzbar erkannt wird, muss der Hersteller sie beheben, bevor er das Produkt in Verkehr bringt. Der Maßstab des CRA ist bewusst gewählt: Produkte müssen frei von bekannten ausnutzbaren Schwachstellen sein, nicht frei von allen Schwachstellen. Wo eine Schwachstelle existiert, im Einsatzkontext des Produkts aber nachweislich nicht ausnutzbar ist, mit dokumentierter Begründung, darf sie bestehen bleiben. Null Schwachstellen ist kein realistischer oder geforderter Maßstab; null ungerechtfertigte ausnutzbare Schwachstellen schon.

Stufe 3: Aktiv ausgenutzte Schwachstellen unverzüglich melden. Wird ein Hersteller gewahr, dass eine Schwachstelle in seinem Produkt im Feld aktiv ausgenutzt wird, verlangt Artikel 14 Absatz 1 eine Meldung. Das ist ein eigenständiger Auslöser, getrennt vom schwerwiegenden Sicherheitsvorfall, den Artikel 14 Absatz 3 auf einer eigenen Spur mit eigener Frist für den Abschlussbericht behandelt. Die Vermengung beider führt dazu, dass Meldungen auf der falschen Uhr laufen. Die Meldung geht gleichzeitig an das als Koordinator benannte CSIRT und an ENISA, in einer einzigen Übermittlung über die zentrale Meldeplattform. Artikel 14 Absatz 7 bestimmt dieses CSIRT nach der Hauptniederlassung in der Union, also dem Ort, an dem die Entscheidungen über die Cybersicherheit der Produkte überwiegend getroffen werden, und folgt damit nicht automatisch dem Sitz der Gesellschaft. Diese Pflichten gelten unabhängig davon, wie alt das betroffene Produkt ist.

Die EUVD: eine nützliche Referenz, aber keine hinreichende

Eine praktische Frage, die sich aus Stufe 2 ergibt, lautet: Wie stellt ein Hersteller fest, ob eine Schwachstelle „bekannt“ ist? Die Europäische Schwachstellendatenbank (EUVD) ist der naheliegende Ausgangspunkt, und es lohnt sich, genau zu sein, was sie ist und was nicht.

Die EUVD wird von ENISA nach Artikel 12 Absatz 2 der NIS2-Richtlinie betrieben, nicht nach dem CRA, und der CRA benennt sie nicht als maßgebliches Register bekannter ausnutzbarer Schwachstellen. Ihre Einträge enthalten eine technische Beschreibung, betroffene Produkte und Versionen, den Schweregrad, Angaben zur Ausnutzung sowie Hinweise zur Risikominderung, und sie führt eine Ansicht der als ausgenutzt bekannten Schwachstellen.

Zwei Grenzen sind für die Compliance-Planung wichtig. Die EUVD bildet nicht jede CVE ab; unabhängige Auswertungen haben Zehntausende CVEs gefunden, die ihre zentrale API nicht ausliefert. Wer sie als vollständiges Bild behandelt, lässt reale Lücken. Ihre Liste ausgenutzter Schwachstellen stützt sich zudem stark auf CISA KEV und lässt einzelne Einträge aus.

Daraus folgt praktisch: Erscheint eine Schwachstelle in der EUVD, ist die Behauptung der Unkenntnis schwer zu halten. Ihr Fehlen dort belegt dagegen nichts. Hersteller sollten die EUVD überwachen, wo möglich automatisiert, und zwar neben CVE und NVD, Hersteller- und Upstream-Advisories sowie eigenen Komponenten-Feeds aus der SBOM.

Allein die EUVD zu beobachten ist eine dünnere Abdeckung, als die Pflicht der Stufe 1 zum Suchen und Bewerten tatsächlich verlangt.

Meldefristen: Präzision zählt

Wird eine Schwachstelle aktiv ausgenutzt und löst damit die Pflicht der Stufe 3 aus, legt der CRA strenge Meldefristen fest, die keinen Raum für Verzögerung lassen:

  1. Innerhalb von 24 Stunden nach Kenntniserlangung: eine Frühwarnung, die, soweit einschlägig, die Mitgliedstaaten angibt, in denen das Produkt bereitgestellt wurde.
  2. Innerhalb von 72 Stunden: eine Schwachstellenmeldung mit allgemeinen Angaben zum betroffenen Produkt, zur allgemeinen Art des Exploits und der Schwachstelle, zu ergriffenen Korrektur- oder Abhilfemaßnahmen sowie zu Maßnahmen, die Nutzer ergreifen können. Hier geben Sie auch an, wie sensibel Sie die Informationen einschätzen.
  3. Spätestens 14 Tage, nachdem eine Korrektur- oder Abhilfemaßnahme verfügbar ist: ein Abschlussbericht mit einer Beschreibung der Schwachstelle einschließlich Schweregrad und Auswirkungen, soweit verfügbar Angaben zu einem ausnutzenden Bedrohungsakteur sowie Einzelheiten zum Sicherheitsupdate oder zu anderen Korrekturmaßnahmen.

Die Spur für schwerwiegende Sicherheitsvorfälle nach Artikel 14 Absatz 4 läuft über 24 Stunden, dann 72 Stunden, dann einen Abschlussbericht innerhalb eines Monats nach der 72-Stunden-Meldung, mit einer ausführlichen Beschreibung, der wahrscheinlichen Grundursache und den ergriffenen und laufenden Abhilfemaßnahmen.

Dieser Unterschied ist der entscheidende. Der Abschlussbericht zur Schwachstelle hängt daran, dass eine Korrektur verfügbar ist, und lässt sich deshalb bei der 72-Stunden-Meldung noch nicht terminieren. Der Bericht zum Sicherheitsvorfall hängt an der früheren Meldung und lässt sich terminieren. Zu beachten ist außerdem: „schwerwiegend“ ist der Begriff des CRA. Der „erhebliche Sicherheitsvorfall“ gehört zu Artikel 23 NIS2, einer eigenen Pflicht mit eigenem Adressaten.

Diese Berichte laufen über die nach Artikel 16 eingerichtete zentrale EU-Meldeplattform, die ENISA bis zum 11. September 2026 betriebsbereit stellen will, mit einer Testphase davor. Eine Übermittlung am Endpunkt des koordinierenden CSIRT ist gleichzeitig für ENISA zugänglich, und dieses CSIRT verteilt sie anschließend an die CSIRTs der Mitgliedstaaten, in denen das Produkt nach Ihrer Angabe bereitgestellt wurde. Verantwortungsvolle Offenlegung, so kalibriert, dass sie Bedrohungsakteuren nicht hilft und zugleich ein legitimes Lagebild ermöglicht, bleibt die richtige Arbeitshaltung. Klarzustellen ist allerdings, dass Artikel 14 selbst keine „Offenlegungsstrategie“ als benanntes Element einer der drei Meldungen verlangt.

Ausnutzbar vs. ausgenutzt: Die rechtliche Unterscheidung

Diese beiden Begriffe wirken in der Alltagssprache ähnlich. Im CRA-Rahmen tragen sie wesentlich unterschiedliche rechtliche Folgen.

Eine ausnutzbare Schwachstelle ist eine, die theoretisch von einem Angreifer genutzt werden könnte, aber noch nicht aktiv als Waffe eingesetzt wurde. Ausnutzbare Schwachstellen sind Gegenstand der Pflicht der Stufe 2: Sie müssen behoben werden, bevor ein Produkt auf den Markt gelangt, oder als akzeptables Risiko im spezifischen Einsatzkontext begründet werden.

Eine aktiv ausgenutzte Schwachstelle ist eine, bei der ein Angreifer den Fehler erfolgreich gegen ein reales Produkt im Feld eingesetzt hat. Das ist der Auslöser der Stufe 3: die 24-Stunden-Meldepflicht.

Eine offene Frage, die an die Europäische Kommission herangetragen wurde, betrifft Proof-of-Concept-Exploit-Code (PoC). Ein veröffentlichter PoC zeigt, dass die Ausnutzung technisch machbar ist, belegt aber nicht, dass eine aktive, andauernde Angriffskampagne im Gange ist. Die Kommission hat zu dieser Unterscheidung noch keine rechtssichere Leitlinie herausgegeben. Bis dahin sollten Hersteller im Zweifel einen veröffentlichten PoC als eskalierend behandeln und genau auf Indikatoren aktiver Ausnutzung achten.

Was das in der Praxis bedeutet

Die Frist am 11. September 2026 ist nicht das Ende des Compliance-Wegs, sondern der Beginn des operativ anspruchsvollsten Teils davon. Hersteller, die noch keine Richtlinie zur koordinierten Offenlegung von Schwachstellen eingerichtet, ihre Benachrichtigungsketten bei Komponentenlieferanten kartiert, ihr koordinierendes CSIRT nach Artikel 14 Absatz 7 bestimmt oder eine Schwachstellenüberwachung in ihre Abläufe eingebaut haben, sollten diese Frist als erzwingende Funktion behandeln.

Der Schwachstellenbehandlungsrahmen des CRA belohnt Hersteller, die Sicherheit als kontinuierliche operative Disziplin behandeln statt als Checkliste vor der Veröffentlichung. Die regulatorische Exposition für jene, die das nicht tun, ist nun sowohl konkret als auch zeitlich befristet.

Bleiben Sie konform mit dem Cyber Resilience Act

Prüfen Sie Ihre Bereitschaft mit der CRA-Bereitschafts-Checkliste oder vergleichen Sie die Tarife auf der Preisseite.

Kostenlos starten