Die KI-Cyberrichtlinie der EZB: Was EU-Banken jetzt wissen müssen

EZB-Richtlinie – 863×300

Eine Bank ist nicht nur ein Tresor voller Geld. Sie ist ein Motor, der durch das Vertrauen der Öffentlichkeit angetrieben wird – getragen von der stetigen Gewissheit, dass Gelder sicher aufbewahrt und jederzeit verfügbar sind. Wenn das operative Risikomanagement versagt, sei es durch Cyber-Angriffe, Systemausfälle oder Schwachstellen bei Drittanbietern, bricht dieses Vertrauen zusammen. Das gefährdet nicht nur das einzelne Institut, sondern die Stabilität des gesamten Finanzsystems. Deshalb geht die regulatorische Aufsicht über die bloße Compliance hinaus: Regulierungsbehörden setzen ein rigoroses operationelles Risikomanagement durch, um sicherzustellen, dass Banken die nötige Resilienz bewahren, um das systemische Vertrauen zu schützen, einen Domino-Effekt bei Störungen zu verhindern und das reibungslose Funktionieren der Gesamtwirtschaft aufrechtzuerhalten.

Während Betriebsunterbrechungen traditionell das Risiko waren, das für Banken am wichtigsten war, betrachten die Europäische Zentralbank (EZB) und der Europäische Ausschuss für Systemrisiken (ESRB) Frontier-KI-Modelle (FAIMs) als systemische Bedrohung der Cyberresilienz für das europäische Finanzsystem, die als vorrangiges Anliegen zeitnah angegangen werden muss.

In diesem Zusammenhang informierte die Europäische Zentralbank am 7. Juli 2026 die CEOs aller großen europäischen Großbanken darüber, dass KI-Modelle der neuesten Generation inzwischen Software-Schwachstellen schneller finden und ausnutzen können, als jeder Prozess reagieren kann, dessen Tempo von Menschen bestimmt wird. Der Europäische Ausschuss für Systemrisiken bestätigte die Auffassung der EZB, dass Frontier-KI-Modelle Bedrohungsakteuren kurz- bis mittelfristig einen echten Vorteil verschaffen.

Das ist keine neue Art von Risiko. Es ist eine, die jede Bank bereits kennt – allerdings nun mit einer Geschwindigkeit, für die die meisten Security- und Engineering-Teams nie ausgelegt waren. Die 110 größten europäischen Banken und indirekt 1.900 kleinere Institute haben bis zum 31. Oktober 2026 Zeit, ihrem Joint Supervisory Team einen konkreten Aktionsplan vorzulegen, Dieser muss benannte Kontrollmaßnahmen, Ressourcen und Verantwortliche (Owner) enthalten, um Schutz gegen die Bedrohungen durch die neuesten Frontier-KI-Modelle zu gewährleisten.
Warum sind Angriffe auf KI-Frontier-Modelle so gefährlich?
Ein Angreifer mit KI-Unterstützung kann selbst Schwachstellen mit geringem Impact innerhalb von Minuten in einen funktionierenden Exploit verwandeln und starten– oft noch bevor eine CVE überhaupt veröffentlicht oder geratet wurde. Eine Priorisierung allein anhand von CVSS kann damit nicht Schritt halten, und den Schweregrad hat es ohnehin nie besonders zuverlässig bewertet. Der neue Standard ist die Reachability (Erreichbarkeit): Ist diese Schwachstelle in Ihrer konkreten Runtime überhaupt adressierbar und relevant? Richtig umgesetzt reduziert dieser Ansatz das Hintergrundrauschen um 80 bis 90 %. So konzentrieren sich Ihre Teams auf reale Bedrohungen, anstatt Zeit mit endlosen Backlogs zu verschwenden.
Welche Rolle die Software Supply Chain spielt
Sie müssen jede Drittanbieter- und Open-Source-Komponente kennen, die in Ihrer Umgebung läuft, eingehenden Code vor der Übernahme kontrollieren und die Lücke zwischen der Erkennung einer Schwachstelle, der Risikobewertung und der Remediation schließen – ohne dabei Compliance-Vorgaben zu verletzen oder die Pipelines auszubremsen, auf die Ihre Teams angewiesen sind, um neue Releases auszuliefern.
Der blinde Fleck in Ihrem eigenen Stack
Die EZB-Richtlinie bringt jedoch noch eine weitere kritische Lücke ans Licht, die bisher in kaum einem Aktionsplan berücksichtigt ist: die KI-Modelle, MCP-Server und Agent Skills, die bereits aktiv in Ihrer Umgebung laufen. Das Schreiben fordert Sie auf, sich auf KI-beschleunigte Bedrohungen vorzubereiten. Es erläutert nicht, wie Sie die KI-Komponenten in Ihrer eigenen Lieferkette steuern sollen, und genau diesen Teil haben die meisten Banken noch nicht angegangen. Wenn Ihr gemeinsames Aufsichtsteam Sie fragt, wie Sie Ihre agentenbasierten Komponenten heute steuern, und die ehrliche Antwort "wir arbeiten noch daran," lautet, können Sie dann wirklich bereit sein, am 31. Oktober einzureichen.

So können Sie schnell testen, wo Sie tatsächlich stehen:

Können Sie ohne großen Aufwand jedes KI-Modell, jeden MCP-Server und jeden Agent Skill auflisten, der heute in Production läuft?

Können Sie für Ihre offenen kritischen Schwachstellen Evidenz auf Basis von Reachability vorlegen? Oder nur eine reine CVE-Auflistung?

Wären Sie in der Lage, innerhalb von Minuten anstatt von Tagen eine signierte SBOM und eine Timeline für die Remediation eines spezifischen Releases zu erstellen?

Wenn Sie bei einer dieser Fragen zögern, ist genau das die Lücke, die Ihr Aktionsplan schließen muss.

All dem zugrunde liegt DORA, was im Schreiben der EZB ausdrücklich bekräftigt wird. DORA-Auditoren verlangen den Nachweis auf Knopfdruck, dass eine bestimmte Control funktioniert hat, als sie gebraucht wurde: eine signierte SBOM, eine Attestation oder ein Remediation-Nachweis mit Zeitstempel für ein bestimmtes Release. Ebendiese Nachweise sollten ein Nebenprodukt jedes Releases sein, kein wochenlanger Kraftakt. Der bestehende Auditprozess der meisten Banken ist nicht darauf ausgelegt, auf diese Weise zu funktionieren. Unser Bericht „Sicherheit der Software-Lieferkette: Zum Stand der Dinge 2026“ zeigte, dass die meisten Unternehmen noch immer eine Woche oder länger benötigen, um solche Nachweise zu erbringen. Nur ein kleiner Bruchteil schafft es innerhalb eines Tages.
Der JFrog Ansatz
Wir haben mit einem globalen Finanzunternehmen mit einem Umsatz von über 50 Milliarden USD zusammengearbeitet, das in mehr als 160 Ländern tätig ist, um Echtzeitreplikation, eine Verfügbarkeit von 99,9 % und eine ordnungsgemäße Prüfung jedes Open-Source-Pakets in seiner Pipeline zu gewährleisten. Dies ist dieselbe Grundlage, die ein DORA-fähiger Aktionsplan benötigt.

Hier würden wir ansetzen, basierend auf unserer Erfahrung damit, was bei anderen Banken funktioniert hat:

Beginnen Sie mit einer Gap-Analyse: Gleichen Sie Ihren Ist-Zustand direkt mit den Schwerpunktbereichen der EZB ab, damit Sie vor dem 31. Oktober genau wissen, wo Sie stehen.
Governance integrieren: Etablieren Sie eine Single Source of Truth für jedes Artifact über ein zentrales System of Record.
Security einbetten: Verankern Sie Sicherheitsprüfungen nahtlos in jeder Phase – von der Aufnahme bis zur Production.
KI-Komponenten verwalten: Steuern Sie Agents, Skills und MCPs als gleichwertige First-Class-Komponenten in Ihrer Supply Chain.
Priorisieren Sie nach Erreichbarkeit: Richten Sie die Kapazitäten Ihres Teams gezielt auf die Risiken aus, die tatsächlich eine Bedrohung darstellen.
Automatisieren Sie Detection & Remediation: Definieren Sie Richtlinien und Approval Gates für Ihr Team. Bei dieser Frequenz kann ein Prozess, der bei jedem Schritt auf manuelle Eingriffe angewiesen ist, nicht mehr Schritt halten.

Ihre Kontrollen müssen mit dem Tempo der Bedrohungen Schritt halten, um Ihre Kunden vor Risiken zu schützen und DORA standzuhalten. Um die EZB-Richtlinie zu erfüllen, sollten Sie zunächst feststellen, wo Ihre Software-Lieferkette heute steht, und auf Grundlage Ihrer Erkenntnisse handeln.

Möchten Sie tiefer in das Thema eintauchen? Sehen Sie sich dieses Webinar an, in dem wir erläutern, was die EZB-Richtlinie in der Praxis bedeutet und wie Banken sich unserer Erfahrung nach auf die Frist am 31. Oktober vorbereiten.