Wie unterscheiden sich CRA, NIS2 und DORA?

TL;DR

• Der Cyber Resilience Act (CRA, Verordnung (EU) 2024/2847) regelt Produktsicherheit: Hersteller, Importeure und Händler von Produkten mit digitalen Elementen.
• NIS2 regelt Organisationssicherheit für Betreiber wesentlicher und wichtiger Einrichtungen (z. B. Energie, Gesundheit, digitale Infrastruktur).
• DORA regelt IKT-Resilienz speziell für den Finanzsektor (Banken, Versicherer, Zahlungsdienstleister).
• Ein Unternehmen kann gleichzeitig unter mehrere Regelwerke fallen, etwa wenn ein NIS2-pflichtiger Betreiber auch CRA-pflichtige Produkte herstellt oder einsetzt.
• Die drei Verordnungen/Richtlinien haben unterschiedliche Meldefristen und Aufsichtsbehörden, die im Ernstfall parallel bedient werden müssen.

Was regelt der Cyber Resilience Act konkret?

Der CRA ist seit dem 10.12.2024 in Kraft und adressiert die Sicherheit von Produkten mit digitalen Elementen, also Hardware und Software, die auf den EU-Markt gebracht werden. Die Verordnung setzt an der Inverkehrbringung an: Hersteller tragen die Hauptlast der Pflichten, Importeure und Händler haben abgestufte Kontroll- und Weitergabepflichten entlang der Lieferkette. Ab dem 11.12.2027 gelten die Hauptpflichten vollständig, darunter grundlegende Cybersicherheitsanforderungen, Konformitätsbewertung, CE-Kennzeichnung, technische Dokumentation sowie Schwachstellen-Handling über den gesamten Support-Zeitraum des Produkts. Bereits ab dem 11.09.2026 greifen die Meldepflichten nach Art. 14 CRA für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle.

Was regelt NIS2 im Unterschied dazu?

NIS2 setzt nicht am Produkt, sondern an der Organisation an. Wesentliche und wichtige Einrichtungen, etwa aus den Sektoren Energie, Gesundheit, Verkehr oder digitale Infrastruktur, müssen Risikomanagementmaßnahmen für ihre Netz- und Informationssysteme umsetzen und Sicherheitsvorfälle an die zuständige nationale Behörde melden. Der Fokus liegt auf dem Betrieb: Wie sicher sind die IT-Systeme, Prozesse und Lieferketten einer Einrichtung, unabhängig davon, ob sie selbst Produkte herstellt.

Was regelt DORA und für wen gilt es?

DORA (Digital Operational Resilience Act) ist sektorspezifisch und gilt für den Finanzsektor: Banken, Versicherungen, Zahlungsdienstleister, Wertpapierfirmen und weitere beaufsichtigte Finanzunternehmen. Der Regelungsgegenstand ist die digitale operationale Resilienz, also IKT-Risikomanagement, Vorfallmeldung, Tests der digitalen Widerstandsfähigkeit und die Überwachung kritischer IKT-Drittdienstleister. DORA ist damit lex specialis gegenüber NIS2 für den Finanzsektor: Wo DORA anwendbar ist, tritt es an die Stelle der NIS2-Anforderungen für die betroffenen Finanzunternehmen.

Die zentrale Abgrenzung in einer Tabelle

Kriterium	CRA	NIS2	DORA
Regelungsgegenstand	Produktsicherheit	Organisationssicherheit	IKT-Resilienz Finanzsektor
Adressaten	Hersteller, Importeure, Händler	Wesentliche/wichtige Einrichtungen	Finanzunternehmen, IKT-Drittdienstleister
Ansatzpunkt	Inverkehrbringen des Produkts	Betrieb der Netz- und Informationssysteme	Betrieb + Auslagerung von IKT-Diensten
Wesentliche Fristen	11.09.2026 (Meldepflichten), 11.12.2027 (Hauptpflichten)	national umgesetzt, Meldefristen je Vorfallart	national umgesetzt, Meldefristen je Vorfallart

Wo überschneiden sich die Pflichten in der Praxis?

Überschneidungen entstehen vor allem dort, wo ein Unternehmen mehrere Rollen gleichzeitig einnimmt. Ein typisches Beispiel: Ein Unternehmen ist als Betreiber kritischer Infrastruktur NIS2-pflichtig und stellt gleichzeitig Produkte mit digitalen Elementen her oder bringt sie in Verkehr, die unter den CRA fallen. In diesem Fall bestehen Pflichten aus beiden Regelwerken parallel: die organisatorischen Anforderungen aus NIS2 für den eigenen Betrieb und die produktbezogenen Anforderungen aus dem CRA für die hergestellten oder vertriebenen Produkte. Für Finanzunternehmen, die zugleich CRA-pflichtige Software oder Hardware einsetzen oder entwickeln, gilt entsprechend: DORA regelt die Resilienz des eigenen IKT-Betriebs, der CRA regelt die Sicherheit der eingesetzten oder hergestellten Produkte selbst.

Wie sollte die Betroffenheitsprüfung ablaufen?

Eine strukturierte Prüfung unterscheidet zunächst zwischen der Rolle des Unternehmens (Hersteller/Importeur/Händler eines Produkts, Betreiber einer Einrichtung, Finanzunternehmen) und dem jeweiligen Regelwerk, das an diese Rolle anknüpft. Da die drei Rechtsakte unterschiedliche Meldeplattformen, Fristen und Aufsichtsbehörden vorsehen, ist es sinnvoll, die Meldeprozesse getrennt zu dokumentieren, auch wenn ein einzelner Vorfall theoretisch mehrere Meldepflichten gleichzeitig auslösen kann.

In der Praxis empfiehlt sich eine tabellarische Erfassung aller Produkte, Systeme und Dienstleistungen des Unternehmens mit jeweiliger Zuordnung: Fällt das Produkt unter den CRA, weil es digitale Elemente enthält und auf den EU-Markt gebracht wird? Ist die Organisation als wesentliche oder wichtige Einrichtung im Sinne von NIS2 einzustufen? Handelt es sich um ein Finanzunternehmen oder einen IKT-Drittdienstleister im Anwendungsbereich von DORA? Diese Zuordnung ist keine einmalige Übung, sondern sollte bei jeder neuen Produkteinführung, jeder Sektorveränderung und jeder wesentlichen Änderung der Unternehmensstruktur wiederholt werden, da sich die Einordnung ändern kann.

Kann ein Unternehmen gleichzeitig CRA- und NIS2-pflichtig sein?

Ja. Die Pflichten knüpfen an unterschiedliche Kriterien an, Produkteigenschaft beim CRA, Sektorzugehörigkeit und Einrichtungsgröße bei NIS2. Ein Unternehmen kann beide Kriterien gleichzeitig erfüllen und ist dann beiden Regelwerken unterworfen.

Ersetzt DORA die NIS2-Pflichten für Finanzunternehmen vollständig?

Für die von DORA erfassten Finanzunternehmen und den dort geregelten Bereich gilt DORA als sektorspezifische Regelung vorrangig gegenüber NIS2. Im Einzelfall ist zu prüfen, welche Aktivitäten eines Unternehmens tatsächlich unter DORA fallen.

Welche Konsequenzen hat die Mehrfachbetroffenheit für die interne Organisation?

Unternehmen, die gleichzeitig unter mehrere Regelwerke fallen, stehen vor der Aufgabe, unterschiedliche Governance-Strukturen aufeinander abzustimmen, ohne sie zu vermischen. Ein NIS2-Risikomanagementprozess für den eigenen Betrieb ersetzt nicht die produktbezogenen Konformitätsbewertungen nach CRA, und umgekehrt deckt eine CRA-Konformitätsbewertung eines Produkts nicht die organisatorischen Anforderungen an die eigene IT-Sicherheit ab, die NIS2 oder DORA verlangen. Üblicherweise wird empfohlen, für jedes Regelwerk eine eigene Verantwortlichkeit im Unternehmen zu benennen, auch wenn sich die operativen Maßnahmen an manchen Stellen überschneiden, etwa bei der Dokumentation von Schwachstellen oder bei der technischen Absicherung von Systemen.

Praktischer Ausgangspunkt für die eigene Einordnung

Für eine erste Orientierung, ob und in welchem Umfang der CRA für die eigenen Produkte greift, bietet sich eine strukturierte Betroffenheitsprüfung an. Der CRA-Betroffenheitscheck führt durch die relevanten Kriterien und ordnet ein, ob ein Produkt unter den CRA fällt. Einen Überblick über die CRA-Fristen und Pflichten insgesamt bietet der Grundlagenartikel Cyber Resilience Act im Überblick. Wer die Schnittstelle zu NIS2 und DORA im Bankensektor vertiefen möchte, findet weiterführende Einordnung im Artikel NIS2 und DORA: Überschneidung für Banken-IT.

Quellen

• Europäische Kommission, Cyber Resilience Act (Übersicht): https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act (verifiziert: 11.08.2026)
• Europäische Kommission, CRA Reporting Obligations: https://digital-strategy.ec.europa.eu/en/policies/cra-reporting (verifiziert: 11.08.2026)
• EUR-Lex, Verordnung (EU) 2024/2847: https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32024R2847 (verifiziert: 11.08.2026)
• ENISA, Cyber Resilience Act: https://www.enisa.europa.eu/topics/cyber-resilience-act (verifiziert: 11.08.2026)