The ECB and ESRB’s wake-up call: rethinking operational resilience for frontier AI

The ESRB warning of 25 June 2026, addressed to supervising authorities, describes frontier AI models with cyber capabilities as a material change in the risk landscape for the EU financial system.¹ These models can discover vulnerabilities, generate working exploits and execute cyberattacks at a speed and scale far beyond previous AI, which the ESRB frames not as a marginal increase in cyber risk but as a paradigm shift with systemic consequences.

The ECB’s ‘Dear CEO’ letter of 7 July 2026 turns that systemic concern into a direct supervisory ask.² Banks are expected to assess the evolving threat landscape without delay and to develop a comprehensive action plan covering concrete measures, resources, governance and implementation timelines. The required areas of focus include:

• accelerate vulnerability and patch management at scale
• enhance monitoring, detection and AI-enabled defensive capabilities
• verify that third-party risk management is fit for purpose in the current situation, in light of the role of ICT service providers in critical supply chains
• reinforcing defence-in-depth and cyber hygiene, and modernising infrastructure by replacing or updating legacy, unsupported or end-of-life technologies
• improving operational resilience through response and recovery mechanisms, including crisis management, as well as information sharing arrangements

 

---

Key date

ECB-supervised significant institutions must submit their frontier-AI cyber action plan to their Joint Supervisory Team (JST) by 31 October 2026.³ To create room, the ECB is postponing its annual IT Risk Questionnaire from September 2026 to February 2027 and has said it will address quantum-computing risk in a separate letter in due course.⁴ Although less significant institutions are not in scope of this exercise, they should carefully consider these requirements as national competent authorities routinely mirror SSM expectations and as they are facing the same threats.

---

The Digital Operational Resilience Act (DORA) has already created a common regulatory architecture for digital operational resilience, covering:

• ICT risk management;
• ICT-related incident management, classification and reporting;
• digital operational resilience testing;
• ICT third-party risk management;
• information-sharing arrangements.

The ECB and ESRB publications suggest the framework must now be recalibrated to operate fast enough.

 

Why this matters now

Cyber-resilience frameworks assume a relatively stable rhythm: vulnerabilities are identified, triaged, tested, patched and reported through defined governance. Critical patches can be accelerated, but remediation still depends on release windows, change-approval boards, vendor dependencies and risk-acceptance workflows.

Frontier AI compresses the time between vulnerability discovery and exploit weaponisation. Google’s Threat Intelligence Group has tracked the mean time to exploit falling from 63 days in 2018 to roughly minus seven days in its 2026 M-Trends estimate⁵ (time-to-exploit being measured against patch availability, a negative figure means the vulnerability has been exploited before the patch exists).

The ESRB identifies this collapse of defensive time buffers as a key source of increased ICT risk, alongside the pressure on defenders, the concentration risk from dependence on a few AI and cloud providers, and the need for authorities to recalibrate stress testing and supervisory expectations.

 

What Project Glasswing tells us

As we set out in our earlier analysis, Project Glasswing offers a useful illustration of the strategic signal.⁶ Announced on 7 April 2026, Anthropic’s restricted programme gave selected defenders, including major technology providers and financial institutions, early access to an unreleased frontier model, Claude Mythos Preview, for defensive work.⁷

Anthropic reported that the model had identified more than 10,000 high- and critical-severity zero-day vulnerabilities across critical infrastructure, with access controlled to help defenders secure software before comparable capabilities spread more widely.

These claims warrant caution since the figures are vendor-reported and have not been independently verified. Nevertheless, the direction of travel matches the ESRB warning and the ECB’s concerns. If AI materially cuts the cost, time and expertise needed to find vulnerabilities and build exploits, institutions cannot keep managing cyber risk through slow remediation cycles and governance designed for a different threat environment.

The answer is a shorter cyber risk cycle, in which patch velocity, exploitability and response latency become central resilience variables. The challenge is as much organisational as technical: the weakest link may no longer be the security control itself, but the time needed to decide, escalate, coordinate and act.

This is also why the ESRB frames the issue as systemic. Frontier AI amplifies shared dependencies across cloud providers, operating systems, open-source components, ICT service providers and payment infrastructures. If the same vulnerability or supplier is embedded across numerous institutions, AI-enabled exploitation could generate simultaneous pressure across the sector. The sector has already seen how fast a single shared dependency can propagate: the CrowdStrike outage of 19 July 2024, when a faulty update disabled an estimated 8.5 million Windows machines worldwide and hit banks, airlines and hospitals at once, showed how a protective tool can become a common point of failure.⁸

 

DORA remains the foundation, but not the full answer

DORA compliance is not the same as AI-era resilience.
The first wave of DORA implementation was necessarily document-heavy: policies, registers, incident classification, reporting templates and test plans. That groundwork, though essential, may not hold under high-speed, high-volume conditions, and in effect the ECB letter shifts the basis of assessment from design effectiveness (is it well documented?) to operating effectiveness (does it work under pressure?).

The next round of scrutiny, as both warnings imply, will be less about whether the documentation exists and more about whether the framework holds under pressure. Banks should ask whether their DORA framework can answer some uncomfortable questions:

• Can the institution identify all internet-facing, externally exposed and critical internal assets with sufficient accuracy?
• Can it determine which vulnerabilities are actually reachable, exploitable and connected to critical or important functions?
• Can it detect exploitation attempts across its estate, with enough telemetry coverage and a short enough mean time to detect, when an attacker moves at machine speed?
• Can it patch or mitigate critical exposures in days rather than weeks while maintaining operational stability?
• Can it classify and report a major ICT incident within DORA’s deadlines (initial notification four hours from classification and 24 hours from detection, intermediate report within 72 hours, final within one month) when the incident unfolds faster than the paperwork?
• Can it obtain the same urgency and transparency from its ICT providers, and can crisis teams make risk decisions fast enough when remediation cannot be immediate?
• Can the board see whether risk-appetite metrics still reflect the changed threat environment?

If the answer to any of these is unclear, the bank’s DORA framework may be formally present but operationally under-calibrated.

---

The ESA statement adds a supervisory convergence layer
On 31 July 2026, the European Supervisory Authorities (EBA, EIOPA and ESMA) published a joint statement calling for a consistent and risk-based approach to ICT risks stemming from frontier AI models⁹. In this paper, the ESAs confirm that DORA and the AI Act provide the regulatory foundation but argue that shorter vulnerability discovery and exploitation cycles require financial entities to act faster and adapt their cybersecurity capabilities.

Their proposed response, which is not limited to significant banks but includes all institutions with proportionality principles, is structured around three mitigation strategies:

• Prevention: through continuously updated asset inventories, secure-by-design principles, proactive patching and dependency-risk assessment
• Detection: through continuous vulnerability scanning, monitoring, behavioural analytics and AI-enhanced SOC or red-teaming capabilities
• Management: through operational resilience testing, updated business continuity and incident response frameworks, stronger backup and recovery capabilities, and management-body accountability.

The statement points out that, as Lead Overseers under DORA, the ESAs have started targeted engagement with Critical ICT Third-Party Providers and will embed AI-related risks into their 2027 oversight work. It also provides illustrative, non-binding examples of mitigation actions to help financial entities and supervisors structure a proportionate dialogue around prevention, detection and operational resilience measures.

---

 

What to do now

The priority is to turn these signals into an executable agenda that stress-tests the existing DORA framework against risks evolving at AI speed. For a significant institution, that means a credible plan rather than a generic statement: one that can withstand JST scrutiny with a clear view of current exposure, priority gaps, remediation actions, accountable owners, budgets, timelines, dependencies and evidence standards, anchored by the four workstreams below.

1. Vulnerability and patch management.
   Current processes were designed for stable remediation queues, which no longer fits the threat. Institutions need to separate routine patching from critical-exposure remediation, since a critical vulnerability on an internet- or customer-facing system cannot sit in the backlog like any other ticket. Prioritisation that leans mainly on severity scores needs sharpening: complement CVSS with exploitability intelligence (EPSS probabilities, the CISA Known Exploited Vulnerabilities catalogue and vendor threat intelligence) and reachability analysis. This is the continuous threat exposure management (CTEM) pattern, asking not only how severe a vulnerability is but whether it is reachable, exposed, weaponisable and connected to a critical or important function.¹⁰ Patch and exception cycles then need redesigning around that distinction, giving critical internet-facing assets, cloud workloads, privileged-access infrastructure and systems supporting critical functions faster remediation paths, clearer emergency-change procedures, stronger compensating controls and explicit executive risk acceptance where patching cannot be immediate.
   
   
2. Third-party and concentration risk.
   AI-enabled vulnerability discovery raises the bar for supplier readiness. Banks need better visibility into critical providers, subcontractors, software components and cloud dependencies, with stronger evidence that suppliers can disclose, patch, communicate and recover at the pace now required. Financial institutions should therefore treat the register of information not as a static regulatory deliverable, but as a live management tool for monitoring dependency risk. This should be supported by stronger contractual mechanisms under DORA Article 30¹¹ and the subcontracting RTS, enhanced software-component transparency through Software Bills of Materials, and explicit SLAs covering vulnerability disclosure, patch availability and remediation timelines.
   
   
3. Resilience testing.
   Testing must move to a more continuous and adversarial footing. Institutions should move from the current DORA’s threat-led penetration testing (TLPT) regime based on a 3-year cycle¹² to a more cadenced and realistic TLPT framework with Scenarios should include emergency patch waves, zero-day exploitation, destructive ransomware, simultaneous cloud or SaaS disruption, privileged-access compromise and third-party contagion, and they should measure not just technical recovery but escalation speed, regulatory reporting, decision rights, customer communication and whether the institution stays within its tolerance for ICT-related disruptions.
   
   
4. AI-enabled resilience.
   The temptation to fight fire with fire and adopt AI-enabled defence is strong, and not misplaced: AI can help with code review, vulnerability discovery, configuration analysis, threat hunting, detection engineering and incident response. But as the ECB makes explicit, these capabilities must be governed with adequate safeguards and embedded into the control environment with defined use cases, human oversight, data-protection and access controls, validation, auditability and clear accountability. Ultimately AI defensive tooling becomes part of the regulated estate itself and must comply with subsequent regulatory requirements such as EU AI Act and model-risk obligations.

Over the longer term, banks will also need to fold quantum computing and post-quantum cryptography into the roadmap (the ECB will address quantum risk in a separate letter, so it sits outside the October plan). NIST finalized its first post-quantum standards (FIPS 203, 204 and 205) in August 2024, and the EU’s coordinated roadmap targets quantum-safe migration of high-risk use cases, financial services among them, by end-2030 (with broader completion by 2035).¹³ The reason not to wait is ‘harvest now, decrypt later’: long-lived sensitive data captured today can be decrypted once a capable quantum computer exists. As such, institutions should already be mapping where cryptography sits, which data has long-term sensitivity, where crypto-agility is weak and how suppliers plan to transition.

 

How Capco helps institutions move faster

For a significant institution, the practical question is clear: will the plan withstand JST scrutiny, and can the bank remediate a critical vulnerability in days rather than weeks?

Capco supports a compliance-ready action plan, translating regulatory expectations into concrete actions, accountable owners, timelines, investment and evidence standards, so senior management and the ECB have a credible view of what will change. Building on our earlier article on the shorter cyber risk cycle, that support spans several areas.⁶

Build patching programmes for a faster threat cycle: we redesign vulnerability-management programmes so critical exposures move through faster decision and remediation paths, tightening patch governance, reducing exception drag and strengthening compensating controls where immediate patching is not feasible.

Prioritise what is actually exploitable: we move clients from broad backlogs to exploitability-based prioritisation, focusing on the exposures most likely to cause disruption, data compromise, fraud or control failure and linking remediation to business criticality and attack paths.

Reduce reaction time across the control environment: we cut decision latency across cyber, technology, risk and operations, clarifying escalation paths, defining trigger-based response actions and strengthening playbooks for high-velocity scenarios.

Move to AI-enabled cyber operations: we help clients evaluate the cyber and resilience implications of adopting AI services and AI-enabled security tools, then embed them across cybersecurity programmes in a governed, scalable way.

ICT third-party and supply-chain assurance: we help clients improve the Register of Information, map critical functions to ICT dependencies, test supplier readiness for accelerated disclosure and patching, and strengthen contractual and exit provisions.

Enhanced resilience testing: we help clients design and facilitate high-velocity exercises across the CISO, CIO, COO, CRO, legal, communications, procurement and business lines, testing whether the institution can decide and recover within its disruption tolerances when the threat cycle accelerates.

 

 

 

References
^1. ESRB warning (ESRB/2026/3), 25 June 2026: https://www.esrb.europa.eu/pub/pdf/warnings/esrb.warning260625_on_systemic_cyber_risks_stemming_from_frontier_ai_models~ef424708cf.en.pdf. Legal basis: Regulation (EU) No 1092/2010 (ESRB Regulation), Article 16.
^2. ECB ‘Dear CEO’ letter, Addressing AI-enabled cybersecurity threats, 7 July 2026: https://www.bankingsupervision.europa.eu/press/letterstobanks/shared/pdf/2026/ssm.2026_letter_on_AI_enabled_cybersecurity_threats.en.pdf
^3. 31 October 2026 deadline per the ECB letter (ref. 2); see also ESRB/ECB press release of 7 July 2026: esrb.europa.eu/news/pr/date/2026/html/esrb.pr260707~4e1b68241a.en.html. On significant-institution status: bankingsupervision.europa.eu/framework/supervised-banks/criteria/html/index.en.html
^4. ECB letter (ref. 2); coverage: https://www.mondaq.com/germany/compliance/1815838/ecb-requires-significant-institutions-to-address-ai-enabled-cybersecurity-threats
^5. Google Threat Intelligence Group / Mandiant, on time-to-exploit methodology and 63-day baseline: https://cloud.google.com/blog/topics/threat-intelligence/time-to-exploit-trends-2023; negative TTE figure from M-Trends 2026: helpnetsecurity.com/2026/03/24/mandiant-m-trends-2026-report/
^6. Capco, Anthropic Glasswing signals shorter cyber risk cycles: https://www.capco.com/intelligence/capco-intelligence/anthropic-glasswing-signals-shorter-cyber-risk-cycles
^7. Anthropic, Project Glasswing (announced 7 April 2026): https://www.anthropic.com/project/glasswing
^8. CrowdStrike outage, 19 July 2024, CISA alert: cisa.gov/news-events/alerts/2024/07/19/widespread-it-outage-due-crowdstrike-update
^9. https://www.eba.europa.eu/sites/default/files/2026-07/9c0d597c-79ff-482f-a3fe-d9ad66e96bac/JC%202026%2025_ESA%20Statement%20on%20frontier%20AI%20models_.pdf
^10. EPSS (FIRST): first.org/epss/. CISA Known Exploited Vulnerabilities catalogue: cisa.gov/known-exploited-vulnerabilities-catalog. CTEM: Gartner, Continuous Threat Exposure Management.
^11. DORA, Regulation (EU) 2022/2554, Article 30, and the RTS on subcontracting of ICT services supporting critical or important functions (see EUR-Lex).
^12. DORA, Regulation (EU) 2022/2554, Articles 26–27 (threat-led penetration testing); TIBER-EU framework: ecb.europa.eu/paym/cyber-resilience/tiber-eu/html/index.en.html
^13. NIST post-quantum cryptography standards (FIPS 203/204/205, August 2024): csrc.nist.gov/projects/post-quantum-cryptography. EU Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography (NIS Cooperation Group, June 2025): digital-strategy.ec.europa.eu/en/news/survey-eu-roadmap-post-quantum-cryptography