CRA und NIS2: Unterschiede, Überschneidungen und getrennte Meldepflichten

CRA und NIS2 betreffen unterschiedliche Ebenen der Cybersicherheit. Der Cyber Resilience Act regelt Produkte mit digitalen Elementen und die Pflichten ihrer Wirtschaftsakteure. NIS2 richtet sich an bestimmte Einrichtungen und deren Netzwerk- und Informationssysteme. Ein Unternehmen kann beiden Regelwerken unterliegen, muss seine Betroffenheit aber getrennt prüfen.

Die praktische Konsequenz: Ein sicheres Produkt belegt nicht automatisch die Sicherheit des Unternehmensbetriebs. Umgekehrt ersetzt ein gutes Informationssicherheitsmanagement keine produktbezogene Risikobewertung, technische Dokumentation oder CRA-Konformitätsbewertung. Gemeinsame Prozesse sind sinnvoll, wenn sie die unterschiedlichen Rechtsgrundlagen erkennbar lassen.

Dieser Beitrag erklärt die Abgrenzung auf Ebene des EU-Rechts. Nationale NIS2-Umsetzung, sektorale Besonderheiten und konkrete Zuständigkeiten sind zusätzlich anhand des anwendbaren Rechts zu prüfen. Die Grundlagen des Cyber Resilience Act und die Herstellerpflichten bieten den produktbezogenen Ausgangspunkt.

Was ist der wichtigste Unterschied zwischen CRA und NIS2?

Der CRA stellt die Sicherheit eines vermarkteten Produkts über seinen Lebenszyklus in den Mittelpunkt. NIS2 stellt auf die Cybersicherheitsrisiken bestimmter Einrichtungen und ihrer Dienste ab. Deshalb unterscheiden sich Betroffenheit, Nachweise und Meldeanlässe.

Ein Hersteller entwickelt beispielsweise vernetzte Messgeräte. Beim CRA fragt er, welche Geräte und zugehörigen Softwarefunktionen in den Anwendungsbereich fallen, wie Risiken behandelt werden und welcher Supportzeitraum angemessen ist. Bei NIS2 fragt er gesondert, ob die Einrichtung nach Sektor, Größe oder besonderen Kriterien erfasst wird.

Ein Gerätehersteller kann klein genug sein, um außerhalb der üblichen größenbezogenen NIS2-Regel zu liegen, und trotzdem CRA-Pflichten für seine Produkte haben. Umgekehrt kann ein betroffener Dienstleister keine eigenen Produkte vermarkten und dennoch NIS2-Anforderungen an seinen Betrieb erfüllen müssen. Die Antwort auf eine dieser Fragen entscheidet die andere nicht.

Rechtsform und Regelungswirkung

Der CRA ist eine EU-Verordnung. NIS2 ist eine Richtlinie, die national umgesetzt wird. Für die praktische NIS2-Prüfung genügt deshalb der Richtlinientext nicht immer: Nationale Begriffe, Registrierungswege und Zuständigkeiten müssen berücksichtigt werden. Eine allgemeine Internetübersicht ersetzt diese Prüfung nicht.

Auch beim CRA sind praktische Ausführungsfragen relevant, etwa Produktkategorien, harmonisierte Normen und Meldewege. Daraus wird der CRA jedoch nicht zu einer organisationsbezogenen Zertifizierungspflicht für jedes Unternehmen. Der Bezug zum konkreten Produkt bleibt entscheidend.

Vergleich im Arbeitsalltag

Die Tabelle ist ein Einstieg in die Prüfung. Sie entscheidet keinen Grenzfall und bildet nicht jede sektorspezifische Regel ab. Für eine belastbare Zuordnung braucht das Unternehmen eine dokumentierte Entscheidung je Rechtsgrundlage.

Wie prüft ein Unternehmen seine doppelte Betroffenheit?

Das Unternehmen erstellt zwei getrennte Prüfungen: eine Produkt- und Rollenprüfung für den CRA sowie eine Einrichtungsprüfung für NIS2. Anschließend werden Überschneidungen in Prozessen und Risiken ermittelt. So bleiben Lücken und abweichende Verantwortlichkeiten sichtbar.

Für die CRA-Prüfung inventarisieren Sie verkaufte Hardware, Software und notwendige produktbezogene Backendfunktionen. Halten Sie fest, unter wessen Namen das Produkt vermarktet wird und welche juristische Person die jeweilige Rolle wahrnimmt. Bei Konzernen können Entwicklung, Vertrieb und Betrieb auf verschiedene Gesellschaften verteilt sein.

Für NIS2 werden die Tätigkeiten der Einrichtung, die einschlägigen Sektoren und die anwendbaren Größen- beziehungsweise Sonderkriterien erfasst. Umsatz und Beschäftigtenzahl dürfen nicht isoliert betrachtet werden, wenn verbundene Unternehmen oder spezielle Einstufungsregeln relevant sind. Die Prüfung wird mit ihrem Rechtsstand und den zugrunde gelegten Daten dokumentiert.

Beispiel eines Herstellers mit Cloudfunktion

Eine Gesellschaft verkauft industrielle Gateways und betreibt ein Backend, ohne das eine beworbene Steuerungsfunktion nicht nutzbar wäre. Die produktbezogene CRA-Prüfung muss die einschlägige Datenfernverarbeitung einbeziehen. Die bloße Auslagerung des Hostings entfernt diese Verantwortung nicht.

Separat ist zu prüfen, ob die Gesellschaft mit ihren Tätigkeiten eine unter NIS2 erfasste Einrichtung ist. Ein Backend macht nicht jedes Unternehmen automatisch zum NIS2-Cloudanbieter. Produktfunktion, Dienstangebot, rechtliche Definitionen und nationales Recht müssen zusammen betrachtet werden.

Der Beitrag zur CRA-Datenfernverarbeitung erklärt die Produktgrenze. Die NIS2-Zuordnung bleibt eine zusätzliche Prüfung. Eine gemeinsame Architekturzeichnung kann beide Prüfungen unterstützen, sollte aber die verschiedenen Grenzen ausdrücklich markieren.

Entscheidung und Überprüfung organisieren

Hinterlegen Sie eine kurze Entscheidungsvorlage: betrachtete Einheit oder Produktfamilie, relevante Tatsachen, Rechtsgrundlage, Ergebnis, Verantwortlicher und Anlass zur erneuten Prüfung. Auslöser sind etwa ein neues Geschäftsmodell, eine Übernahme, eine geänderte Produktfunktion oder eine wesentliche Änderung der Unternehmensgröße.

Eine einmalige Aussage „NIS2 betrifft uns nicht“ ist ohne Datum und Begründung schlecht wartbar. Dasselbe gilt für „alle Produkte CRA-konform“. Verantwortliche müssen erkennen können, auf welche konkrete Konfiguration und welchen Prüfstand sich die Aussage bezieht.

Welche Sicherheitsprozesse können CRA und NIS2 gemeinsam nutzen?

Gemeinsam nutzbar sind beispielsweise Inventare, Schwachstelleninformationen, Vorfallkoordination und Lieferantenprüfungen. Die Nachweise müssen dennoch auf Produkt- oder Einrichtungsrisiken zurückführbar bleiben. Ein gemeinsamer Prozess funktioniert nur, wenn Zuständigkeit und Prüfkriterien nicht vermischt werden.

Ein Unternehmen kann etwa eine zentrale Meldestelle für Sicherheitsbefunde betreiben. Diese nimmt Hinweise entgegen und verteilt sie an Betriebssicherheit und Produktsicherheit. Die anschließende Bewertung unterscheidet jedoch, ob ein verwundbares internes System, ein vermarktetes Produkt oder beides betroffen ist.

Inventar und Software-Stückliste verbinden

Ein Betriebsinventar beschreibt installierte Systeme und ihre Verantwortlichen. Eine produktbezogene Software-Stückliste beschreibt Komponenten eines bestimmten Produktstands. Beide können dieselbe Bibliothek enthalten, benötigen aber unterschiedliche Kontextinformationen.

Für den Betrieb ist wichtig, wo die Bibliothek tatsächlich eingesetzt wird und welcher Dienst ausfallen könnte. Für den Hersteller ist wichtig, welche ausgelieferten Versionen sie enthalten, ob der verwundbare Code erreichbar ist und wie Nutzer eine Korrektur erhalten. Eine einzige Liste ohne diese Zuordnung hilft bei einem dringenden Hinweis wenig.

Gemeinsame Komponentendaten können deshalb in einer zentralen Datenbasis gepflegt werden. Verknüpfen Sie sie mit Produktversionen und betriebenen Instanzen. Vermeiden Sie eine Kopie in vielen Tabellen, deren Aktualität niemand verantwortet. Ein sauberer Bezug spart Zeit, ohne die beiden Prüfzwecke gleichzusetzen.

Lieferketten und Zugänge koordinieren

Ein externer Entwickler kann zugleich Zugang zum Quellcode und zu produktiven Systemen haben. Die Lieferantenprüfung muss beide Risiken erfassen. Vertragliche Pflichten zur Schwachstelleninformation, sichere Entwicklungsprozesse und Zugriffsbegrenzungen ergänzen einander.

Ein Lieferantenzertifikat ersetzt nicht die Prüfung des konkret verwendeten Bauteils. Ebenso belegt ein sicherer Firmwarestand nicht, dass ein Servicekonto im Unternehmensnetz angemessen abgesichert ist. Gemeinsame Evidenz ist nutzbar, wenn ihre Reichweite ausdrücklich benannt wird.

Für kleine Teams ist diese Verbindung besonders hilfreich. Eine zentrale Kontaktliste, ein gemeinsamer Eskalationskanal und ein einheitlicher Beweisstandard reduzieren organisatorische Doppelarbeit. Produktbezogene Freigaben und betriebliche Risikofreigaben bleiben trotzdem unterscheidbar.

Wann können getrennte Meldepflichten entstehen?

Getrennte Meldepflichten können entstehen, wenn ein Sachverhalt sowohl einen CRA-Meldeanlass als auch einen NIS2-Meldeanlass erfüllt. Das muss für jede betroffene juristische Person und Rechtsgrundlage geprüft werden. Eine Meldung in einem System gilt nicht ohne gesicherte rechtliche Grundlage automatisch als Erfüllung aller anderen Pflichten.

Ein Beispiel: Ein Hersteller stellt eine aktiv ausgenutzte Schwachstelle in seinem Gateway fest. Gleichzeitig nutzt eine NIS2-betroffene Einrichtung dieses Gerät und erleidet dadurch einen erheblichen Ausfall ihres Dienstes. Der Hersteller prüft seine CRA-Meldung; die Einrichtung prüft ihre eigenen NIS2-Pflichten. Beide Akteure benötigen Informationen voneinander, tragen aber nicht dieselbe Verantwortung.

Ein weiterer Fall betrifft einen kompromittierten Herstellerbetrieb. Wenn der Angriff nur die interne Zeiterfassung betrifft, ist daraus noch kein CRA-Produktsicherheitsvorfall abzuleiten. Werden hingegen Updatepakete manipuliert, ist die Produktsicherheitswirkung gesondert zu untersuchen. Dieselbe technische Infrastruktur kann unterschiedliche rechtliche Folgen haben.

Fristen nicht aus Gewohnheit übernehmen

Bei CRA und NIS2 gibt es gestufte Meldungen, darunter frühe Warnungen und weitere Meldungen. Die bekannten Zahlen 24 und 72 Stunden dürfen nicht dazu verleiten, Inhalte, Adressaten oder Abschlussfristen gleichzusetzen. Die Fristberechnung gehört jeweils zur konkreten Rechtsgrundlage.

Für die CRA-Meldung aktiv ausgenutzter Schwachstellen unterscheidet sich der Abschlussbericht von demjenigen für schwerwiegende Vorfälle. Bei NIS2 sind die einschlägigen nationalen und gegebenenfalls sektorspezifischen Anforderungen zu prüfen. Ein gemeinsamer Kalender führt deshalb eigene Einträge statt einer einzigen pauschalen „Cyberfrist“.

Die CRA-Meldepflichten sollten im internen Ablauf mit einem eigenständigen Entscheidungspfad hinterlegt werden. Daneben steht der Pfad für Betriebs- und Einrichtungsereignisse. Weitere Pflichten, beispielsweise zum Datenschutz, werden bei Bedarf gesondert ergänzt.

Informationen abgestimmt weitergeben

Ein gemeinsames Lagebild verhindert widersprüchliche Angaben. Es enthält gesicherte Tatsachen, betroffene Versionen oder Dienste, Auswirkungen und verfügbare Maßnahmen. Aus diesem Lagebild werden die jeweils erforderlichen Meldungen abgeleitet.

Beschränken Sie Informationen auf den notwendigen Umfang. Ein betroffener Betreiber benötigt insbesondere umsetzbare Schutzmaßnahmen und eine Aussage zur Produktversion. Vollständige Hersteller-Forensik mit fremden Kundendaten gehört nicht automatisch in seine Meldung. Die Zusammenarbeit muss Vertraulichkeit und sicheren Austausch berücksichtigen.

Wer trägt welche Verantwortung im Unternehmen?

Die Produktsicherheitsfunktion verantwortet den produktbezogenen Sachstand, die Betriebssicherheit den Zustand der eigenen Systeme. Compliance oder Rechtsfunktion prüft die rechtlichen Zuordnungen; die zuständige Leitung stellt Ressourcen und Entscheidungsfähigkeit sicher. Eine zentrale Fallleitung koordiniert gemeinsame Vorfälle.

Diese Aufgaben müssen keine getrennten Abteilungen sein. In einem kleineren Herstellerteam kann eine Person technische Befunde sammeln und zugleich den Betrieb betreuen. Wichtig sind dann eine zweite prüfende Person und eindeutige Freigaberegeln. Sonst entscheidet dieselbe Person unter Zeitdruck über alle Risiken ohne erkennbare Kontrolle.

Eine sinnvolle Zuständigkeitsmatrix beginnt mit konkreten Ergebnissen: Produktinventar, Einrichtungsprüfung, technischer Befund, Meldeentscheidung, abgesendete Meldung, Nutzerinformation und Maßnahmenkontrolle. Für jedes Ergebnis gibt es einen Verantwortlichen und eine Vertretung. Allgemeine Rollenbezeichnungen allein reichen nicht.

Die CRA-Rollen und Pflichten helfen, Hersteller, Importeur, Händler und Bevollmächtigten auseinanderzuhalten. Diese Rollen sind nicht mit NIS2-Funktionen oder dem Betreiber einer Installation identisch. Besonders bei Eigenmarken und ausgelagerter Entwicklung muss der Name auf dem Produkt mit der Verantwortungszuordnung übereinstimmen.

Drei unterschiedliche Verantwortliche in einem Fall

Ein Hersteller kann ein Gateway vermarkten, ein Dienstleister dessen Fernzugang betreiben und eine Einrichtung das Gerät in einem wichtigen Dienst verwenden. Ein Sicherheitsfall kann alle drei Akteure betreffen. Die gemeinsame technische Ursache macht ihre Pflichten jedoch nicht identisch.

Der Hersteller braucht den Bezug zu Produktversionen und Sicherheitsmaßnahmen. Der Dienstleister prüft seinen Betrieb und seine Zugangsverwaltung. Die Einrichtung bewertet die Wirkung auf ihre Dienste und ihre einschlägigen Meldepflichten. Ein gemeinsamer Ansprechpartner kann die Zusammenarbeit vereinfachen, sollte aber die Entscheidungen nicht undifferenziert für alle Beteiligten übernehmen.

Legen Sie bereits vertraglich einen sicheren Informationsweg fest. Welche Versions- und Ereignisdaten können kurzfristig ausgetauscht werden? Wer bestätigt eine Maßnahme? Welche Angaben sind vertraulich? Diese Vereinbarungen verbessern die Reaktion, ohne gesetzliche Pflichten auf einen anderen Akteur zu verschieben.

Aussagen zur Konformität präzise halten

Eine Beschaffungsanforderung wie „CRA- und NIS2-zertifiziert“ kann unklar oder sachlich unzutreffend sein. Fordern Sie konkrete Nachweise für das Produkt beziehungsweise die Einrichtung an. Beim Produkt können dies der einschlägige Konformitätsnachweis und Sicherheitsinformationen sein; beim Dienstleister nachvollziehbare organisatorische und technische Kontrollen.

Prüfen Sie die Reichweite jedes Dokuments. Ein Zertifikat für einen Standort muss nicht alle angebotenen Dienste abdecken. Ein Produktnachweis muss nicht jede nachträglich veränderte Konfiguration erfassen. So werden Dokumente als Belege für konkrete Aussagen genutzt, statt als austauschbare Sicherheitsversprechen.

Wie verhindert man doppelte Arbeit und blinde Flecken?

Doppelte Arbeit lässt sich durch gemeinsame Daten und koordinierte Abläufe verringern. Blinde Flecken verhindert eine getrennte rechtliche Bewertung mit klarer Rückverfolgbarkeit. Das Ziel ist ein gemeinsamer Sachstand mit nachvollziehbaren Pflichten je Regelwerk.

Beginnen Sie mit einer gemeinsamen Fallübung. Ein Lieferantenhinweis betrifft eine Bibliothek sowohl in einem verkauften Gerät als auch in einem internen Dienst. Das Team soll betroffene Produktversionen und Betriebsinstanzen ermitteln, beide Risiken bewerten und die erforderlichen Kommunikationswege festlegen. Diese Übung zeigt schnell, ob Inventare miteinander verbunden sind.

Kontrollieren Sie anschließend die Nachweise. Ist erkennbar, welche Kontrollen den Unternehmensbetrieb schützen und welche Eigenschaften das Produkt absichern? Sind Supportzeitraum und Updateweg berücksichtigt? Gibt es eine gesonderte Prüfung der NIS2-Einrichtung und der CRA-Herstellerrolle?

Ein gutes Ergebnis ist keine Sammlung möglichst vieler Zertifikate. Es ist eine belastbare Zuordnung von Risiken, Maßnahmen und Verantwortlichkeiten. Gemeinsame Prozesse sparen Aufwand, wenn sie diese Zuordnung erhalten. Werden CRA und NIS2 dagegen als austauschbare Etiketten verwendet, bleiben gerade die wichtigen Unterschiede unbearbeitet.

Quelle und fachlicher Prüfstand: Europäische Kommission: NIS2-Richtlinie und ihr Regelungsrahmen. Zusätzlich fachlich berücksichtigt: Cyber Resilience Act, Verordnung (EU) 2024/2847. Quellen geprüft am 4. Oktober 2026. Redaktion: Jörn Poppenhäger.