CRA × NIS2 × DORA × AI Act: die Konvergenz

Vier Rechtsakte, vier Objekte - kein Wortlaut ist wie der andere

Ein technologiegetriebenes Unternehmen kann mehreren EU-Cyber-Regulierungen zugleich unterliegen. So können der Cyber Resilience Act (CRA), NIS2, DORA und der AI Act gleichzeitig auf dasselbe Haus treffen - aber sie regeln unterschiedliche Dinge. Ein Denkfehler ist es, sie in einen Topf zu werfen. Es handelt sich um vier getrennte Rechtsakte mit vier verschiedenen Anknüpfungspunkten: der CRA reguliert das Produkt, NIS2 die Organisation als Betreiber, DORA die Resilienz des Finanzsektors und der AI Act das KI-System. Wer diese vier Objekte sauber auseinanderhält, versteht auch, warum sich die Pflichten überlappen, ohne sich zu ersetzen.

Der CRA (Verordnung (EU) 2024/2847) trat am 10.12.2024 in Kraft. Für Hersteller wird er in zwei Stufen scharf: die produktbezogene Melde- und Berichtspflicht (Art. 14) gilt seit dem 11.09.2026, die vollständige Anwendung aller Produktanforderungen ab dem 11.12.2027. Diese Fristen sind der Taktgeber, an dem sich eine koordinierte Umsetzung ausrichten lässt.

Wer ist von was betroffen - die Mehrfach-Regulierungs-Karte

Die folgende Übersicht ordnet die vier Rechtsakte schematisch zu. Sie ersetzt keine Einzelfallprüfung und stellt keine Rechtsberatung dar - die konkrete Betroffenheit hängt vom jeweiligen Produkt, Geschäftsmodell und der Rolle im Markt ab.

Wichtig: NIS2 ist eine Richtlinie und wird über nationales Recht (in Deutschland das NIS2-Umsetzungsgesetz) wirksam - CRA, DORA und AI Act sind unmittelbar geltende Verordnungen. Auch das ist ein Grund, sie nicht gleichzusetzen.

Wo die Regime sich überlappen - und wo nicht

Die Effizienzgewinne liegen genau in den Schnittmengen. Sie betreffen vor allem drei Bausteine: Risikobewertung, Lieferkette/SBOM und Vorfalls-/Schwachstellenmeldung.

• CRA ↔ NIS2: Ein Hersteller nach CRA kann zugleich eine NIS2-Einrichtung sein. Umgekehrt machen die NIS2-Lieferkettenpflichten die CRA-Konformität eingekaufter Produkte zu einem Beschaffungskriterium - die CE-gekennzeichnete Konformität wird zum Argument im Vertrieb.
• CRA ↔ DORA: IKT-Produkte, die ein Finanzunternehmen einsetzt, unterliegen als Produkt dem CRA, während DORA den Einsatz und das Drittparteirisiko in der Institution regelt. Ein CRA-konformes Produkt mit sauberer SBOM und dokumentiertem Support-Zeitraum erleichtert dem Abnehmer die DORA-Nachweisführung.
• CRA ↔ AI Act: Ein KI-Produkt kann beiden unterliegen - dem AI Act für das KI-Risiko, dem CRA für die Produkt-Cybersicherheit. Ist das KI-System ein Hochrisiko-System, verlangen beide eine dokumentierte Risikobewertung bzw. ein Risikomanagement; die Methoden (Threat-Modeling, Risikoklassifizierung) lassen sich gemeinsam aufsetzen.

Die stärkste operative Überlappung ist das Melde- und Reporting-Thema. CRA, NIS2 und DORA sehen jeweils gestufte Meldungen an Behörden vor, mit unterschiedlichen Fristen und Adressaten, aber vergleichbaren Prozessschritten. Wer den Prozess einmal baut, kann ihn über die Regime hinweg parametrisieren.

Die CRA-Melde-Kaskade - der Anker für den gemeinsamen Prozess

Weil die Meldepflicht die erste Herstellerpflicht des CRA ist, die bereits gilt (seit 11.09.2026), lohnt es sich, den Vorfallsprozess an ihr auszurichten. Der CRA (Art. 14) sieht bei aktiv ausgenutzten Schwachstellen und bei schwerwiegenden Sicherheitsvorfällen mit Auswirkung auf die Sicherheit des Produkts eine gestufte Meldung über die einheitliche Meldeplattform (Single Reporting Platform, SRP) vor, gleichzeitig an das als Koordinator benannte CSIRT und an die ENISA:

Falsch ist es, den Abschlussbericht pauschal mit „14 Tagen" anzusetzen. Korrekt ist die Unterscheidung: 14 Tage bei der Schwachstelle, ein Monat beim Vorfall. Auf Aufforderung des CSIRT kann zusätzlich ein Zwischenbericht fällig werden (Art. 14 Abs. 6). Die SRP richtet ENISA nach Art. 16 CRA ein; die internen Abläufe müssen so eingerichtet sein, dass die 24-/72-Stunden-Uhr eingehalten werden kann.

Ein durchgespieltes Beispiel: ein Mittelständler mit einem KI-gestützten Netzwerk-Sensor

Nehmen wir einen fiktiven Hersteller, der ein IDS-ähnliches Produkt mit einer KI-Anomalieerkennung vertreibt und selbst als mittelgroßer IT-Dienstleister arbeitet. Schematisch könnte sich folgendes Bild ergeben:

• CRA: Das Produkt fiele je nach Einordnung in die Kategorie „wichtiger" Produkte (Anhang III, z. B. IDS/IPS als Klasse II) - die technische Beschreibung dieser Kategorien richtet sich nach der Durchführungsverordnung (EU) 2025/2392. Für Klasse II wäre die interne Kontrolle (Modul A) ausgeschlossen; in Betracht kämen Modul B+C, Modul H oder, sofern verfügbar und anwendbar, ein europäisches Zertifizierungsschema mindestens der Stufe „mittel“ (Art. 32 Abs. 3). Aufzubauen wären eine SBOM (gängiges maschinenlesbares Format, zumindest mit den obersten Abhängigkeiten; die BSI TR-03183-2 nennt CycloneDX ≥ 1.6 oder SPDX ≥ 3.0.1), eine dokumentierte Risikobewertung, ein Schwachstellen-Handling über den Support-Zeitraum (mindestens fünf Jahre, kürzer nur bei kürzerer voraussichtlicher Nutzungsdauer, Art. 13 Abs. 8) und die technische Dokumentation nach Anhang VII, aufzubewahren mindestens zehn Jahre nach dem Inverkehrbringen oder für die Dauer des Unterstützungszeitraums, je nachdem, welcher Zeitraum länger ist.
• AI Act: Die KI-Komponente wäre nach Risikoklasse einzuordnen. Fiele sie unter die Hochrisiko-Systeme, ließe sich das dort verlangte Risikomanagement methodisch gemeinsam mit der CRA-Risikobewertung aufsetzen.
• NIS2: Als IT-Dienstleister könnte das Unternehmen selbst eine wichtige Einrichtung sein - mit Risikomanagement, Lieferkettenpflichten und einem organisationsweiten Vorfallsprozess, der den CRA-Produktprozess mitnutzt.

Der Hebel: SBOM, Risikobewertung, CVD-Policy und Vorfallsprozess werden einmal sauber gebaut und können dann in allen drei betroffenen Regimen als Grundlage dienen. Getrennte Silos pro Rechtsakt führen zu Doppelarbeit.

Bußgeldrahmen - nüchtern eingeordnet

Der CRA staffelt Sanktionen (Art. 64, jeweils der höhere Betrag): bis 15 Mio € / 2,5 % des weltweiten Jahresumsatzes bei Verstößen gegen die grundlegenden Anforderungen (Anhang I, Art. 13/14); bis 10 Mio € / 2 % bei sonstigen Pflichten; bis 5 Mio € / 1 % bei falschen Angaben gegenüber Behörden oder notifizierten Stellen. NIS2 und DORA kennen jeweils eigene Sanktionsrahmen. Art. 64 gehört nicht zu den vorgezogenen Vorschriften und gilt ab dem 11.12.2027 (Art. 71 Abs. 2); das deutsche Durchführungsgesetz (Bundestag-Drucksache 21/6134), das Behörde und Bußgeldverfahren regeln soll, ist zum 9. Oktober 2026 weder beschlossen noch verkündet. Die Zahlen sprechen für eine strukturierte Vorbereitung.

Was Blackfort tut

Blackfort Technology UG (haftungsbeschränkt) unterstützt Hersteller bei den CRA-Bausteinen, die auch in anderen Regelwerken gebraucht werden können: Risikobewertung je Produkt, SBOM-Kette, Strategie zur koordinierten Offenlegung und Meldeprozess nach Art. 14. Ob NIS2, DORA oder der AI Act für Ihr Unternehmen gelten, klären Sie mit Ihrer Rechtsabteilung oder Kanzlei.

Ein guter erster Schritt ist unser Betroffenheits-Check: Er ordnet schematisch ein, ob und wie der CRA Ihr Produkt erfasst. Kleine und mittlere Unternehmen finden im KMU-Bereich einen pragmatischen Einstieg, branchenspezifische Perspektiven im Branchen-Überblick. Wenn Sie die CRA-Nachweise so aufbauen möchten, dass Ihr Team sie in anderen Regelwerken wiederverwenden kann, sprechen Sie uns an: Kontakt aufnehmen.