CRA × NIS2 × DORA × AI Act: die Konvergenz

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

Kaum ein technologiegetriebenes Unternehmen unterliegt heute nur noch einer einzigen EU-Cyber-Regulierung. In der Praxis treffen der Cyber Resilience Act (CRA), NIS2, DORA und der AI Act oft gleichzeitig auf dasselbe Haus — aber sie regeln unterschiedliche Dinge. Der häufigste Denkfehler ist, 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 ab 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 fast immer dieselben drei Bausteine: Risikobewertung, Lieferkette/SBOM und Vorfalls-/Schwachstellenmeldung.

• CRA ↔ NIS2: Ein Hersteller nach CRA ist häufig zugleich eine NIS2-Einrichtung. 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. Beide verlangen eine dokumentierte Risikobewertung; die Methoden (Threat-Modeling, Risikoklassifizierung) lassen sich gemeinsam aufsetzen.

Die stärkste operative Überlappung ist das Melde- und Reporting-Thema. CRA, NIS2 und DORA verlangen jeweils Frühwarnung, Zwischen- und Abschlussberichte an Behörden — 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 CRA-Meldepflicht als erste hart wird (11.09.2026), lohnt es sich, den Vorfallsprozess an ihr auszurichten. Der CRA (Art. 14) sieht bei aktiv ausgenutzten Schwachstellen und schweren Sicherheitsvorfällen eine gestufte Meldung über die ENISA Single Reporting Platform (SRP) an das zuständige CSIRT und ENISA vor:

Ein verbreiteter Fehler ist, den Abschlussbericht pauschal mit „14 Tagen" anzusetzen. Korrekt ist die Unterscheidung: 14 Tage bei der Schwachstelle, ein Monat beim Vorfall. Die SRP soll zum 11.09.2026 bereitstehen; bis dahin sind die internen Abläufe so einzurichten, 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 regelmäßig eine notifizierte Stelle einzubinden. Es wären eine SBOM (maschinenlesbar, CycloneDX ≥ 1.6 oder SPDX ≥ 3.0.1 gemäß BSI TR-03183-2), eine dokumentierte Risikobewertung, ein Schwachstellen-Handling über den Support-Zeitraum (Richtwert mind. 5 Jahre) und die technische Dokumentation nach Anhang VII aufzubauen — 10 Jahre aufzubewahren.
• AI Act: Die KI-Komponente wäre nach Risikoklasse einzuordnen; die dafür nötige Risikobewertung ließe sich mit der CRA-Risikobewertung gemeinsam methodisch 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 bedienen dann große Teile aller drei betroffenen Regime. Getrennte Silos pro Rechtsakt sind teuer, redundant und fehleranfällig.

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. Diese Zahlen sind ein Grund für strukturierte Vorbereitung — nicht für Panik.

Was Blackfort tut

Die Blackfort Technology UG (haftungsbeschränkt) begleitet Hersteller und Betreiber dabei, die vier Regime nicht als vier Projekte, sondern als einen integrierten Nachweisaufbau zu behandeln. Wir strukturieren die gemeinsamen Bausteine — Risikobewertung und Threat-Modeling, SBOM-Erzeugung, CVD- und Vorfallsprozess entlang der CRA-Melde-Kaskade — so, dass sie über CRA, NIS2, DORA und AI Act hinweg wiederverwendbar sind. Ergebnisse und Empfehlungen sind schematisch und ersetzen keine Rechtsberatung; die verbindliche rechtliche Einordnung bleibt Ihrer Prüfung bzw. Ihren Rechtsberatern vorbehalten.

Ein guter erster Schritt ist unser Betroffenheits-Check: Er ordnet schematisch ein, welche der vier Regime auf Ihr Produkt und Ihre Organisation zutreffen könnten. Kleine und mittlere Unternehmen finden im KMU-Bereich einen pragmatischen Einstieg, branchenspezifische Perspektiven im Branchen-Überblick. Wenn Sie die Konvergenz konkret für Ihr Haus durchspielen möchten, sprechen Sie uns an: Kontakt aufnehmen.

Quellen

• Verordnung (EU) 2024/2847 (Cyber Resilience Act), EUR-Lex
• Richtlinie (EU) 2022/2555 (NIS2), EUR-Lex
• Verordnung (EU) 2022/2554 (DORA), EUR-Lex
• Verordnung (EU) 2024/1689 (AI Act), EUR-Lex
• Durchführungsverordnung (EU) 2025/2392; ENISA Single Reporting Platform; BSI TR-03183-2