Die Begriffe des Cyber Resilience Act

Der Cyber Resilience Act ist die Verordnung (EU) 2024/2847. Sie gilt seit dem 10.12.2024 unmittelbar in allen Mitgliedstaaten — anders als eine Richtlinie braucht sie keine nationale Umsetzung, damit sie für Sie verbindlich wird.

Sie richtet sich an Hersteller, Einführer und Händler von Produkten mit digitalen Elementen und verlangt zweierlei: Das Produkt muss über seinen gesamten Unterstützungszeitraum sicher entwickelt, gepflegt und mit Updates versorgt werden, und der Hersteller muss aktiv ausgenutzte Schwachstellen sowie schwerwiegende Sicherheitsvorfälle innerhalb kurzer Fristen melden.

Zwei Stichtage sind entscheidend: Seit dem 11.09.2026 gelten die Meldepflichten (Art. 14), ab dem 11.12.2027 gilt die Verordnung vollständig — einschließlich Produktanforderungen, Konformitätsbewertung und CE-Kennzeichnung.

Der CRA spricht nicht von „Software“, sondern von Produkten mit digitalen Elementen: Software- oder Hardwareprodukte samt getrennt bereitgestellter Software- oder Hardwarekomponenten, deren bestimmungsgemäße Verwendung eine Datenverbindung zu einem Gerät oder Netz einschließt.

Praktisch fällt darunter fast alles, was Ihr Haus mit einer Steuerung, einem Webinterface, einer Fernwartung oder einer Cloud-Anbindung ausliefert — die Maschine ebenso wie der Sensor mit Firmware und das Konfigurationswerkzeug auf dem Windows-Rechner des Kunden.

Ausgenommen sind Bereiche, die bereits gleichwertig reguliert sind (etwa Medizinprodukte, Kraftfahrzeuge, Luftfahrt) sowie reine Dienstleistungen. Freie Open-Source-Software fällt nur dann darunter, wenn sie im Rahmen einer Geschäftstätigkeit bereitgestellt wird.

Der CRA teilt Produkte in drei Stufen ein. Die Standardstufe — der weitaus größte Teil — darf die Konformität selbst erklären (interne Kontrolle). Für „wichtige“ Produkte nach Anhang III (Klasse I und II) und „kritische“ nach Anhang IV gelten strengere Konformitätsbewertungsverfahren, teils mit Beteiligung einer benannten Stelle.

In Anhang III stehen unter anderem Betriebssysteme, Netzwerkmanagement, Firewalls, Passwortmanager, Mikrocontroller mit sicherheitsrelevanten Funktionen und industrielle Automatisierungs- und Steuerungssysteme (IACS) sowie industrielle IoT-Geräte.

Die Einordnung entscheidet, wie aufwendig Ihr Nachweisweg wird — und sie ist eine Auslegungsfrage am konkreten Produkt, keine Software-Ausgabe. Wer eine Steuerung oder ein IIoT-Gerät baut, sollte sie früh klären.

Der Unterstützungszeitraum ist die Zeitspanne, in der Sie Schwachstellen Ihres Produkts wirksam behandeln und Sicherheitsupdates bereitstellen müssen. Er soll der erwarteten Nutzungsdauer entsprechen und beträgt grundsätzlich mindestens fünf Jahre ab dem Inverkehrbringen.

Für langlebige Investitionsgüter ist das die eigentliche Zumutung: Eine Maschine, die zwölf Jahre im Feld steht, bindet Sie über den ganzen Zeitraum an die Pflege ihrer Softwarekomponenten — auch der zugekauften und der Open-Source-Bestandteile.

Der Zeitraum ist gegenüber Ihren Kunden anzugeben, und Sicherheitsupdates sind in ihm kostenlos und unverzüglich bereitzustellen. Nach seinem Ende endet die Update-Pflicht, nicht aber die Pflicht, das Ende klar kommuniziert zu haben.

Der CRA verlangt, Schwachstellen unverzüglich zu beheben — unter anderem durch Sicherheitsupdates, die im Unterstützungszeitraum kostenlos bereitzustellen sind. Sicherheitsupdates sollen getrennt von Funktionsupdates ausgeliefert werden können, damit ein Kunde die Sicherheitskorrektur einspielen kann, ohne einen Funktionssprung mitzunehmen.

Zu jedem Update gehört eine verständliche Information darüber, was behoben wurde und welche Handlung der Nutzer gegebenenfalls vornehmen muss. Wo Updates automatisch ausgeliefert werden, muss der Nutzer sie abschalten können.

Die Behebung selbst ist nicht delegierbar: Bibliothek aktualisieren, Release bauen, Update ausliefern bleibt Aufgabe Ihrer Entwicklung. Ein Dienstleister kann die Entscheidung und die Meldung vorbereiten, nicht den Patch.

Wer eine Komponente in sein Produkt integriert — zugekauft oder aus einem Open-Source-Projekt —, muss mit gebotener Sorgfalt prüfen, dass sie die Sicherheit des Produkts nicht gefährdet, und Schwachstellen in ihr genauso behandeln wie eigene.

Das ist der Punkt, an dem die Stückliste vom Papierdokument zum Arbeitsmittel wird: Ohne die Liste der enthaltenen Komponenten samt Version lässt sich weder prüfen noch belegen, dass Sie diese Sorgfalt walten lassen.

Findet ein Hersteller eine Schwachstelle in einer Komponente, muss er sie zudem der Person oder Organisation melden, die die Komponente pflegt — die Kette wirkt in beide Richtungen.

CVD steht für Coordinated Vulnerability Disclosure. Der CRA verlangt vom Hersteller eine Politik zur koordinierten Offenlegung von Schwachstellen und eine Kontaktadresse, unter der Sicherheitsforscher, Kunden oder Behörden eine Schwachstelle melden können.

Praktisch heißt das: eine erreichbare Adresse (etwa security@ihre-domain.de), eine kurze veröffentlichte Beschreibung, wie Sie mit Meldungen umgehen, und intern jemand, der eingehende Meldungen tatsächlich liest.

Diese Adresse ist häufig der Weg, auf dem Sie von einer Schwachstelle erfahren — und der Moment, in dem die Meldefristen zu laufen beginnen. Sie unbeaufsichtigt zu lassen, verschiebt das Problem nicht, sondern verkürzt Ihre Reaktionszeit.

Der CRA verlangt für jedes Produkt eine Cybersicherheits-Risikobewertung: Welche Bedrohungen bestehen für dieses Produkt in seiner bestimmungsgemäßen Verwendung und in vorhersehbarer Fehlanwendung, und welche der Anforderungen aus Anhang I folgen daraus?

Sie ist Teil der technischen Dokumentation, wird über den Lebenszyklus fortgeschrieben und begründet, warum Sie bestimmte Anforderungen umgesetzt und andere als nicht einschlägig eingestuft haben.

Für den Maschinen- und Sensorbau ist sie nah an einer Gefährdungsbeurteilung: dieselbe Denkweise, anderer Gegenstand — statt mechanischer Gefahren die Angriffsfläche der Software und der Schnittstellen.

Die technische Dokumentation nach Anhang VII enthält alles, was die Konformität des Produkts belegt: Produktbeschreibung, Risikobewertung, Angaben zur Entwicklung und Produktion, zum Schwachstellenmanagement einschließlich der Stückliste, zu Tests und zu den angewandten Normen.

Sie ist vor dem Inverkehrbringen zu erstellen, während des Unterstützungszeitraums aktuell zu halten und den Marktüberwachungsbehörden auf Verlangen vorzulegen — in der Regel zehn Jahre nach dem Inverkehrbringen oder für die Dauer des Unterstützungszeitraums, je nachdem, was länger ist.

Der Nachweis der laufenden Schwachstellenüberwachung gehört hier hinein. Genau deshalb dokumentiert Resilvance jede Prüfung — auch die ohne Fund.

Vor dem Inverkehrbringen muss ein Produkt ein Konformitätsbewertungsverfahren durchlaufen. Für die meisten Produkte genügt die interne Kontrolle (Modul A): Sie prüfen selbst gegen die Anforderungen aus Anhang I, dokumentieren das und erklären die Konformität in eigener Verantwortung.

Für wichtige Produkte der Klasse II und für kritische Produkte sind aufwendigere Verfahren vorgesehen, teils unter Einbeziehung einer benannten Stelle. Die Anwendung harmonisierter Normen verschafft dabei die Vermutung der Konformität.

Diese Pflicht greift vollständig ab dem 11.12.2027 — anders als die Meldepflichten, die bereits seit dem 11.09.2026 gelten.

Die EU-Konformitätserklärung ist das Dokument, mit dem Sie als Hersteller in eigener Verantwortung erklären, dass Ihr Produkt die Anforderungen des CRA erfüllt. Sie benennt Produkt, Hersteller, angewandte Rechtsvorschriften und Normen und wird mit dem Produkt bereitgestellt.

Aus dem Maschinenbau ist das Verfahren vertraut: Der CRA reiht sich in dieselbe Systematik ein wie Maschinen-, EMV- oder Niederspannungsrichtlinie — mit dem Unterschied, dass die zugrunde liegende Prüfung nie abgeschlossen ist, weil neue Schwachstellen laufend hinzukommen.

Die CE-Kennzeichnung ist keine Prüfplakette einer Behörde, sondern Ihre eigene Erklärung, dass das Produkt allen einschlägigen EU-Rechtsvorschriften entspricht. Ab dem 11.12.2027 gehört der Cyber Resilience Act zu diesen Vorschriften.

Für Produkte mit digitalen Elementen heißt das: Ohne erfüllte CRA-Anforderungen, Konformitätsbewertung und technische Dokumentation darf das Zeichen nicht angebracht werden — auch dann nicht, wenn alle mechanischen und elektrischen Anforderungen erfüllt sind.

Artikel 14 des CRA verpflichtet den Hersteller, zwei Arten von Ereignissen zu melden: eine aktiv ausgenutzte Schwachstelle in seinem Produkt und einen schwerwiegenden Sicherheitsvorfall, der die Sicherheit des Produkts beeinträchtigt.

Gemeldet wird in drei Stufen — Frühwarnung binnen 24 Stunden, Meldung binnen 72 Stunden, Abschlussbericht nach Verfügbarkeit einer Korrekturmaßnahme. Alle Fristen laufen ab Kenntnisnahme durch den Hersteller.

Empfänger sind das zuständige CSIRT und die ENISA, seit dem 11.09.2026 über eine gemeinsame Meldeplattform. Zusätzlich sind betroffene Nutzer unverzüglich zu informieren.

Ob ein meldepflichtiges Ereignis vorliegt, entscheidet der Hersteller — mit Begründung und Beleg. Keine Software trifft diese Entscheidung für Sie.

Die Fristen des CRA laufen ab Kenntnisnahme durch den Hersteller — nicht ab Veröffentlichung der Schwachstelle, nicht ab dem Zeitpunkt, an dem der zuständige Kollege aus dem Urlaub kommt, und nicht ab der internen Bestätigung.

Kenntnisnahme ist damit der kritischste Zeitpunkt des ganzen Verfahrens: Er entscheidet über den Fristbeginn, er muss dokumentiert sein, und er entsteht oft außerhalb der Entwicklung — im Support, in der Fernwartung oder an der Meldeadresse aus Ihrer Offenlegungspolitik.

Deshalb ist der erste organisatorische Schritt nicht ein Werkzeug, sondern eine benannte Person mit Vertretung, die eingehende Hinweise sieht und den Zeitpunkt festhält.

Die Frühwarnung ist die erste der drei Meldestufen: unverzüglich, in jedem Fall binnen 24 Stunden ab Kenntnisnahme. Sie ist bewusst knapp — bei einer aktiv ausgenutzten Schwachstelle genügt der Hinweis, dass eine solche vorliegt, und die Angabe der Mitgliedstaaten, in denen das Produkt bereitgestellt wurde.

Eine vollständige Analyse wird zu diesem Zeitpunkt nicht verlangt. Eine konservative Erstmeldung ist zulässig und in der Praxis oft der richtige Weg: Die Detailtiefe kommt in der 72-Stunden-Meldung und im Abschlussbericht nach.

Wer die 24 Stunden erst nach einer internen Klärungsrunde startet, hat sie meist schon verbraucht. Deshalb gehört der Ablauf — wer entscheidet, wer formuliert, wer reicht ein — vor den Ernstfall.

Der CRA knüpft die Meldepflicht nicht an jede Schwachstelle, sondern an die aktiv ausgenutzte: eine Schwachstelle, für die es einen belastbaren Nachweis gibt, dass sie von einem Angreifer in einem System ohne Erlaubnis des Eigentümers ausgenutzt wurde.

Der Unterschied ist erheblich. Ein Produkt kann Dutzende bekannter Schwachstellen enthalten, ohne dass eine einzige davon aktiv ausgenutzt wird — und genau diese wenigen lösen die 24-Stunden-Uhr aus.

Kataloge wie CISA KEV oder die europäische Schwachstellendatenbank der ENISA sind der praktische Eskalationsauslöser. Sie belegen die Ausnutzung, aber nicht, dass Ihr Produkt betroffen ist — das ist die nächste, eigene Prüfung.

Neben der aktiv ausgenutzten Schwachstelle löst ein schwerwiegender Sicherheitsvorfall die Meldepflicht aus: ein Ereignis, das die Sicherheit des Produkts beeinträchtigt und etwa zu einer Störung der Verfügbarkeit oder zum Zugriff auf sensible Daten führt oder führen kann.

Dieser Auslöser ist der unangenehmere, weil er nicht überwacht werden kann: Er kommt als Kundenanruf, als Beobachtung aus der Fernwartung oder als Meldung an Ihre Offenlegungsadresse — nicht aus einer Datenquelle, die man abfragen könnte.

Auch hier gilt: 24 Stunden bis zur Frühwarnung, 72 Stunden bis zur Meldung, danach der Abschlussbericht — spätestens einen Monat nach der 72-Stunden-Meldung.

Die Single Reporting Platform ist die von der ENISA betriebene gemeinsame Meldeplattform nach Artikel 16 des CRA. Über sie laufen die Meldungen an das zuständige CSIRT und die ENISA; sie ist seit dem Anwendungsbeginn der Meldepflichten am 11.09.2026 in Betrieb.

Praktisch bedeutet das: Eine Meldung wird von einem Menschen in ein Formular eingegeben. Eine offene Schnittstelle, über die ein Werkzeug automatisch melden könnte, gibt es nicht — und selbst wenn es sie gäbe, bliebe die Freigabe beim Hersteller.

Ein Dienstleister kann deshalb den Entwurf, die Fristenüberwachung und den Nachweis liefern, nicht aber die Einreichung.

SBOM steht für Software Bill of Materials — die Stückliste einer Software. Wie die Stückliste im Maschinenbau jedes Teil und jede Baugruppe mit Bezeichnung und Ausführung verzeichnet, listet sie alle Software-Bausteine (Bibliotheken) auf, die in einem Produkt stecken — jeweils mit Name und Version.

Der Cyber Resilience Act verlangt von Herstellern, eine solche Stückliste zu pflegen: Nur wer weiß, was im Produkt steckt, kann prüfen, ob bekannte Schwachstellen das eigene Produkt betreffen — so, wie Sie beim Rückruf eines Zulieferteils in der Stückliste nachsehen, ob es in Ihren Maschinen verbaut ist.

Von Hand schreiben müssen Sie die Liste nicht. Drei Wege führen dorthin: unser lokaler Scanner — eine Software, die Sie bei sich im Haus installieren; sie arbeitet komplett offline und lässt sich sogar hinter Ihrer Firewall abschotten, sodass garantiert keine Daten Ihr Unternehmen verlassen. Alternativ erzeugt Ihr Entwicklungsteam oder Ihr Software-Dienstleister die Liste mit gängigen Werkzeugen — oder Ihr Zulieferer liefert sie zur zugekauften Software gleich mit.

CVE steht für Common Vulnerabilities and Exposures. Jede öffentlich bekannte Schwachstelle erhält eine eindeutige Nummer im Format CVE-Jahr-Laufnummer, zum Beispiel CVE-2023-4863.

Dieselbe Schwachstelle kann zusätzlich unter anderen Kennungen geführt werden (z. B. GHSA-… bei GitHub oder PYSEC-… für Python-Pakete). Diese Auswertung führt solche Aliase zu einem Eintrag zusammen und zeigt bevorzugt die CVE-Nummer.

CVSS (Common Vulnerability Scoring System) bewertet den technischen Schweregrad einer Schwachstelle auf einer Skala von 0 bis 10 — üblich sind die Stufen niedrig, mittel, hoch und kritisch.

Der Wert beschreibt die Schwachstelle für sich genommen: wie leicht sie ausgenutzt werden kann und wie groß der Schaden im ungünstigsten Fall wäre. Er sagt nichts darüber, ob sie tatsächlich angegriffen wird und ob Ihr Produkt sie überhaupt erreichbar enthält.

Für die Meldepflicht ist deshalb nicht der CVSS-Wert maßgeblich, sondern die aktive Ausnutzung. Ein Fund mit hohem Score ohne Ausnutzungsnachweis ist ein Wartungsthema, kein Fristfall.

Eine purl (Package-URL) benennt ein Software-Paket eindeutig — mit Ökosystem, Name und Version. Beispiel: pkg:pypi/pillow@10.0.0 bezeichnet das Python-Paket „Pillow“ in Version 10.0.0.

Für den Schwachstellenabgleich ist die purl entscheidend: Nur mit ihr lässt sich eine Komponente zuverlässig in den Schwachstellendatenbanken nachschlagen. Komponenten ohne purl kann diese Auswertung deshalb nicht prüfen.

KEV steht für Known Exploited Vulnerabilities — ein Katalog der US-Cybersicherheitsbehörde CISA. Er listet ausschließlich Schwachstellen, für die Angriffe in der Praxis nachgewiesen sind.

Das ist ein wichtiger Unterschied: Für die meisten bekannten Schwachstellen ist kein aktiver Missbrauch dokumentiert. Steht eine Schwachstelle dagegen im KEV-Katalog, ist das Risiko real und die Prüfung eilt — deshalb stuft diese Auswertung solche Funde als „Dringend prüfen“ ein, wenn Ihr Produkt die betroffene Funktion nutzt.

Der KEV-Eintrag allein beantwortet nicht, ob Ihr konkretes Produkt betroffen ist oder eine Meldepflicht besteht — das bleibt Ihre Entscheidung.

OSV (Open Source Vulnerabilities) ist eine offene, maschinenlesbare Schwachstellendatenbank, betrieben von Google in Zusammenarbeit mit den Paket-Ökosystemen.

Diese Auswertung fragt OSV.dev live für jede Komponente Ihrer Stückliste ab — Grundlage sind Paketname, Version und purl.

CycloneDX ist ein offener Standard der OWASP für SBOM-Dateien. Gängige Werkzeuge (z. B. syft, trivy, cdxgen) erzeugen SBOMs in diesem Format.

Diese Demo liest CycloneDX im JSON-Format ab Version 1.4. Andere Formate wie SPDX werden noch nicht unterstützt — die meisten Werkzeuge können aber wahlweise CycloneDX exportieren.

Die Spalte „Nutzungsevidenz“ beantwortet für jede Komponente die Frage: Wie gut ist belegt, dass Ihr Produkt diese Bibliothek tatsächlich nutzt? Das ist für die Einordnung entscheidend — eine Schwachstelle in einer enthaltenen Bibliothek ist vor allem dann kritisch, wenn Ihr Produkt die verwundbare Funktion auch erreicht.

Angezeigt wird eine von vier Stufen, etwa „Stufe 2 · referenziert“. Je höher die Stufe, desto stärker der Nachweis:

Stufe 1 — vorhanden: Die Bibliothek ist Teil des Produkts, mehr ist nicht bekannt.

Stufe 2 — referenziert: Der Produktcode verweist auf eine Funktion der Bibliothek.

Stufe 3 — statisch erreichbar: Eine Code-Analyse findet einen möglichen Aufrufpfad zur Funktion.

Stufe 4 — zur Laufzeit beobachtet: Ein tatsächlicher Aufruf wurde gemessen.

Je höher die Stufe, desto wahrscheinlicher ist Ihr Produkt konkret betroffen. Die endgültige Bewertung bleibt eine fachliche Entscheidung.

„Nutzungsevidenz“ zeigt, ob Ihr Produkt eine Bibliothek überhaupt nutzt. „Erreichbarkeit“ geht einen Schritt weiter: Wird ausgerechnet die Funktion aufgerufen, in der die Schwachstelle steckt? Das schränkt viele Funde spürbar ein — die meisten Schwachstellen einer Bibliothek betreffen nur einzelne Funktionen, nicht die ganze Bibliothek.

Angezeigt wird einer von drei Zuständen:

„Aufruf nachgewiesen“ — die statische Analyse hat einen Aufrufpfad zur konkret verwundbaren Funktion gefunden.

„Aufruf nicht nachgewiesen“ — Ihr Produkt nutzt die Bibliothek, aber kein belegter Aufrufpfad erreicht die verwundbare Funktion. Das entwarnt NICHT: Statische Analyse übersieht dynamische Aufrufe, Reflection, Plugins oder Dependency Injection.

„Keine Funktionsdaten“ — zu dieser Schwachstelle liegen (noch) keine Angaben vor, welche Funktion konkret betroffen ist. Die Prüfung bleibt auf Bibliotheksebene.

Wichtig: Dieser Status verschärft eine Einordnung nur, er entschärft sie nie automatisch. Ein aktiv ausgenutzter Fund bleibt dringend zu prüfen, auch ohne nachgewiesenen Funktionsaufruf.

VEX steht für Vulnerability Exploitability eXchange — eine maschinenlesbare Aussage des Herstellers, ob und wie eine gefundene Schwachstelle sein konkretes Produkt betrifft. Typische Status: „betroffen“, „nicht betroffen“ (mit Begründung) oder „in Prüfung“.

VEX beantwortet die Frage, die ein reiner Schwachstellen-Scan offenlässt: Nicht jede Schwachstelle in einer enthaltenen Bibliothek betrifft das Produkt tatsächlich. Ein „nicht betroffen“ mit nachvollziehbarer Begründung erspart Abnehmern und Behörden unnötige Rückfragen.

Diese Auswertung leitet aus der Erreichbarkeitsanalyse einen Vorschlag ab und exportiert ihn im Format CycloneDX-VEX (JSON). Der Vorschlag ist ein Entwurf: Die Betroffenheit entscheidet immer der Hersteller, nie die Software — die Freigabe ist ein bewusster menschlicher Schritt.

Die ENISA ist die Agentur der Europäischen Union für Cybersicherheit. Im CRA erhält sie jede Meldung nach Artikel 14 parallel zum nationalen CSIRT, betreibt die gemeinsame Meldeplattform und führt die europäische Schwachstellendatenbank (EUVD).

Sie ist keine Aufsichtsbehörde für Ihr Unternehmen: Kontrolle und Sanktionen liegen bei den nationalen Marktüberwachungsbehörden.

CSIRT steht für Computer Security Incident Response Team. Jeder Mitgliedstaat benennt ein solches Team als Anlaufstelle; für Hersteller mit Sitz in Deutschland ist das BSI die zuständige Stelle.

Meldungen nach Artikel 14 gehen an das CSIRT des Mitgliedstaats mit der Hauptniederlassung und parallel an die ENISA. Das CSIRT kann Hinweise zur Eindämmung geben und informiert gegebenenfalls weitere betroffene Mitgliedstaaten.

Das Bundesamt für Sicherheit in der Informationstechnik ist das deutsche CSIRT und damit für Hersteller mit Hauptniederlassung in Deutschland die zuständige Stelle für Meldungen nach dem CRA.

Daneben veröffentlicht das BSI technische Richtlinien, die für die praktische Umsetzung einschlägig sind — insbesondere die TR-03183 zu Cyber-Resilienzanforderungen und zum Format der Software-Stückliste.

Die Marktüberwachungsbehörden der Mitgliedstaaten kontrollieren, ob in Verkehr gebrachte Produkte die Anforderungen des CRA erfüllen. Sie können technische Dokumentation anfordern, Prüfungen veranlassen, Produkte vom Markt nehmen lassen und Sanktionen verhängen.

Der CRA sieht für Verstöße gegen die wesentlichen Anforderungen Geldbußen von bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes vor, für Verstöße gegen andere Pflichten — darunter die Meldepflicht — bis zu 10 Millionen Euro oder 2 %.

Für die praktische Vorbereitung zählt weniger die Bußgeldhöhe als die Frage, was Sie im Anforderungsfall vorlegen können: technische Dokumentation, Stückliste und der Nachweis der laufenden Schwachstellenüberwachung.

NIS2 ist die EU-Richtlinie zur Cybersicherheit von Einrichtungen und Betreibern wesentlicher Dienste. Sie verpflichtet Organisationen, ihre eigenen Netz- und Informationssysteme abzusichern und Vorfälle zu melden.

Der CRA setzt an anderer Stelle an: Er verpflichtet Sie als Hersteller für das Produkt, das Sie in Verkehr bringen. Beide können nebeneinander gelten — etwa wenn ein Hersteller zugleich Betreiber kritischer Anlagen ist.

Die Meldewege überschneiden sich teilweise, die Auslöser nicht: NIS2 meldet den Vorfall im eigenen Betrieb, der CRA die ausgenutzte Schwachstelle oder den Vorfall im ausgelieferten Produkt.