Content
The Threat Landscape That Prompted the Letter
On 7 July 2026, the European Central Bank sent a letter titled “Addressing AI-enabled Cybersecurity Threats” addressed to the CEOs of every significant institution under ECB supervision. The message was simple: this is urgent, and we need a plan from you by 31 October 2026, submitted to your Joint Supervisory Team.
The letter did not arrive in a vacuum, but rather as a response to the recent developments in Frontier AI Models. By mid-2026, a series of developments had accumulated to the point where the gap between how fast institutions could respond and how fast adversaries could move had become impossible to ignore at the supervisory level. Two weeks before the ECB letter, the European Systemic Risk Board had issued a formal warning on systemic cyber risks stemming from frontier AI models, concluding that the same capability shift threatening individual institutions carried implications for the stability of the financial system as a whole. CERT-EU’s blog post (April 2026) cited a disturbing trend; the mean time to exploit newly disclosed vulnerabilities has fallen to negative seven days (Google’s M-Trends 2026), a figure that inverts the traditional assumption that defenders have at least some window between disclosure and active exploitation. That assumption no longer holds, and for financial institutions, which have occupied a place among the two most targeted sectors in CERT-EU’s Threat Landscape Report 2025 (April 2026), the implication is not that they need to patch faster but that patching speed alone is structurally insufficient as a defensive posture.
The European Union Agency for Cybersecurity (ENISA) put a name to the underlying problem in its publication “Cybersecurity in the Frontier AI Era” (July 2026), released the same day as the ECB letter: velocity asymmetry. Human-led authorisation processes like change advisory boards introduce procedural latency that was always a trade-off, but is now becoming a genuine structural liability. At the same time, AI is industrialising vulnerability discovery at a volume that overwhelms triage capacity, and adversaries are increasingly using the software supply chain to bypass perimeter defences entirely.
Black Hat 2026 in Las Vegas provided some of the most concrete evidence yet of offensive AI capability development. CrowdStrike’s 2026 Threat Hunting Report found that 88% of exploits with an effective public proof-of-concept were actively exploited within 48 hours of release, with state-sponsored APTs consistently weaponising effective PoCs within 24 hours. James Kettle of PortSwigger went further, presenting HTTP Terminator, an AI-assisted system that autonomously explored more than 30,000 attack vectors derived from HTTP protocol specifications and identified hundreds of vulnerable banking and government targets without relying on a single known vulnerability. Researchers from Tencent’s Security Xuanwu Lab demonstrated something equally unsettling; an LLM pipeline that discovered over 100 vulnerabilities in Chrome and Android through self-correcting logic, finding bugs that no human had pointed it toward. Taken together, these presentations did not describe what AI-driven offensive research might one day look like. They described what it looks like right now, in the hands of well-resourced adversaries who are not waiting for defenders to catch up.
What the ECB Is Actually Asking For
The ECB is not arguing that AI threats are categorically new. Its position is more pointed than that; the speed and scale at which AI models can now autonomously identify vulnerabilities and generate working exploits have compressed the exploitation window to near zero, and that demands a response that matches the pace.
The ECB is also not saying DORA is insufficient. It is saying DORA’s requirements need to be implemented with far greater urgency than many institutions have shown so far.
Concretely, each institution must submit a detailed action plan to its Joint Supervisory Team by 31 October 2026. That plan needs to answer four questions: what controls will be strengthened, what resources will be committed, who is accountable, and by when. To give institutions space to focus on this, the ECB has extended the annual IT Risk Questionnaire deadline from September 2026 to February 2027.
The short-term priorities are vulnerability and patch management, stronger detection, AI-enabled defences, and a serious reassessment of third-party risk given the sharp rise in supply chain attacks. Longer-term, the ECB calls for defence-in-depth, zero-trust architecture, network micro-segmentation, and robust cyber hygiene baselines. Legacy systems need to go, and separately dedicated supervisory guidance on post-quantum cryptography is coming, as the ECB flags quantum computing as an emerging threat to traditional encryption that institutions should already be thinking about.
The Six Action Areas: What They Mean in Practice
1. Prioritise Attack Surface Protection
A comprehensive and continuously updated inventory of all ICT assets is the foundation of everything else. That means third-party software and open-source components too, not just what your own teams deployed. Remediation priority should flow outward-in: start with internet-facing and externally exposed assets (cloud environments, third-party VPN connections), then work inward. Critically, internal threat vectors deserve equal attention alongside external ones.
Regulatory grounding:
- DORA Art. 8 (ICT asset inventory), and DORA Arts. 28-44 (third-party risk management)
- CRA Art. 13(5)-(6) and Annex I Part II (supply chain vulnerability handling).
- CERT-EU notes that exploitation of internet-facing software has been the highest-impact initial access vector against Union entities for two consecutive years running.
2. Accelerate Vulnerability and Patch Management at Scale
The patching problem is not just technical, but organisational. AI-based scanning tools can help with prioritisation, but only with proper risk assessment, human oversight, and safeguards in place. ICT teams need enough people to actually handle higher-volume patching cycles. Change management processes must support rapid, risk-based remediation with clear emergency escalation paths, and those expectations need to be written into SLAs with outsourced ICT providers.
The numbers here are stark; ENISA notes that newly disclosed vulnerabilities can be weaponised within 15 minutes of disclosure. CERT-EU documents attackers using automated patch-diffing combined with AI-assisted exploit generation to reverse-engineer vulnerabilities and produce working attacks within days of a patch release. Change advisory boards meeting weekly are simply not built for this reality.
Regulatory grounding:
- DORA Art. 9 (ICT security policies, patch and change management), and DORA Art. 30 (third-party SLA patching obligations)
- CRA Annex I Part II (vendor remediation obligations)
- EU AI Act Arts. 14-15 (AI tool oversight)
3. Enhance Monitoring, Detection, and AI-Enabled Defensive Capabilities
Stronger monitoring of application and access logs, network traffic, and indicators of compromise is essential, with particular focus on internet-facing applications, cloud repositories, and critical internal systems. AI-based detection tools are explicitly encouraged here, subject to the same governance conditions as scanning tools; prior risk assessment, human oversight, and robust safeguards.
The detection problem in most institutions is not a shortage of data. ENISA found that in 75% of breaches logging existed that should have surfaced the intrusion, but the signals were scattered across tools and never consolidated into action. That gap between data availability and operational awareness is precisely what AI-enabled detection is positioned to close, and why ENISA calls for security operations to target single-digit-minute mean-time-to-detect and mean-time-to-respond rather than treating detection as a periodic or reactive function.
Regulatory grounding:
- DORA Art. 10 (incident detection mechanisms); DORA Art. 17 (incident management)
- EU AI Act Arts. 14-15
- ENISA Multilayer Framework for Good Cybersecurity Practices for AI
4. Strengthen Governance, Funding, Awareness Training, and Supply Chain Assurance
The question management bodies need to ask themselves is not whether their ICT budgets and staffing levels are defensible on paper, but whether they are genuinely adequate for what accelerated patching, continuous resilience testing, and AI-enabled defensive capabilities actually require in practice. In many institutions, an honest answer to that question will be uncomfortable, and the ECB is clearly aware of that. Awareness training deserves the same scrutiny; programmes that are updated once a year and delivered uniformly across the organisation are not fit for a threat environment that changes on a weekly basis. Training needs to be role-specific, extended to customers and third parties where relevant, and treated as a living part of the security programme rather than an annual compliance exercise.
The supply chain dimension is equally unambiguous. Institutions cannot outsource accountability for the security posture of their ICT providers, and the ECB makes no allowance for the assumption that a contracted provider will meet accelerated patching obligations without those obligations being explicitly verified. ENISA adds a further condition that applies across all of this; wherever AI-assisted workflows are introduced into security operations, human oversight and auditability must be built into the design from the start. Bolting governance onto an AI-driven triage process after the fact is not oversight. It is the appearance of oversight.
Regulatory grounding:
- DORA Art. 5 (board-level ICT risk responsibility), DORA Art. 13 (security awareness and training), and DORA Arts. 28-44 (supply chain accountability)
- CRA Art. 13(5) and Annex I Part II
- EU AI Act Art. 26 (deployer obligations for high-risk AI systems).
5. Reinforce Defence-in-Depth, Cyber Hygiene, and Infrastructure Modernisation
The ECB’s expectation that institutions operate on the assumption of eventual breach is not pessimism but operational realism, and the controls it calls for follow directly from that premise. Network segmentation and, where feasible, micro-segmentation are the practical expression of that assumption; if a perimeter defence fails, the architecture itself should limit how far an attacker can move. Zero-trust principles extend that logic further, requiring continuous verification across users, devices, applications, APIs, and service accounts rather than treating anything inside the network boundary as implicitly trustworthy.
Underpinning all of this are hygiene controls that the ECB treats as non-negotiable precisely because they are so often deprioritised in favour of more visible investments: comprehensive asset inventories, secure configuration, least-privilege access, MFA, and logging that is actually complete enough to be useful. Security-by-design must be embedded from the earliest stages of software development rather than applied as a retrospective layer. Legacy and end-of-life systems need a credible replacement path, and where immediate replacement is not feasible, compensating controls must be documented and actively maintained rather than noted and forgotten. ENISA goes further, recommending that institutions treat every environment as potentially already compromised and use continuous AI-driven threat modelling as a permanent red teaming capability rather than a periodic exercise.
Regulatory grounding:
- DORA Art. 9 (layered ICT security controls), and DORA Art. 8 (asset inventory)
- CRA Art. 13 and Annex I Part I (security by design)
- EU AI Act Arts. 14-15
- ENISA Multilayer Framework for Good Cybersecurity Practices for AI
6. Improve Operational Resilience, Crisis Management, and Information Sharing
A business continuity plan that has only ever been tested against familiar, well-scoped scenarios is not a resilience capability, but merely a document. The ECB’s expectation is that resilience testing explicitly covers the conditions that are most likely to stress the plan beyond its design assumptions; zero-day exploitation, ransomware, destructive attacks, and disruptions that originate in the supply chain or cloud rather than within the institution’s own perimeter. Backup and failover arrangements deserve the same scrutiny. Verifying that they work under realistic conditions is a different exercise from verifying that they exist, and the ECB expects institutions to know the difference.
On information sharing, the ECB’s encouragement to participate actively in trusted frameworks reflects something that the threat data consistently supports; financial institutions facing the same adversaries and the same vulnerability landscape have more to gain from exchanging intelligence than from treating it as proprietary. Vulnerability data, threat indicators, and remediation approaches shared with sector peers reduce the time it takes every institution in the network to respond. Withholding that information does not protect competitive advantage, it protects the attacker’s.
Regulatory grounding:
- DORA Art. 11 (business continuity and disaster recovery), DORA Art. 15 (ICT business continuity testing), DORA Art. 17 (incident management), and DORA Art. 45 (voluntary information sharing arrangements)
- ENISA Multilayer Framework for Good Cybersecurity Practices for AI (June 2023)
- TIBER-EU (updated January 2025, aligned with DORA regulatory technical standards on threat-led penetration testing, including mandatory purple team exercises).
Focus on October 31: How Resilient Is Your Organization?
The October 31 deadline is fast approaching, and the requirements go well beyond mere regulatory compliance.
How well is your institution prepared for the new speed asymmetry? Which of the six areas of action have already been effectively implemented? Where is there still a specific need for action?
We would be happy to discuss how the ECB’s requirements can be translated into a prioritized and actionable plan. Please contact our experts.
References
ECB, “Addressing AI-enabled Cybersecurity Threats” (July 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 blog post (August 2026) – https://www.crowdstrike.com/en-us/blog/crowdstrike-2026-threat-hunting-report/
ENISA, “Cybersecurity in the Frontier AI Era” (July 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 (June 2023) – https://www.enisa.europa.eu/publications/multilayer-framework-for-good-cybersecurity-practices-for-ai
ESRB, Warning on Systemic Cyber Risks Stemming from Frontier AI Models (June 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 (March 2026) – https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2026/
TIBER-EU Framework (updated January 2025) – https://www.ecb.europa.eu/paym/cyber-resilience/tiber-eu/html/index.en.html
Regulation (EU) 2022/2554, Digital Operational Resilience Act (DORA) – https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng
Regulation (EU) 2024/1689, Artificial Intelligence Act (EU AI Act) – https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng
Regulation (EU) 2024/2847, Cyber Resilience Act (CRA) – https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng
