DORA hat Sie von NIS2 befreit. Vom CRA befreit es Sie nicht.

In neununddreißig Tagen startet der Cyber Resilience Act eine Meldefrist von vierundzwanzig Stunden, und die Ausnahme, nach der jede Bank greift, hält sie nicht auf. Fragen Sie ein Finanzinstitut, ob NIS2 gilt, und die Antwort kommt flüssig: DORA ist lex specialis, Artikel 4 NIS2 tritt zurück, sobald ein sektorspezifischer Rechtsakt dasselbe Feld abdeckt, und die Bank meldet IKT-Vorfälle ihrer zuständigen Behörde statt einem CSIRT. Diese Antwort ist richtig. Sie wird auch gleich, fälschlich, auf eine Frage zu einer anderen Verordnung gegeben. Der CRA reguliert keine Unternehmen. Er reguliert Produkte und legt seine Pflichten demjenigen auf, der sie herstellt. In seinem Anwendungsbereichsartikel steht keine Ausnahme für Finanzdienstleistungen, denn eine für Unternehmensrecht formulierte Ausnahme findet im Produktrecht nichts, woran sie andocken könnte. Ab dem 11. September 2026 schuldet eine Bank, die Software auf dem Markt bereitstellt, der ENISA eine Frühwarnung binnen vierundzwanzig Stunden — und zwar zusätzlich zu DORA, nicht an dessen Stelle.

Zusammenfassung für die Geschäftsleitung

Ein scharfgestelltes Datum, kein Horizont. Artikel 14 gilt ab dem 11. September 2026. Der Rest des CRA wartet bis zum 11. Dezember 2027, und der Planungsfehler sitzt im Abstand zwischen diesen beiden Tatsachen.

Der Anwendungsbereich entscheidet sich an dem, was Sie ausliefern, nicht an dem, was Sie sind. Die Ausnahmen des CRA sind andere Produktregime — Medizinprodukte, Fahrzeuge, Luftfahrt, Schiffsausrüstung. Das Bankwesen steht nicht darunter und war nie dafür vorgesehen.

Auslöser ist die Ausnutzung, nicht die Schwere. Eine aktiv ausgenutzte Schwachstelle startet die Uhr, auch wenn kein Kunde betroffen ist und nichts davon nach DORA ein schwerwiegender Vorfall wäre.

Heute besitzt das niemand. Die DORA-Meldung sitzt in der operationellen Resilienz. Die CRA-Meldung sitzt bei demjenigen, der als Hersteller gilt — eine Rolle, die die meisten Banken nie vergeben haben.

Was am 11. September tatsächlich beginnt

Der CRA trat am 10. Dezember 2024 mit einem gestaffelten Anwendungsplan in Kraft, und die Staffelung ist genau das, was verloren geht.

Die vollständige Anwendung — grundlegende Cybersicherheitsanforderungen nach Anhang I, Konformitätsbewertung, CE-Kennzeichnung, technische Dokumentation — fällt auf den 11. Dezember 2027. Die Notifizierung von Konformitätsbewertungsstellen ist seit dem 11. Juni 2026 offen. Dazwischen liegt das Datum, auf das es in diesem Quartal ankommt: der 11. September 2026, an dem die Meldepflichten nach Artikel 14 beginnen.

Die Meldestruktur ist dreistufig und enger, als sie sich beim ersten Lesen anfühlt.

Frühwarnung binnen 24 Stunden, nachdem der Hersteller Kenntnis von einer aktiv ausgenutzten Schwachstelle oder von einem schwerwiegenden Vorfall mit Auswirkung auf die Sicherheit des Produkts erlangt hat.
Vollständige Meldung binnen 72 Stunden, mit den technischen Einzelheiten und den ergriffenen Korrektur- oder Abhilfemaßnahmen.
Abschlussbericht binnen 14 Tagen, nachdem für eine aktiv ausgenutzte Schwachstelle eine Korrekturmaßnahme verfügbar ist, oder binnen eines Monats nach der Meldung bei einem schwerwiegenden Vorfall.

Die Meldungen laufen über die von der ENISA betriebene zentrale Meldeplattform des CRA. Ein Hersteller reicht einmal ein, beim als Koordinator benannten CSIRT im Mitgliedstaat seiner Hauptniederlassung; die Plattform stellt die Meldung gleichzeitig der ENISA zur Verfügung, und das empfangende CSIRT leitet sie an weitere CSIRTs in den Gebieten weiter, in denen das Produkt vertrieben wird. Diese Einmal-Einreichung nimmt eine administrative Ausrede weg, entschärft die Frist aber nicht.

Beachten Sie den Auslöser. Nicht Schwere, nicht Kundenbetroffenheit — Ausnutzung. Eine in freier Wildbahn aktiv ausgenutzte Schwachstelle begründet eine 24-Stunden-Pflicht, ob jemand geschädigt wurde oder nicht und ob derselbe Sachverhalt anderswo als schwerwiegender Vorfall einzustufen wäre oder nicht.

Warum die DORA-Ausnahme hier nicht hinreicht

Das ist der Punkt, an dem Präzision lohnt, denn die Argumentation, die zur falschen Antwort führt, ist echte, gute Argumentation — nur eine Verordnung zu weit getragen.

Artikel 4 NIS2 enthält einen Rücktrittsmechanismus: Verlangt ein sektorspezifischer Unionsrechtsakt von Einrichtungen, Risikomanagementmaßnahmen im Bereich der Cybersicherheit zu ergreifen oder erhebliche Sicherheitsvorfälle zu melden, und sind diese Anforderungen in ihrer Wirkung mindestens gleichwertig, so gelten die entsprechenden NIS2-Bestimmungen nicht. DORA ist genau ein solcher Rechtsakt. Ein Kreditinstitut steuert IKT-Risiken also nach DORA und meldet schwerwiegende Vorfälle nach DORA, und die parallelen NIS2-Pflichten treten zurück. Jede Regulatorik-Abteilung kann das aufsagen.

Drei Dinge zerbrechen die Analogie, sobald man sie auf den CRA überträgt.

Der Mechanismus wohnt innerhalb von NIS2. Artikel 4 ist eine Bestimmung der Richtlinie (EU) 2022/2555, die Bestimmungen der Richtlinie (EU) 2022/2555 außer Anwendung setzt. Er ist kein allgemeiner Grundsatz, wonach das sektorale Regime eines Finanzunternehmens alles Übrige verdrängt. Er kann nicht in die Verordnung (EU) 2024/2847 hineingreifen und dort etwas abschalten, denn nichts im CRA unterliegt ihm.

Der CRA reguliert Produkte, nicht Unternehmen. DORA und NIS2 fragen beide: Was für eine Organisation sind Sie? Der CRA fragt: Was haben Sie in Verkehr gebracht? Das sind verschiedene Fragen, und Gleichwertigkeitsargumente zwischen ihnen tragen nicht: Das Meldregime von DORA ist in keinem Sinne „in seiner Wirkung gleichwertig" zur Pflicht eines Herstellers, ein CSIRT zu warnen, dass ein ausgeliefertes Artefakt ausgenutzt wird, denn sie schützen verschiedene Personenkreise. DORA schützt das Finanzsystem über die Aufsicht. Artikel 14 schützt alle, die das Produkt betreiben, über das CSIRT-Netzwerk.

Die Ausnahmen haben die falsche Form. Der Anwendungsbereichsartikel des CRA nimmt Produkte aus, die von anderen sektoralen Produktrechtsakten erfasst sind — Medizinprodukte nach den Verordnungen (EU) 2017/745 und 2017/746, Fahrzeuge nach der Verordnung (EU) 2019/2144, Zivilluftfahrt nach der Verordnung (EU) 2018/1139, Schiffsausrüstung nach der Richtlinie 2014/90/EU — dazu Ersatzteile nach identischen Spezifikationen und Produkte, die ausschließlich für Zwecke der nationalen Sicherheit oder Verteidigung entwickelt wurden. Eine Ausnahme für Finanzdienstleistungen gibt es nicht, und eine Ausnahme für Produkte von DORA-regulierten Unternehmen ebenso wenig. Das ist kein Versehen, das Leitlinien noch korrigieren werden. Das ist, was passiert, wenn ein Gesetzgeber Produktrecht schreibt: Er nimmt keine Branchen aus, er nimmt andere Produktregime aus.

Tabelle 1: Drei Regime, und welches zurücktritt

	DORA	NIS2	CRA
Reguliert	Finanzunternehmen	Wesentliche und wichtige Einrichtungen	Produkte mit digitalen Elementen
Pflicht trifft	Das Institut	Das Institut	Den Hersteller
Meldeauslöser	Als schwerwiegend eingestufter Vorfall	Erheblicher Sicherheitsvorfall	Aktiv ausgenutzte Schwachstelle oder schwerwiegender Vorfall
Meldung geht an	Zuständige Behörde	CSIRT oder zuständige Behörde	CSIRT der Hauptniederlassung und ENISA
Für Banken verdrängt?	Nein — es ist die lex specialis	Ja, über Artikel 4 NIS2	Nein — nichts verdrängt ihn

Sind Sie Hersteller? Niemand hat das für Sie beantwortet

Hier lautet die ehrliche Position: Die Frage ist offen, nicht geklärt — und eine Bank, die auf ihre Klärung wartet, wartet über das Datum hinaus.

Der CRA erfasst Produkte mit digitalen Elementen, die auf dem Markt bereitgestellt werden — zum Vertrieb oder zur Verwendung im Rahmen einer Geschäftstätigkeit abgegeben. Aus dieser Formulierung folgen unmittelbar zwei Dinge.

Der Preis ist nicht der Maßstab. Unentgeltlich abgegebene Software fällt in den Anwendungsbereich, wenn sie im Rahmen einer Geschäftstätigkeit abgegeben wird. Die Lesart der Kommission zu Open Source stellt auf Geschäftstätigkeit ab, nicht auf Bezahlung, und eine Bank, die eine Anwendung verteilt, um zahlende Kunden zu gewinnen und zu betreuen, handelt nicht außerhalb einer Geschäftstätigkeit. Der Reflex „wir verschenken die App, also verkaufen wir kein Produkt" ist der häufigste Grund, warum dieses Dossier ungeöffnet blieb, und er ist das schwächste der verfügbaren Argumente.

Rein interne Software liegt tatsächlich außerhalb. Produkte, die nicht auf dem Markt bereitgestellt werden — die Kernbankenplattform, internes Werkzeug, alles, was das Institut nie verlässt — sind nicht erfasst. Das ist eine reale und erhebliche Ausnahme, und deshalb ist die Exponierung schmaler, als die Panikfassung dieser Analyse nahelegt.

Die Frage lautet also nicht, ob eine Bank als Unternehmen in den Anwendungsbereich fällt. Sie lautet, welche konkreten Artefakte sie abgibt. Vier Kategorien gehören inventarisiert, bevor irgendjemand zu einem Schluss kommt:

Die Mobile-Banking-Anwendung, über App-Stores an die Allgemeinheit verteilt. Ob eine kundenseitige App ein zur Verwendung abgegebenes Produkt ist oder bloß die Schnittstelle zu einer Dienstleistung der Bank, ist die wirklich strittige Frage — und sie ist strittig, nicht zugunsten der Bank entschieden.
Entwicklerseitige Artefakte: SDKs, Client-Bibliotheken, API-Werkzeug und Referenzimplementierungen, die für Firmenkunden oder Partner veröffentlicht werden. Diese sehen weit mehr nach abgegebenen Produkten aus und weit weniger nach einer Dienstleistungsschnittstelle.
Open-Source-Projekte, die das Institut im Rahmen seiner Geschäftstätigkeit veröffentlicht und pflegt, wobei zusätzlich die Regelungen zum Verwalter greifen können.
White-Label- oder eingebettete Software, die die Bank unter eigenem Namen an Partner weiterreicht — der schnellste Weg vom Betreiber zum Hersteller in jedem EU-Produktregime.

Die ehrliche Planungshaltung besteht nicht darin, ein Ergebnis zu behaupten. Sie besteht darin, die Artefakte zu inventarisieren, zu jedem eine dokumentierte Position einzunehmen und die Begründung vorlegen zu können, wenn ein CSIRT fragt, warum keine Meldung eingegangen ist.

Der Uhrenkonflikt

Nehmen wir für einen Moment an, die Analyse ergibt für mindestens ein Artefakt eine Erfassung. Was sich operativ ändert, ist nicht die Existenz eines Vorfallprozesses — den haben Banken —, sondern die Tatsache, dass nun zwei Prozesse auf dasselbe Ereignis mit unterschiedlichen Parametern laufen.

Eine Schwachstelle im veröffentlichten SDK einer Bank gerät unter aktive Ausnutzung. DORA fragt, ob dies ein schwerwiegender IKT-bezogener Vorfall mit Auswirkung auf das Institut ist, und wenn ja, geht die Erstmeldung binnen vier Stunden nach dieser Einstufung und jedenfalls binnen 24 Stunden nach Kenntniserlangung an die zuständige Behörde, mit Zwischen- und Abschlussbericht dahinter. Artikel 14 stellt eine völlig andere Frage — wird ein Produkt ausgenutzt, das dieses Institut hergestellt hat — und startet seine eigene 24-Stunden-Frühwarnung an ein CSIRT und die ENISA.

Beide können in beide Richtungen auseinanderlaufen, und genau das macht einen zusammengelegten Prozess unsicher.

Eine ausgenutzte Schwachstelle in einem ausgelieferten SDK, die die eigenen Dienste der Bank nicht stört, ist nach DORA womöglich überhaupt kein schwerwiegender Vorfall und liegt zugleich mitten in Artikel 14. Und ein schwerer Ausfall einer intern gebauten Plattform ist eine DORA-Meldung ohne jede CRA-Dimension, weil nichts in Verkehr gebracht wurde. Ein einziger Ablauf, der unterstellt, beide feuerten stets gemeinsam, erzeugt zugleich falsche Negative und überflüssiges regulatorisches Rauschen.

Tabelle 2: Was bis zum 11. September geklärt sein muss

Frage	Warum sie Ihre Exponierung bestimmt
Welche Artefakte geben wir außerhalb des Instituts ab?	Der Anwendungsbereich gilt je Produkt; eine Antwort auf Unternehmensebene gibt es nicht
Gibt es je Artefakt eine dokumentierte Herstellerposition?	Eine undokumentierte Annahme ist keine Verteidigung
Wo liegt unsere Hauptniederlassung im Sinne des CSIRT?	Bestimmt, welches nationale CSIRT die Einreichung erhält
Sind wir auf der zentralen Meldeplattform der ENISA registriert?	24 Stunden reichen nicht, um einen Onboarding-Schritt zu entdecken
Hat „aktiv ausgenutzt" im Triage einen Verantwortlichen?	Der Auslöser weicht von jeder bereits genutzten Schwereskala ab
Wer meldet sonntags um 3 Uhr?	Beide Uhren laufen nach Echtzeit, nicht nach Geschäftszeiten

Die Zahl, die die Priorität setzt

Verstöße gegen die grundlegenden Anforderungen des Anhangs I und gegen die Pflichten der Artikel 13 und 14 werden mit Geldbußen von bis zu 15 Millionen Euro oder 2,5 % des gesamten weltweiten Jahresumsatzes geahndet, je nachdem, welcher Betrag höher ist. Weitere Pflichten von Herstellern, Einführern und Händlern liegen eine Stufe darunter bei 10 Millionen Euro oder 2 %, und die Erteilung unrichtiger oder irreführender Auskünfte an Behörden bei 5 Millionen Euro oder 1 %.

Lesen Sie die oberste Stufe gegen den Aufwand, an dem sie hängt. Zu bestimmen, ob vier Artefaktkategorien erfasst sind, sich auf einer Meldeplattform zu registrieren und einem bestehenden Triage-Runbook einen Zweig hinzuzufügen, ist ein überschaubares Stück Arbeit mit benanntem Verantwortlichen und fünf Wochen Vorlauf. Es ist nicht vergleichbar mit dem Konformitätsbewertungs- und Dokumentationsprogramm, das im Dezember 2027 wartet. Die Asymmetrie zwischen Exponierung und Behebungskosten ist das gesamte Argument, und es ist das seltene Compliance-Argument, das den Kontakt mit einer Priorisierungsrunde überlebt.

Das operative Playbook

Fünf Schritte, und der erste ist kein Rechtsgutachten.

Inventarisieren Sie, was das Haus verlässt. Keine Systeme — Artefakte. Alles, was das Institut an jemanden außerhalb abgibt, einschließlich kostenloser Anwendungen, veröffentlichter Bibliotheken und Open-Source-Repositorien. Die meisten Banken haben eine solche Liste nicht, weil keine frühere Regulierung sie verlangt hat.
Beziehen Sie je Artefakt schriftlich Position. Hersteller oder nicht, und warum. Der Wert liegt nicht darin, in jeder Zeile richtig zu liegen; er liegt darin, eine Begründung zu haben, die dem Vorfall vorausgeht, statt danach konstruiert zu werden.
Registrieren Sie sich jetzt auf der zentralen Meldeplattform. Registrierung, Zugangsdaten und ein benannter Einreicher sind genau die Art Voraussetzung, die unsichtbar bleibt, bis eine 24-Stunden-Uhr bereits läuft.
Trennen Sie den Auslöser im Triage. Fügen Sie eine ausdrückliche Frage hinzu — wird ein von uns hergestelltes Produkt aktiv ausgenutzt —, die unabhängig von der DORA-Einstufung als schwerwiegender Vorfall bewertet wird. Die Unabhängigkeit ist der Punkt: Eine verschachtelte Prüfung erbt die falsche Schwelle.
Starten Sie die SBOM-Arbeit gegen das Datum Dezember 2027. Anhang I verlangt eine Software-Stückliste in einem gängigen maschinenlesbaren Format, die mindestens die Abhängigkeiten der obersten Ebene abdeckt. Diese Pflicht liegt sechzehn Monate voraus, und sie ist dasselbe Aufzählungsproblem, an dem Institute auf der kryptografischen Seite bereits scheitern.

Das Muster ist nicht neu. Ein Regime wird mit Blick auf eine bestimmte Branche entworfen, Finanzinstitute lesen den Branchennamen und schließen daraus, das Dossier gehöre jemand anderem. Der CRA wurde für Gerätehersteller und Softwareanbieter geschrieben. Er erreicht die Bank trotzdem, an der schmalen Stelle, an der die Bank zufällig einer davon ist — und die Ausnahme, nach der alle zuerst greifen werden, wurde in ein anderes Gesetz geschrieben, zu einem anderen Zweck, und gilt nicht.

Häufig gestellte Fragen

Wir melden nach DORA. Deckt das nicht alles ab?
Nein. DORA verdrängt die parallelen NIS2-Pflichten über den Rücktrittsmechanismus des Artikels 4 NIS2 selbst. Dieser Mechanismus ist NIS2-intern und wirkt nicht auf die Verordnung (EU) 2024/2847. Der CRA legt Pflichten den Herstellern von Produkten auf, nicht Finanzunternehmen — es gibt also nichts, was ein Lex-specialis-Argument verdrängen könnte.

Fällt unsere Mobile-Banking-App in den Anwendungsbereich?
Das ist die wirklich offene Frage, und sie sollte bewusst beantwortet und nicht unterstellt werden. Die App ist Software mit Datenverbindung, im Rahmen einer Geschäftstätigkeit an die Allgemeinheit abgegeben — das ist die gesetzliche Formulierung. Das Gegenargument lautet, sie sei die Schnittstelle zu einer regulierten Dienstleistung und kein zur Verwendung abgegebenes Produkt. Dokumentieren Sie eine Position; stützen Sie sich nicht darauf, dass sie kostenlos ist, denn der Preis ist nicht der Maßstab.

Was genau löst die 24-Stunden-Frist aus?
Die Kenntnis einer Schwachstelle in Ihrem Produkt, die aktiv ausgenutzt wird, oder eines schwerwiegenden Vorfalls mit Auswirkung auf die Sicherheit des Produkts. Auslöser ist die Ausnutzung, nicht die Schwere und nicht die Kundenbetroffenheit — deshalb deckt er sich nicht mit DORAs Einstufung als schwerwiegender Vorfall.

Bei wem reichen wir tatsächlich ein?
Über die zentrale Meldeplattform des CRA bei der ENISA, adressiert an das als Koordinator benannte CSIRT im Mitgliedstaat Ihrer Hauptniederlassung. Die ENISA erhält sie gleichzeitig, und das empfangende CSIRT teilt sie mit CSIRTs in anderen Gebieten, in denen das Produkt vertrieben wird. Eine Einreichung, nicht mehrere.

Beginnt im September sonst noch etwas?
Nein. Nur die Meldepflichten nach Artikel 14. Die grundlegenden Cybersicherheitsanforderungen, die SBOM-Pflicht, die Konformitätsbewertung, die technische Dokumentation und die CE-Kennzeichnung gelten sämtlich ab dem 11. Dezember 2027. September für das gesamte Dossier zu halten, ist das Spiegelbild davon, es zu ignorieren.

Was kostet es, wenn wir den Anwendungsbereich falsch bestimmen?
Verstöße gegen die Artikel 13 und 14 sowie gegen die grundlegenden Anforderungen des Anhangs I werden mit Geldbußen von bis zu 15 Millionen Euro oder 2,5 % des gesamten weltweiten Jahresumsatzes geahndet, je nachdem, welcher Betrag höher ist. Der unmittelbarere Preis ist prozedural: Eine versäumte Frühwarnung lässt sich nicht rückwirkend heilen, und der Moment, in dem ein Institut entdeckt, dass es Hersteller war, sollte nicht der sein, in dem ein CSIRT fragt, warum keine Meldung kam.

Quellen

Europäisches Parlament und Rat der Europäischen Union, 2024. Verordnung (EU) 2024/2847 über horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen (Cyberresilienzgesetz). Brüssel: Amtsblatt der Europäischen Union. Verfügbar unter: Europäisches Parlament und Rat der Europäischen Union, 2024..
Europäische Kommission, 2026. Cyberresilienzgesetz — Meldepflichten. Brüssel: Generaldirektion Kommunikationsnetze, Inhalte und Technologien. Verfügbar unter: Europäische Kommission, 2026..
Europäische Kommission, 2026. Das Cyberresilienzgesetz — Zusammenfassung des Rechtstextes. Brüssel: Generaldirektion Kommunikationsnetze, Inhalte und Technologien. Verfügbar unter: Europäische Kommission, 2026..
Europäisches Parlament und Rat der Europäischen Union, 2022. Richtlinie (EU) 2022/2555 über Maßnahmen für ein hohes gemeinsames Cybersicherheitsniveau in der Union (NIS-2-Richtlinie). Brüssel: Amtsblatt der Europäischen Union. Verfügbar unter: Europäisches Parlament und Rat der Europäischen Union, 2022..
Europäisches Parlament und Rat der Europäischen Union, 2022. Verordnung (EU) 2022/2554 über die digitale operationale Resilienz im Finanzsektor (DORA). Brüssel: Amtsblatt der Europäischen Union. Verfügbar unter: Europäisches Parlament und Rat der Europäischen Union, 2022..

Zuletzt überprüft 2026-08-16.

Diesen Artikel republizieren

DORA hat Sie von NIS2 befreit. Vom CRA befreit es Sie nicht. — Sebastien Rousseau

Am 11. September startet der CRA eine 24-Stunden-Meldefrist. Sie hängt am Produkt, deshalb greift die DORA-Ausnahme von NIS2 hier nie.

Dieser Artikel ist lizenziert unter Creative Commons Attribution 4.0 International. Eine Republikation erfordert Attribution zur kanonischen URL.

DORA hat Sie von NIS2 befreit. Vom CRA befreit es Sie nicht. — Sebastien Rousseau

Am 11. September startet der CRA eine 24-Stunden-Meldefrist. Sie hängt am Produkt, deshalb greift die DORA-Ausnahme von NIS2 hier nie.

Originally published at https://sebastienrousseau.com/de/2026-08-03-cyber-resilience-act-article-14-reporting-banks-2026/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER