CRA und NIS2 sind komplementäre EU-Cybersecurity-Regulierungen: Der CRA adressiert Hersteller digitaler Produkte, NIS2 die Betreiber kritischer Infrastruktur — mit erheblichen Überschneidungen bei Meldepflichten und Risikomanagement. Für die Einordnung CRA vs NIS2 ist deshalb die kürzeste Antwort: Sie müssen nicht zwischen beiden Regelwerken wählen, sondern zuerst klären, ob Ihr Unternehmen Produkte in Verkehr bringt, kritische oder wichtige Dienste betreibt oder beides zugleich tut.
Wer die Produktperspektive vertiefen will, sollte parallel unseren Überblick zum Cyber Resilience Act, die Detailseite zu CRA-Anforderungen und die Einordnung von CRA, NIS2 und AI Act lesen. Für den Aufsichts- und Sanktionsrahmen im KI-Kontext hilft außerdem das Glossar zu AI Act Enforcement.
CRA und NIS2 im Überblick — Zwei Seiten einer Medaille
CRA und NIS2 verfolgen dasselbe politische Ziel, aber auf unterschiedlichen Ebenen. Die EU-Verordnung 2024/2847 will Produkte mit digitalen Elementen sicherer machen, bevor und nachdem sie auf den EU-Markt kommen. Die NIS2-Richtlinie (EU) 2022/2555 will dagegen die Cybersicherheits- und Resilienzfähigkeit von Organisationen in besonders relevanten Sektoren erhöhen.
Der operative Unterschied ist deshalb klar. Der CRA fragt: Ist das Produkt sicher konzipiert, dokumentiert, supportet und meldet der Hersteller Schwachstellen sauber? NIS2 fragt: Beherrscht die Organisation ihre Cyberrisiken, meldet sie erhebliche Vorfälle rechtzeitig und steuert sie Lieferkette, Governance und Krisenreaktion belastbar?
Beide Regelwerke ergänzen sich. Ein Hersteller kann mit CRA-konformen Produkten arbeiten und trotzdem als NIS2-pflichtige Einrichtung zusätzliche Organisationspflichten tragen. Umgekehrt kann ein NIS2-pflichtiger Betreiber Produkte einkaufen, deren CRA-Konformität seine Lieferketten- und Produktsicherheitsrisiken reduziert, ohne die NIS2-Pflichten vollständig zu ersetzen.
Für deutsche Unternehmen ist noch ein Strukturpunkt wichtig: Der CRA gilt als Verordnung unmittelbar in allen Mitgliedstaaten. NIS2 ist eine Richtlinie und muss national umgesetzt werden. Die Europäische Kommission führt auf ihrer Deutschland-Seite mit letztem Update vom 7. Juli 2025 weiterhin den Status „failure to notify full transposition“ und nennt zugleich das BSI als Single Point of Contact und nationales CSIRT. Das ist für die Praxis relevant, weil NIS2-Meldewege immer über nationale Strukturen laufen, während der CRA ENISA ausdrücklich einbindet.
Vergleichstabelle: CRA vs. NIS2
Die wichtigste Entscheidungshilfe ist die Gegenüberstellung von Produkt- und Betreiberperspektive. Wenn Sie intern nur eine Tabelle weitergeben, dann diese:
| Vergleichspunkt | CRA | NIS2 |
|---|---|---|
| Scope | Produkte mit digitalen Elementen, die auf dem EU-Markt bereitgestellt werden | Wesentliche und wichtige Einrichtungen in 18 Sektoren sowie bestimmte digitale Dienste |
| Adressaten | Primär Hersteller, daneben Einführer und Händler | Betreiber beziehungsweise Einrichtungen, Management und verantwortliche Organisationseinheiten |
| Kernpflichten | Security by Design, Risikobewertung, technische Dokumentation, Schwachstellenmanagement, Sicherheitsupdates, Meldepflichten, Konformitätsbewertung | Cyberrisikomanagement, Incident Response, Business Continuity, Lieferkettensicherheit, Governance, Schulung, Meldepflichten |
| Fristen | In Kraft seit 10. Dezember 2024; Meldepflichten ab 11. September 2026; volle Anwendbarkeit ab 11. Dezember 2027 | Umsetzungsfrist der Richtlinie bis 17. Oktober 2024; Anwendung unionsrechtlich ab 18. Oktober 2024, praktisch aber abhängig von nationaler Umsetzung |
| Bußgelder | Bis 15 Mio. EUR oder 2,5 % des weltweiten Jahresumsatzes bei Verstößen gegen zentrale Sicherheitsanforderungen; weitere Pflichten bis 10 Mio. EUR oder 2 % | Mitgliedstaaten müssen für wesentliche Einrichtungen mindestens einen Höchstrahmen von 10 Mio. EUR oder 2 % und für wichtige Einrichtungen 7 Mio. EUR oder 1,4 % vorsehen |
| Meldepflichten | Hersteller melden aktiv ausgenutzte Schwachstellen und schwere Vorfälle an ENISA und den koordinierten CSIRT | Einrichtungen melden erhebliche Vorfälle an nationale Behörden oder nationale CSIRTs; ENISA wird über nationale Stellen eingebunden |
Die Tabelle zeigt bereits den Kern von CRA vs NIS2 Unterschiede: Der CRA reguliert die Sicherheit eines Produkts über seinen Lebenszyklus, NIS2 die Widerstandsfähigkeit einer Organisation im laufenden Betrieb.
Wer ist wovon betroffen — Hersteller vs. Betreiber
Die Betroffenheit entscheidet sich zuerst an Ihrer Rolle. Unter dem CRA sind Sie vor allem betroffen, wenn Ihr Unternehmen Produkte mit digitalen Elementen entwickelt, herstellen lässt, unter eigener Marke vertreibt oder in die EU importiert. Das umfasst nicht nur klassische IoT-Geräte, sondern auch Software, industrielle Steuerungen, eingebettete Systeme und viele vernetzte B2B-Produkte.
Unter NIS2 sind Sie betroffen, wenn Ihre Organisation in einen erfassten Sektor fällt und dort die jeweiligen Größen- und Relevanzschwellen erreicht oder ausdrücklich als wesentliche oder wichtige Einrichtung eingeordnet wird. Das betrifft beispielsweise Energie, Gesundheit, Verkehr, digitale Infrastruktur, öffentliche Verwaltung, Finanzmarktinfrastruktur, Managed Services oder bestimmte digitale Dienste.
Die praktische Faustregel lautet deshalb:
- Wenn Sie Software oder vernetzte Hardware verkaufen, prüfen Sie zuerst den CRA.
- Wenn Sie kritische oder wichtige Dienste betreiben, prüfen Sie zuerst NIS2.
- Wenn Sie beides tun, brauchen Sie eine Doppelperspektive.
Typische Überschneidungsfälle sind Industrieunternehmen mit eigener vernetzter Produktlinie, Softwareanbieter für kritische Sektoren, Hersteller medizinischer oder industrieller Systeme und digitale Dienstleister mit eigener Plattform plus reguliertem Betreiberstatus. Genau dort entstehen die meisten Missverständnisse, weil Technik-, Produkt-, Compliance- und Security-Teams unterschiedliche Regelungslogiken gewohnt sind.
Auch die Verantwortungsverteilung ist verschieden. Beim CRA trägt der Hersteller die Primärverantwortung für Konzeption, Support, Sicherheitsupdates und Marktbereitstellung. Bei NIS2 liegt der Fokus auf der Einrichtung selbst, ihrem Management und ihrer Fähigkeit, Risiken zu steuern, Vorfälle zu melden und die eigene Betriebsresilienz zu sichern. Deshalb ist der CRA eher produktrechtlich geprägt, NIS2 eher organisations- und governancebezogen.
Für die interne Abgrenzung hilft eine einfache Leitfrage je Fall. Fragen Sie beim CRA: „Bringen wir dieses digitale Produkt oder diese Software auf den Markt, tragen unsere Marke oder verantworten wir seine Konformität?“ Fragen Sie bei NIS2: „Betreiben wir einen kritischen oder wichtigen Dienst, dessen Ausfall erhebliche Folgen hätte, und fallen wir deshalb in den Kreis der regulierten Einrichtungen?“ Wenn Sie beide Fragen mit Ja beantworten, brauchen Sie keine Grundsatzdiskussion mehr, sondern ein abgestimmtes Doppelprogramm.
Wo sich CRA und NIS2 überschneiden
Die Überschneidung liegt nicht im Adressatenkreis, sondern in den Sicherheitsprozessen. Beide Regelwerke verlangen, dass Cyberrisiken nicht reaktiv, sondern systematisch beherrscht werden. Wenn Sie bereits ein belastbares Schwachstellenmanagement, klare Incident-Playbooks, Lieferkettenkontrollen und saubere Dokumentation haben, bauen Sie nicht zwei völlig getrennte Programme auf.
Die wichtigsten Schnittmengen sind:
- Risikomanagement: CRA verlangt produktspezifische Risikoanalysen und Sicherheitsmaßnahmen über den Lebenszyklus. NIS2 verlangt organisatorisches Cyberrisikomanagement nach dem Stand der Technik.
- Schwachstellenmanagement: Unter dem CRA ist Vulnerability Handling zentraler Teil der Herstellerpflichten. Unter NIS2 ist Schwachstellen- und Patchmanagement Bestandteil des Risikomanagements.
- Lieferkettensicherheit: Der CRA zwingt zur Sicht auf Komponenten, Abhängigkeiten und Updatefähigkeit. NIS2 adressiert Sicherheitsaspekte in der Supply Chain ausdrücklich auf Betreiberseite.
- Incident Response und Meldung: Beide Regelwerke verlangen klare Eskalationswege und enge Fristen.
- Nachweisfähigkeit: Ohne belastbare Dokumentation helfen weder gute Technik noch gute Absichten.
Genau hier entstehen Synergieeffekte. Ein Hersteller, der für CRA-Zwecke seine Komponenten sauber inventarisiert, Schwachstellen bewertet und Supportfenster dokumentiert, produziert bereits wertvolle Nachweise für NIS2-nahe Lieferketten-, Drittparteien- und Sicherheitsanforderungen. Ein Betreiber, der unter NIS2 seine Incident-Prozesse, Asset-Klassen und Kritikalitäten gut steuert, kann CRA-relevante Produkte schneller bewerten und integrieren.
Wer diese Schnittmenge systematisch aufbauen will, sollte auch den Vergleich DORA vs. NIS2 im Blick behalten. Dort wird besonders sichtbar, wie stark Meldewege, Governance und sektorspezifische Sonderregeln auseinanderlaufen können, obwohl die Kernbausteine ähnlich wirken.
Vermutungswirkung — NIS2-Compliance durch CRA-Konformität
Die wichtigste Klarstellung lautet: CRA-Konformität erzeugt keine pauschale NIS2-Compliance. Wer behauptet, ein CE-gekennzeichnetes oder CRA-konformes Produkt mache den Betreiber automatisch NIS2-konform, verkürzt die Rechtslage zu stark.
Warum ist das so? Weil beide Regelwerke andere Prüfobjekte haben. Der CRA prüft vor allem, ob das Produkt selbst Sicherheitsanforderungen erfüllt, dokumentiert ist und während seines Supportzeitraums angemessen betreut wird. NIS2 prüft dagegen, ob die Einrichtung als Ganzes ihre Risiken beherrscht. Dazu gehören Governance, Geschäftsleitungspflichten, Krisenmanagement, Schulung, organisatorische Zuständigkeiten und sektorspezifische Umsetzungsdetails auf nationaler Ebene.
Trotzdem gibt es eine faktische Vermutungswirkung im engeren Sinn. Wenn ein Betreiber CRA-konforme Produkte einsetzt, verbessert das regelmäßig seine Ausgangslage für NIS2-nahe Anforderungen an sichere Beschaffung, Lieferkette, Patch- und Schwachstellenmanagement. Anders formuliert: CRA-Konformität ist kein Ersatz für NIS2, aber oft ein starkes Indiz dafür, dass bestimmte produktsicherheitsbezogene Anforderungen bereits besser beherrscht werden.
Für die Praxis sollten Sie deshalb zwischen drei Ebenen unterscheiden:
- Keine Vollsubstitution: CRA ersetzt NIS2 nie vollständig.
- Teilweiser Nachweisvorteil: CRA-Unterlagen können NIS2-Prüfungen zu Lieferkette, technischem Risiko und Incident Handling erheblich erleichtern.
- Zusätzliche Pflichten bleiben bestehen: Managementverantwortung, Betriebsorganisation, nationale Meldewege und sektorale Zusatzanforderungen müssen unter NIS2 separat erfüllt werden.
Gerade in Ausschreibungen und Security-Fragebögen ist diese Unterscheidung wichtig. Betreiber sollten CRA-Konformität gezielt als Einkaufs- und Kontrollkriterium nutzen, aber nicht als pauschalen Freibrief dokumentieren. Hersteller wiederum sollten verstehen, dass gute CRA-Unterlagen ihren Kunden helfen, selbst NIS2-reifer zu werden. Das ist ein Vertriebs- und Compliance-Vorteil, aber kein juristischer Gleichlauf.
Praktisch heißt das auch: Ein Hersteller sollte seine CRA-Dokumentation so aufbereiten, dass Betreiber sie in ihre NIS2-Prüfungen übernehmen können. Dazu gehören nachvollziehbare Angaben zu Supportdauer, Updatepolitik, bekannten Einschränkungen, Disclosure-Prozessen, Kontaktwegen bei Sicherheitsmeldungen und zu den sicherheitsrelevanten Eigenschaften des Produkts. Je standardisierter diese Informationen vorliegen, desto eher entsteht in der Praxis eine verwertbare Vermutungswirkung auf operativer Ebene, obwohl rechtlich weiterhin getrennte Pflichten bestehen.
Meldepflichten im Vergleich — ENISA vs. nationale Behörden
Die Meldewege sind der sichtbarste Unterschied zwischen beiden Regimen. Unter dem CRA meldet der Hersteller aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle nicht nur an nationale Strukturen, sondern ausdrücklich an ENISA und den benannten koordinierenden CSIRT. Nach öffentlich zugänglichen CRA-Zusammenfassungen auf EUR-Lex beginnen diese Hersteller-Meldepflichten am 11. September 2026; für schwere Vorfälle gilt typischerweise eine Frühwarnung binnen 24 Stunden und eine Vorfallmeldung binnen 72 Stunden.
Unter NIS2 läuft die Meldekette anders. Einrichtungen melden erhebliche Vorfälle an die zuständige nationale Behörde oder an das nationale CSIRT. ENISA beschreibt die NIS2-Logik auf ihrer Seite zu Threats and Incidents ausdrücklich als mehrstufig: Frühwarnung binnen 24 Stunden, Incident Notification binnen 72 Stunden und Abschlussbericht nach einem Monat. ENISA ist hier wichtig, aber nicht der primäre erste Meldungsempfänger des betroffenen Unternehmens; die Einbindung läuft über Behörden- und Kooperationsstrukturen.
Für die Organisation bedeutet das drei konkrete Unterschiede:
- Empfänger: CRA direkt an ENISA plus koordinierten CSIRT; NIS2 primär an nationale Behörden oder nationale CSIRTs.
- Meldelogik: CRA ist produkt- und herstellerbezogen; NIS2 ist organisations- und betriebsbezogen.
- Informationsinhalt: CRA-Meldungen fokussieren stärker auf Schwachstellen, Produktbezug und Korrekturmaßnahmen; NIS2-Meldungen stärker auf Betriebsbeeinträchtigung, Auswirkung und Lagebild der Einrichtung.
Gerade internationale Unternehmensgruppen sollten diese Unterschiede nicht in einem einzigen Postfach versenken. Sinnvoll ist ein gemeinsamer Intake-Prozess mit klarer regulatorischer Weiche: Handelt es sich primär um eine Schwachstelle oder einen Sicherheitsvorfall eines Produkts mit digitalen Elementen? Dann CRA-Spur. Handelt es sich um einen erheblichen Vorfall mit Betriebs- oder Dienstwirkung auf eine NIS2-Einrichtung? Dann NIS2-Spur. In gemischten Fällen müssen beide Meldepfade parallel geprüft werden.
Beide gleichzeitig umsetzen — Synergie-Effekte nutzen
Die beste Umsetzungsstrategie ist ein gemeinsamer Cyber-Compliance-Baukasten mit getrennten Rechtsmappings. Unternehmen verlieren Zeit, wenn sie CRA und NIS2 in zwei vollständig getrennten Programmen aufsetzen, obwohl dieselben Teams oft an Risikoanalyse, Schwachstellenmanagement, Lieferkette und Incident Response arbeiten.
Ein pragmatischer Synergieansatz besteht aus sechs Schritten:
- Rollenlandkarte erstellen: Trennen Sie Hersteller-, Importeur-, Betreiber- und Dienstleisterrollen sauber.
- Asset- und Produktinventar verbinden: Verknüpfen Sie Produktportfolio, Betriebslandschaft und kritische Dienste.
- Einheitliches Schwachstellenmanagement etablieren: Eine zentrale Triage spart Doppelarbeit bei CRA und NIS2.
- Meldeprozesse mit Regulierungs-Triggern bauen: Ein Intake, zwei regulatorische Wege.
- Lieferkettenanforderungen harmonisieren: CRA-Unterlagen sollten in NIS2-Beschaffungs- und Drittparteiprozesse einfließen.
- Governance und Schulung trennen, Nachweise bündeln: Die Fachlogik bleibt getrennt, die Evidenzbasis möglichst einheitlich.
Besonders wirksam ist dieser Ansatz, wenn Sie CRA nicht isoliert von anderen Regulierungen betrachten. Für viele Unternehmen bildet der Beitrag zu CRA, NIS2 und AI Act die dritte relevante Ebene: Produktcybersicherheit, Betreiberresilienz und KI-spezifische Pflichten greifen zunehmend ineinander. Wer zusätzlich KI-Funktionen in vernetzten Produkten oder kritischen Diensten einsetzt, sollte außerdem die Schnittstelle zur Durchsetzung im Glossar zu AI Act Enforcement einordnen.
Auch Einkaufs- und Produktteams profitieren. Wenn Beschaffung künftig standardmäßig CRA-Nachweise, Supportfenster, Updateprozesse und Schwachstellenkommunikation abfragt, verbessert das nicht nur die Produktsecurity, sondern zugleich die Audit-Fähigkeit unter NIS2. Umgekehrt helfen NIS2-Kritikalitätsklassen dabei, CRA-relevante Produkte nach Business-Impact zu priorisieren.
Ein zusätzlicher Vorteil liegt in der Gremienarbeit. Wenn Geschäftsleitung, Produktverantwortliche, Einkauf, IT-Sicherheit und Compliance dieselben Kernbegriffe für Assets, Kritikalität, Meldewege und Lieferantenrisiken nutzen, sinkt der Abstimmungsaufwand deutlich. Genau das macht aus zwei parallelen Rechtsakten ein handhabbares Steuerungsmodell statt zweier konkurrierender Projekte.
Häufig gestellte Fragen (FAQ)
Muss ich CRA UND NIS2 erfüllen?
Ja, wenn Ihr Unternehmen sowohl in den persönlichen Anwendungsbereich des CRA als auch in denjenigen von NIS2 fällt. Das ist vor allem bei Herstellern digitaler Produkte mit eigener Betreiberrolle oder bei kritischen Dienstleistern mit eigener Produktentwicklung realistisch. Sie erfüllen dann nicht zweimal dasselbe, sondern zwei unterschiedliche Pflichtenpakete mit Überschneidungen.
Was ist der Hauptunterschied?
Der Hauptunterschied ist das Regelungsobjekt. Der CRA reguliert Produkte mit digitalen Elementen und ihre Sicherheit über den Lebenszyklus. NIS2 reguliert Organisationen, ihre Cyberresilienz und ihr Sicherheitsmanagement im laufenden Betrieb.
Gelten unterschiedliche Bußgelder?
Ja. Der CRA sieht unmittelbar unionsrechtliche Bußgeldrahmen vor, insbesondere bis 15 Mio. EUR oder 2,5 % des weltweiten Jahresumsatzes für Verstöße gegen zentrale Sicherheitsanforderungen. NIS2 verpflichtet die Mitgliedstaaten, nationale Sanktionen vorzusehen; für wesentliche Einrichtungen muss der Höchstrahmen mindestens 10 Mio. EUR oder 2 % betragen, für wichtige Einrichtungen mindestens 7 Mio. EUR oder 1,4 %.
Wie hängt der AI Act mit CRA und NIS2 zusammen?
Der AI Act ergänzt beide Regelwerke, ersetzt sie aber nicht. Wenn ein KI-System Teil eines Produkts mit digitalen Elementen ist, kann der CRA für die Produktsecurity relevant sein. Wenn dieselbe Lösung in einer NIS2-pflichtigen Einrichtung betrieben wird, kommt die Betreiber- und Resilienzsicht hinzu. Welche zusätzliche Ebene der AI Act eröffnet, erläutern wir in unserem Beitrag zu CRA, NIS2 und AI Act.
Gibt es gemeinsame Compliance-Maßnahmen?
Ja. Gemeinsame Maßnahmen sind vor allem Inventarisierung, Risikobewertung, Patch- und Schwachstellenmanagement, saubere Lieferkettenkontrollen, Incident Response, klare Verantwortlichkeiten, Management-Reporting und dokumentierte Nachweise. Genau deshalb sollten CRA und NIS2 organisatorisch verzahnt, aber rechtlich getrennt gemappt werden.
Fazit: CRA oder NIS2 ist fast immer die falsche Frage
Die belastbare Antwort auf CRA vs NIS2 lautet: Der CRA ist produktzentriert, NIS2 betreiberzentriert, und beide treffen sich bei Cyberhygiene, Meldepflichten und Lieferkette. Für Unternehmen ist deshalb nicht die Entweder-oder-Frage entscheidend, sondern die Rollenklärung.
Wenn Sie digitale Produkte entwickeln, vertreiben oder importieren, starten Sie mit dem Überblick zum Cyber Resilience Act und den CRA-Anforderungen. Wenn Sie parallel kritische oder wichtige Dienste betreiben oder die dritte Regulierungsebene mitdenken müssen, lesen Sie direkt weiter in CRA, NIS2 und AI Act und DORA vs. NIS2.
Wenn Ihr Team die Unterschiede zwischen Produktpflichten, Betreiberpflichten und KI-spezifischen Vorgaben sauber verstehen und intern dokumentierbar umsetzen soll, ist unsere EU-AI-Act-Schulung der nächste sinnvolle Schritt. Sie schafft einen gemeinsamen Mindeststandard für Management, Compliance und Fachbereiche und erleichtert damit die koordinierte Umsetzung angrenzender Regulierungen.