Velocity Asymmetry: Wie KI die Kräfteverhältnisse zwischen Angreifern und Verteidigern verschiebt 

Was hinter dem EZB-Brief steckt 

Als die Europäische Zentralbank am 7. Juli 2026 einen Brief an die CEOs der beaufsichtigten Institute verschickte, war die Stoßrichtung klar: Unter dem Titel „Addressing AI-enabled cybersecurity threats“ fordert die EZB, dass sich die Institute ernsthaft und nachweislich mit KI-gestützten Cyberbedrohungen auseinandersetzen und bis zum 31. Oktober 2026 einen Aktionsplan bei ihrem jeweiligen Joint Supervisory Team einreichen. 

Der Brief hatte eine Vorgeschichte, die sich bis Mitte 2026 aus mehreren parallelen Entwicklungen zusammensetzte und ein Bild ergab, das auf Aufsichtsebene nicht mehr zu ignorieren war. Zwei Wochen vor dem EZB-Schreiben hatte der Europäische Ausschuss für Systemrisiken (ESRB) eine formelle Warnung herausgegeben: KI-Frontier-Modelle gefährden nicht nur einzelne Institute, sondern die Stabilität des Finanzsystems insgesamt. Zur gleichen Zeit zeigte ein Blogbeitrag von CERT-EU, gestützt auf Daten aus Google M-Trends 2026, dass die mittlere Zeit bis zur Ausnutzung neu bekannt gewordener Schwachstellen auf unter sieben Tage gesunken ist. Dieser Wert stellt die traditionelle Annahme grundlegend in Frage, dass Verteidiger zwischen der Offenlegung einer Schwachstelle und ihrer aktiven Ausnutzung noch über ein nutzbares Zeitfenster verfügen. Für Finanzinstitute, die laut CERT-EU Threat Landscape Report 2025 zu den meistangegriffenen Sektoren gehören, heißt das nicht einfach schneller patchen, sondern dass Patchgeschwindigkeit als zentrales Element der Abwehrstrategie strukturell neu gedacht werden muss. 

Die Europäische Agentur für Cybersicherheit (ENISA) gab dem zugrundeliegenden Problem in ihrer Publikation „Cybersecurity in the Frontier AI Era“ (Juli 2026), die am selben Tag wie der EZB-Brief veröffentlicht wurde, einen Namen: „velocity asymmetry“ (übers. Geschwindigkeitsasymmetrie). Menschlich gesteuerte Genehmigungsprozesse wie Change Advisory Boards bringen eine prozedurale Latenz mit sich, die immer ein Kompromiss war, aber nun zu einer echten strukturellen Schwachstelle wird. Gleichzeitig industrialisiert KI die Entdeckung von Schwachstellen in einem Volumen, das die Triagekapazitäten überfordert, und Angreifer nutzen zunehmend die Software Lieferkettenangriffe, um Perimeterschutzmaßnahmen vollständig zu umgehen. 

Die Black Hat 2026 in Las Vegas machte greifbar, was viele bis dahin eher als Zukunftsszenario eingeordnet hatten. CrowdStrike belegte im Threat Hunting Report 2026, dass 88% der Exploits mit einem öffentlichem Proof-of-Concept innerhalb von 48 Stunden aktiv ausgenutzt werden, staatlich gesponserte APTs schaffen das schon in unter 24 Stunden. James Kettle von PortSwigger demonstrierte mit HTTP Terminator ein System, das autonom aus HTTP-Protokollspezifikationen mehr als 30.000 Angriffsvektoren ableitete und Hunderte angreifbarer Bank- und Behördensysteme identifizierte, ohne eine einzige öffentlich bekannte Schwachstelle zu benötigen. Forscher des Tencent Security Xuanwu Lab zeigten eine LLM-Pipeline, die durch selbstkorrigierende Logik über 100 Schwachstellen in Chrome und Android aufdeckte, darunter Fehler, die kein Mensch ihr vorgegeben hatte. Diese Präsentationen beschrieben nicht, wozu KI eines Tages fähig sein könnte. Sie beschrieben, was gut ausgestattete Angreifer heute bereits tun. 

Was die EZB tatsächlich fordert 

Die EZB behauptet nicht, dass KI-Bedrohungen etwas völlig Neues sind. Ihre Einschätzung ist präziser: KI-Modelle können heute autonom und in großem Maßstab Schwachstellen aufspüren und funktionsfähige Exploits erzeugen, was das Ausnutzungsfenster auf nahezu null schrumpfen lässt. Eine Verteidigungsstrategie, die mit diesem Tempo nicht mithalten kann, ist keine Strategie mehr. Und DORA stellt die EZB dabei nicht in Frage, sondern die Konsequenz, mit der seine Anforderungen bislang umgesetzt wurden. 

Was das konkret bedeutet: Jedes Institut muss bis zum 31. Oktober 2026 einen detaillierten Aktionsplan bei seinem Joint Supervisory Team einreichen. Der Plan soll vier Fragen beantworten: Welche Kontrollen werden gestärkt, welche Ressourcen dafür eingeplant, wer ist verantwortlich und bis wann. Damit sich die Institute darauf konzentrieren können, hat die EZB die Frist für den jährlichen IT-Risikofragebogen von September 2026 auf Februar 2027 nach hinten verschoben. 

Kurzfristig liegt der Schwerpunkt auf Schwachstellen- und Patch-Management, verbesserter Erkennung, KI-gestützter Abwehr und einer gründlichen Neubewertung von Drittanbieterrisiken vor dem Hintergrund zunehmender Lieferkettenangriffe. Langfristig erwartet die EZB Defence-in-Depth, Zero-Trust-Architektur, Netzwerk-Mikrosegmentierung und eine belastbare Cyber-Hygiene-Basis. Für Legacy-Systeme braucht es einen glaubwürdigen Ablösepfad. Gesondert wird eine Aufsichtsleitlinie zur Post-Quanten-Kryptografie folgen, da Quantencomputing als aufkommende Bedrohung für klassische Verschlüsselung eingestuft wird und Institute nach Ansicht der EZB bereits jetzt beginnen sollten, sich darauf vorzubereiten. 

Die sechs Handlungsfelder: Was sie in der Praxis bedeuten 

1. Angriffsfläche schützen 

Ein umfassendes und kontinuierlich aktualisiertes Inventar aller IKT-Assets ist die Grundlage, auf der alles andere aufbaut. Dabei geht es nicht nur um das, was die eigenen Teams eingesetzt haben, sondern ausdrücklich auch um Software von Drittanbietern und Open-Source-Komponenten. Bei der Priorisierung von Behebungsmaßnahmen empfiehlt sich eine Außen-nach-innen-Logik; Internetexponierte und extern erreichbare Assets wie Cloud-Umgebungen oder VPN-Verbindungen zu Drittanbietern verdienen die höchste Aufmerksamkeit, bevor der Blick nach innen geht. Allerdings sollte dabei nicht der Fehler gemacht werden, interne Bedrohungsvektoren als nachrangig zu behandeln. 

Regulatorische Grundlage:  

• DORA Art. 8 (IKT-Asset-Inventar), und DORA Art. 28-44 (Drittanbieter-Risikomanagement) 

• CRA Art. 13(5)-(6) und Anhang I Teil II (Umgang mit Schwachstellen in der Lieferkette).  

• CERT-EU stellt fest, dass die Ausnutzung internetexponierter Software seit zwei aufeinanderfolgenden Jahren der wirksamste initiale Zugriffsvektor gegen EU-Einrichtungen war. 

2. Schwachstellen- und Patch-Management im großen Maßstab beschleunigen 

Das Patch-Problem ist nicht allein technischer Natur, sondern zu einem erheblichen Teil auch organisatorisch. KI-basierte Scan-Tools können bei der Priorisierung sinnvoll unterstützen, allerdings nur dann wenn sie mit angemessener Risikobewertung, menschlicher Aufsicht und klaren Sicherheitsvorkehrungen betrieben werden. Daneben brauchen IKT-Teams schlicht ausreichend Personal, um höhere Patch-Zyklen operativ stemmen zu können. Change-Management-Prozesse müssen so gestaltet sein, dass sie eine schnelle, risikobasierte Behebung ermöglichen und klare Eskalationswege für Notfälle vorsehen. Wo IKT-Dienstleistungen ausgelagert sind, müssen genau diese Erwartungen in den entsprechenden SLAs verankert sein. 

Die Datenlage lässt wenig Interpretationsspielraum, denn ENISA stellt fest dass neu bekannt gewordene Schwachstellen bereits innerhalb von 15 Minuten nach ihrer Offenlegung als Waffe eingesetzt werden können. CERT-EU dokumentiert, wie Angreifer automatisiertes Patch-Diffing mit KI-gestützter Exploit-Generierung kombinieren, um aus einem veröffentlichten Patch rückwärts auf die zugrundeliegende Schwachstelle zu schließen und innerhalb weniger Tage funktionierende Angriffe zu entwickeln. Change Advisory Boards, die wöchentlich tagen, sind für diese Realität schlicht nicht ausgelegt. 

Regulatorische Grundlage:  

• DORA Art. 9 (IKT-Sicherheitsrichtlinien, Patch- und Change-Management), und DORA Art. 30 (Patch-Verpflichtungen in Drittanbieter-SLAs) 

• CRA Anhang I Teil II (Herstellerpflichten zur Behebung) 

• EU AI Act Art. 14-15 (Aufsicht über KI-Tools). 

3. Monitoring, Erkennung und KI-gestützte Abwehrfähigkeiten verbessern 

Ein verbessertes Monitoring von Anwendungs- und Zugriffsprotokollen, Netzwerkverkehr und Indicators of Compromise bildet die operative Grundlage für alles, was danach kommt, mit besonderem Augenmerk auf internetexponierte Anwendungen, Cloud-Repositorys und kritische interne Systeme. KI-basierte Erkennungstools werden dabei ausdrücklich befürwortet, unterliegen jedoch denselben Governance-Anforderungen wie andere KI-gestützte Werkzeuge: vorherige Risikobewertung, menschliche Aufsicht und robuste Sicherheitsvorkehrungen. 

Das eigentliche Erkennungsproblem in den meisten Instituten ist dabei kein Datenmangel. ENISA hat festgestellt, dass bei 75 Prozent der untersuchten Sicherheitsvorfälle Protokolldaten vorhanden waren, die den Einbruch hätten sichtbar machen können. Das Problem war, dass die relevanten Signale über verschiedene Tools verteilt lagen und nie zu einer verwertbaren Handlungsgrundlage zusammengeführt wurden. Genau diese Lücke zwischen vorhandenen Daten und operativem Lagebewusstsein soll KI-gestützte Erkennung schließen. Aus diesem Grund fordert ENISA, dass Security Operations auf eine mittlere Erkennungs- und Reaktionszeit im einstelligen Minutenbereich hinarbeiten, anstatt Erkennung weiterhin als periodische oder reaktive Funktion zu behandeln. 

Regulatorische Grundlage:  

• DORA Art. 10 (Vorfallserkennungsmechanismen), und DORA Art. 17 (Vorfallsmanagement) 

• EU AI Act Art. 14-15 

• ENISA Multilayer Framework for Good Cybersecurity Practices for AI. 

4. Governance, Finanzierung, Sensibilisierungsschulungen und Lieferkettensicherheit stärken 

Die entscheidende Frage für Leitungsorgane ist nicht, ob IKT-Budgets und Personalausstattung auf dem Papier vertretbar aussehen, sondern ob sie für das ausreichen, was beschleunigte Patch-Zyklen, kontinuierliche Resilienztests und KI-gestützte Abwehrfähigkeiten in der Praxis tatsächlich verlangen. In vielen Instituten wird eine ehrliche Antwort darauf unbequem sein, und die EZB ist sich dessen erkennbar bewusst. Dasselbe gilt für Sensibilisierungsschulungen: Programme, die einmal jährlich aktualisiert und einheitlich durch die gesamte Organisation geschickt werden, sind für ein Bedrohungsumfeld, das sich wöchentlich verändert, schlicht nicht gemacht. Schulungen müssen rollenspezifisch gestaltet sein, wo sinnvoll auf Kunden und Dritte ausgeweitet werden und als lebendiger Bestandteil des Sicherheitsprogramms behandelt werden, nicht als jährliche Pflichtübung, die man abhakt. 

Bei der Lieferkette ist die Erwartungshaltung der EZB ebenso klar. Die Verantwortung für die Sicherheitslage beauftragter IKT-Dienstleister lässt sich nicht delegieren, und die EZB räumt keinerlei Spielraum für die Annahme ein, dass Dienstleister beschleunigte Patch-Verpflichtungen erfüllen, ohne dass dies ausdrücklich vereinbart und überprüft wird. ENISA ergänzt eine Bedingung, die für den gesamten Bereich gilt: Wo KI-gestützte Workflows in den Sicherheitsbetrieb eingeführt werden, müssen menschliche Aufsicht und Nachvollziehbarkeit von Anfang an im Design verankert sein, nicht nachträglich hinzugefügt werden. Governance, die erst im Nachhinein in einen KI-gesteuerten Triage-Prozess eingebaut wird, ist keine Aufsicht. Sie ist die Simulation von Aufsicht. 

Regulatorische Grundlage:  

• DORA Art. 5 (IKT-Risikoverantwortung auf Vorstandsebene), DORA Art. 13 (Sicherheitsbewusstsein und Schulungen), und DORA Art. 28-44 (Lieferkettenverantwortung) 

• CRA Art. 13(5) und Anhang I Teil II 

• EU AI Act Art. 26 (Betreiberpflichten für Hochrisiko-KI-Systeme). 

5. Defence-in-Depth, Cyber-Hygiene und Infrastrukturmodernisierung stärken 

Dass Institute damit rechnen sollten, dass ein Sicherheitsvorfall letztlich eintritt, ist keine pessimistische Grundhaltung, sondern operativer Realismus, und die EZB leitet ihre Kontrollanforderungen konsequent aus dieser Prämisse ab. Netzwerksegmentierung und, wo technisch möglich, Mikrosegmentierung sind der praktische Ausdruck davon: Wenn ein Perimeterschutz versagt, sollte die Architektur selbst begrenzen, wie weit ein Angreifer vordringen kann. Zero-Trust-Prinzipien erweitern diese Logik und erfordern eine kontinuierliche Verifikation über Nutzer, Geräte, Anwendungen, APIs und Service-Accounts hinweg, anstatt allem innerhalb der Netzwerkgrenze implizites Vertrauen entgegenzubringen. 

Darunter liegt eine Reihe von Hygiene-Kontrollen, die die EZB als nicht verhandelbar einstuft, gerade weil sie in der Praxis so häufig zugunsten sichtbarerer Investitionen zurückgestellt werden: vollständige Asset-Inventare, sichere Konfigurationen, Least-Privilege-Zugang, MFA und eine Protokollierung, die tatsächlich vollständig genug ist, um im Ernstfall verwertbar zu sein. Security-by-Design muss von den frühesten Phasen der Softwareentwicklung an mitgedacht werden, nicht als nachträgliche Schicht. Legacy- und End-of-Life-Systeme brauchen einen glaubwürdigen Ablösepfad, und wo eine sofortige Ablösung nicht realisierbar ist, müssen kompensierende Kontrollen dokumentiert und aktiv gepflegt werden, nicht nur einmalig festgehalten und danach aus dem Blick verloren. ENISA geht noch einen Schritt weiter und empfiehlt, jede Umgebung als potenziell bereits kompromittiert zu betrachten und KI-gestütztes Bedrohungsmodellieren als dauerhafte Fähigkeit zu etablieren, nicht als gelegentliche Übung. 

Regulatorische Grundlage:  

• DORA Art. 9 (mehrschichtige IKT-Sicherheitskontrollen), und DORA Art. 8 (Asset-Inventar) 

• CRA Art. 13 und Anhang I Teil I (Security by Design) 

• EU AI Act Art. 14-15 

• ENISA Multilayer Framework for Good Cybersecurity Practices for AI. 

6. Operative Resilienz, Krisenmanagement und Informationsaustausch verbessern 

Ein Business-Continuity-Plan, der nur gegen bekannte und klar umrissene Szenarien getestet wurde, ist keine Resilienzfähigkeit, sondern ein Dokument, das Resilienz lediglich beschreibt. Die EZB erwartet, dass Resilienztests explizit jene Bedingungen abdecken, die einen Plan am wahrscheinlichsten an seine Grenzen bringen: Zero-Day-Ausnutzung, Ransomware, destruktive Angriffe und Störungen, die nicht im eigenen Perimeter entstehen, sondern in der Lieferkette oder in Cloud-Umgebungen. Backup- und Failover-Vorkehrungen verdienen dieselbe kritische Betrachtung. Zu prüfen, ob sie unter realistischen Bedingungen funktionieren, ist eine grundlegend andere Übung als zu prüfen, ob sie überhaupt vorhanden sind, und die EZB erwartet, dass Institute diesen Unterschied nicht nur kennen, sondern auch danach handeln. 

Bei der Frage des Informationsaustauschs spiegelt die EZB etwas wider, das die Bedrohungsdaten konsequent belegen: Finanzinstitute, die denselben Angreifern und derselben Schwachstellenlandschaft ausgesetzt sind, gewinnen mehr durch den gezielten Austausch von Intelligence, als wenn sie diese als proprietär behandeln. Schwachstellendaten, Bedrohungsindikatoren und Erkenntnisse über erfolgreiche Behebungsansätze, die mit Branchenkollegen geteilt werden, verkürzen die Reaktionszeit für alle Beteiligten im Netzwerk. Wer diese Informationen zurückhält, schützt damit keinen Wettbewerbsvorteil, sondern den des Angreifers. 

Regulatorische Grundlage:  

• DORA Art. 11 (Business Continuity und Disaster Recovery), DORA Art. 15 (Tests der IKT-Geschäftskontinuität), DORA Art. 17 (Vorfallsmanagement), und DORA Art. 45 (freiwillige Informationsaustauschvereinbarungen) 

• ENISA Multilayer Framework for Good Cybersecurity Practices for AI (Juni 2023) 

• TIBER-EU (aktualisiert Januar 2025) – abgestimmt auf die technischen DORA-Regulierungsstandards für bedrohungsgeführte Penetrationstests, einschließlich obligatorischer Purple-Team-Übungen. 

31. Oktober im Blick: Wie resilient ist Ihr Institut?

Die Frist bis zum 31. Oktober ist knapp und die Anforderungen gehen deutlich über eine regulatorische Pflichtübung hinaus.

Wie gut ist Ihr Institut auf die neue Geschwindigkeitsasymmetrie vorbereitet? Welche der sechs Handlungsfelder sind bereits belastbar umgesetzt? Wo besteht noch konkreter Handlungsbedarf?

Gerne tauschen wir uns dazu aus, wie sich die Anforderungen der EZB in einen priorisierten und umsetzbaren Aktionsplan übersetzen lassen. Kontaktieren Sie unsere Experten.

Referenzen 

EZB, „Addressing AI-enabled Cybersecurity Threats“ (Juli 2026) – https://www.bankingsupervision.europa.eu/press/letterstobanks/shared/pdf/2026/ssm.2026_letter_on_AI_enabled_cybersecurity_threats.en.pdf  

CERT-EU, „AI is changing the economics of vulnerability discovery“ (April 2026) – https://cert.europa.eu/blog/ai-vulnerability-discovery-defenders-must-adapt  

CERT-EU, Threat Landscape Report 2025 (April 2026) – https://www.cert.europa.eu/publications/threat-intelligence/tlr2025/pdf  

CrowdStrike, 2026 Threat Hunting Report Blogbeitrag (August 2026) – https://www.crowdstrike.com/en-us/blog/crowdstrike-2026-threat-hunting-report/  

ENISA, „Cybersecurity in the Frontier AI Era“ (Juli 2026) – https://www.enisa.europa.eu/publications/enisas-view-on-cybersecurity-in-the-frontier-ai-era  

ENISA, Multilayer Framework for Good Cybersecurity Practices for AI (Juni 2023) – https://www.enisa.europa.eu/publications/multilayer-framework-for-good-cybersecurity-practices-for-ai  

ESRB, Warnung zu systemischen Cyberrisiken durch KI-Frontier-Modelle (Juni 2026) – https://www.esrb.europa.eu/pub/pdf/warnings/esrb.warning260625_on_systemic_cyber_risks_stemming_from_frontier_ai_models~ef424708cf.en.pdf  

Google Mandiant, M-Trends 2026 (März 2026) – https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2026/  

TIBER-EU Framework (aktualisiert Januar 2025) – https://www.ecb.europa.eu/paym/cyber-resilience/tiber-eu/html/index.en.html  

Verordnung (EU) 2022/2554, Digital Operational Resilience Act (DORA) – https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng  

Verordnung (EU) 2024/1689, Artificial Intelligence Act (EU AI Act) – https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng  

Verordnung (EU) 2024/2847, Cyber Resilience Act (CRA) – https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng