ESAs publish statement on ICT risks arising from frontier AI
The European Supervisory Authorities EBA, EIOPA and ESMA are responding to the growing cyber risks associated with particularly powerful AI models. In their joint statement of 31 July 2026, “Toward a consistent and risk-based approach for ICT risks from frontier AI models” (ESA JC 2026 25), they explain how financial entities should adapt their ICT risk management frameworks to AI-enabled threats. The paper does not create any new or binding legal obligations, but it is relevant to supervisory practice: the ESAs clarify how the existing technology-neutral requirements of the Digital Operational Resilience Act (DORA) should be applied in light of a changing cyber threat landscape.
Table of Contents
Frontier AI as an accelerator of existing cyber risks
The paper follows on from the EU Action Plan on the Cybersecurity of Artificial Intelligence of 7 July 2026, a warning by the European Systemic Risk Board and recommendations by the European Union Agency for Cybersecurity (ENISA). Its aim is to raise awareness among financial entities of the changing cyber risk dynamics resulting from particularly powerful AI models, while at the same time promoting a consistent, cross-sectoral and risk-based supervisory approach.
The supervisory authorities use the term “Frontier AI Models” to refer to particularly advanced AI models whose capabilities are close to, match or exceed the current state of the art. The focus is not solely on the use of AI by financial entities themselves. Rather, a key consideration is that such models can also be used by attackers.
The ESAs do not assume that frontier AI will necessarily give rise to entirely new categories of cyberattacks. Instead, the principal issue lies in the speed, scalability and complexity of already known forms of attack.
Powerful AI models can, for example, assist attackers in:
- automatically identifying and exploiting vulnerabilities;
- analysing published patches and reconstructing the underlying vulnerabilities;
- combining several smaller security vulnerabilities into complex attack chains;
- analysing source code and technical configurations;
- identifying single points of failure;
- targeting shared infrastructures; and
- attacking numerous entities or systems simultaneously.
From a legal perspective, this assessment is significant because DORA is linked to the ICT risk that exists at any given time. The adequacy of an ICT risk management framework cannot be assessed solely on the basis of whether it complied with regulatory requirements when it was introduced. If the relevant threat landscape changes significantly, the financial entity must assess whether its processes, controls and response times remain adequate.
Interaction between DORA and the AI Act
The statement regards DORA and the AI Act as complementary regulatory frameworks. Among other things, the AI Act contains specific obligations for providers of general-purpose AI models with systemic risk. These include, for example, risk assessments, technical documentation, reporting of serious incidents and cybersecurity measures.
DORA, by contrast, focuses on the ICT risk and digital operational resilience of the financial entity. A particularly powerful AI model may therefore simultaneously be subject to obligations imposed on the model provider under the AI Act and form part of the ICT risk management of the financial entity using it under DORA.
The provider’s compliance with the AI Act does not replace the financial entity’s DORA risk assessment. Conversely, DORA does not give rise to a general obligation to replicate contractually all AI Act obligations addressed to the provider.
In practice, the roles and the respective use case must therefore first be clarified:
- Is the financial entity a provider or deployer of the AI system, and is it potentially subject to additional obligations arising from that role under the AI Act?
- Does the service also constitute an ICT service within the meaning of DORA?
- Does the service support a critical or important function?
- Which obligations apply directly to the AI provider?
- Which risks remain with the financial entity?
- What information and contractual rights does the financial entity require in order to fulfil its own obligations under DORA?
Only on this basis can it be determined which regulatory and contractual measures are actually required.
DORA does not prescribe an exhaustive catalogue of technical measures for every conceivable technology. Instead, it requires financial entities to continuously identify, assess, manage and monitor their ICT risks. Cyber threats amplified by frontier AI therefore do not constitute a separate new category of risk outside DORA. They must be taken into account within the existing ICT risk management framework insofar as they change the financial entity’s risk profile or call into question the adequacy of existing controls.
Three areas for supervisory action
The ESAs structure their expectations around three risk mitigation strategies:
- prevention;
- detection; and
- management of cyber risks and operational resilience.
This three-part structure maps potential measures to existing ICT risk management obligations under DORA.
1. Prevention: inventories, architecture and patch management
According to the ESAs, the starting point for appropriate prevention is a complete and continuously updated ICT asset inventory. This should cover not only infrastructure and applications but also data assets, APIs and AI and machine-learning components.
From a legal perspective, this relates in particular to Article 8 DORA and the more detailed requirements of Commission Delegated Regulation (EU) 2024/1774 (RTS RMF). The key supervisory point is that a simple inventory is not sufficient. The financial entity must understand the criticality of its assets, their exposure and their interdependencies. Particularly relevant are dependencies on:
- cloud infrastructures;
- software libraries and open-source components;
- external APIs;
- DNS and network services;
- outsourced Security Operations Centres;
- shared platforms; and
- subcontractors of ICT third-party service providers.
The statement therefore places particular emphasis on the risk of cascading disruptions. Where several critical processes depend on the same technical component or service provider, a single vulnerability may have far-reaching consequences.
Further measures concern security and resilience by design, network segmentation, zero-trust approaches, protection of source code, reduction of unnecessary attack surfaces and the decommissioning of legacy systems.
Patch management is particularly relevant. The ESAs assume that AI-enabled attacks may significantly shorten the time between a vulnerability becoming known and its exploitation. For particularly exposed or critical systems, this may require greater automation and acceleration of patching processes.
However, this does not result in a general legal obligation to install all patches fully automatically. Automated processes can themselves create operational and availability risks. A risk-based assessment therefore remains necessary, taking into account, among other things, testing procedures, rollback capabilities, redundancies, fallback solutions and monitoring.
2. Detection: are periodic controls still sufficient?
In the area of detection, the ESAs question the adequacy of exclusively periodic control models. AI-enabled attacks can be dynamically adapted and carried out at high speed. Significant periods of exposure may therefore arise between individual vulnerability scans or compliance reviews.
The ESAs identify the following as possible responses:
- continuous or more frequent vulnerability scanning;
- comprehensive logging;
- behavioural monitoring and anomaly detection;
- detection of lateral movement;
- deception techniques;
- more frequent security and compliance reviews; and
- AI-enabled support for Security Operations Centres and red teams.
Again, these do not constitute a general minimum standard applicable to all financial entities. Article 4 DORA continues to require proportionate implementation. The frequency and depth of monitoring must be appropriate to the criticality, exposure and complexity of the respective systems.
From a legal perspective, the justification for the frequency of controls therefore becomes particularly relevant. For critical or important functions, publicly accessible interfaces or complex cloud environments, monitoring carried out only at long intervals may be difficult to justify.
Financial entities should therefore document the criteria used to determine the frequency and scope of their monitoring measures and the circumstances in which an event-driven reassessment is carried out.
3. Management of cyber risks and operational resilience
The third area concerns incident response, business continuity, recovery and digital operational resilience testing.
The ESAs point out that existing contingency and recovery plans are often designed around the failure of individual systems or linear attack patterns. Frontier AI, by contrast, may facilitate the simultaneous exploitation of multiple vulnerabilities and attacks on interdependent systems. Financial entities should therefore assess whether their scenarios adequately cover, in particular:
- simultaneous disruption of multiple systems;
- failure of shared infrastructure;
- compromise of primary, backup and disaster recovery systems;
- failure of a cloud, DNS, API or security service provider;
- cascading disruptions along the ICT supply chain; and
- significantly shortened response and escalation times.
Implications for ICT third-party risk management
The ESAs pay particular attention to the supply chain. AI-enabled attacks can specifically identify the weakest link within a complex ICT supply chain. Relevant parties include not only direct ICT third-party service providers but also subcontractors, cloud infrastructures, software and hardware manufacturers, APIs and open-source components.
Financial entities should therefore assess whether their risk analyses under Article 28(4) DORA adequately take account of these new attack scenarios. In the case of ICT services supporting critical or important functions, this may result in higher requirements for due diligence, ongoing monitoring and exit planning.
The ESA statement is likely to influence the risk assessment of ICT third-party service providers and, consequently, the additional security and information obligations negotiated on a risk-based basis. Financial entities are likely to request more detailed information from ICT and AI service providers on the following matters:
- governance of model development and deployment;
- security and resilience of the underlying infrastructure;
- known model limitations and failure modes;
- vulnerability and patch management;
- incident detection and incident reporting;
- dependencies on cloud providers and other subcontractors;
- business continuity and disaster recovery procedures; and
- auditability and evidence of implemented controls.
However, this does not give financial entities the right to impose every conceivable security measure indiscriminately on every ICT service provider. Contractual requirements must also be aligned with the specific risk of the service, its criticality and the principle of proportionality. Particularly from a provider perspective, it therefore remains important to distinguish carefully between contractual provisions actually required by DORA and additional commercial or security requirements.
The management body remains responsible
The statement expressly emphasises the responsibility of the management body. It should ensure that clear governance and accountability structures are in place, that adequate resources are available and that the entity’s ability to respond keeps pace with developments in the threat landscape.
In particular, the ESAs recommend reviewing the Risk Appetite Framework. Existing metrics, risk tolerances and controls should be examined to determine whether they reflect AI-related changes in cyber risk. This concerns both the entity’s own use of AI models and indirect exposure through service providers and external infrastructures.
The statement illustrates the expectations that the ESAs associate with management body responsibility under Article 5 DORA in light of the changing threat landscape. The management body does not have to manage every technical detail itself, but it must be capable of understanding the key risks, dependencies and deficiencies, setting appropriate priorities and overseeing the provision of sufficient human and financial resources.
Particularly relevant is the ESAs’ call to move from merely periodic consideration to continuous, informed decision-making. This is likely to affect the content, frequency and escalation logic of ICT risk reporting.
Significance for the annual review of the ICT risk management framework under Article 6(5) DORA
The statement is particularly relevant to the review of the ICT risk management framework required at least annually under Article 6(5) DORA. Further details concerning the content and form of the report on this review are set out in Article 27 of Commission Delegated Regulation (EU) 2024/1774.
The review must not be limited to a formal comparison of existing policies with DORA requirements. It must also assess whether the framework remains appropriate and effective in light of the current risk environment and the entity’s actual operational organisation.
The ESA statement documents a new, or at least significantly intensified, supervisory assessment of the risks. It therefore lends itself as an input for the next review.
The report should, at a minimum, address in a comprehensible manner:
- whether and to what extent the financial entity is exposed to cyber risks related to frontier AI;
- whether the internal threat landscape and ICT risk analysis have been adjusted;
- which systems, interfaces and third-party providers may be particularly affected;
- whether existing patching, monitoring and escalation cycles remain appropriate;
- whether multi-system failures and supply-chain scenarios are adequately reflected in BCM and testing;
- whether the Risk Appetite Framework and risk tolerances need to be adjusted;
- which measures have been decided upon or prioritised; and
- why individual measures contained in the Annex are not relevant or proportionate.
There is no legal requirement to provide an affirmative declaration that all measures in the Annex have been implemented. What is required is a robust, risk-based and documented consideration of those risks that are relevant to the entity.
Practical relevance of the Annex
The greatest practical value is arguably provided by the Annex, “Examples of risk mitigation strategies and actions”. In it, the ESAs describe a total of 16 areas for action, organised according to the three strategies of prevention, detection, and risk management and operational resilience. For each area, they first describe the risk intensified by frontier AI and then identify possible countermeasures.
The Annex is neither exhaustive nor legally binding. The ESAs expressly clarify that it does not establish additional requirements and should not be understood as a comprehensive compliance checklist. Rather, the measures should be assessed taking into account the size, complexity, interconnectedness and risk exposure of the financial entity. They may also serve as a basis for dialogue with ICT third-party service providers.
The following examples and mitigation measures are recommended by ESAs.
https://www.esma.europa.eu/sites/default/files/2026-07/JC_2026_25_ESA_statement_on_frontier_AI_models.pdf
| Strategy | Risk | Potential actions to consider |
| Implement automated security controls into development, deployment, and operational workflows | Traditional static security models may not be able to respond timely to AI-enhanced attacks as they rely on predefined rules, signatures, and fixed patterns, while AI-driven threats are dynamic and adaptive. | As referred to in Article 10 of the RTS RMF, measures may range from basic automated vulnerability scanning and patch management to (AI-augmented) “DevSecOps” (Development, Security, and Operations) practices, across the ICT-System lifecycle. |
| Implement security and resilience by design principles | AI’s ability to analyse and exploit architectural flaws (such as poorly secured APIs, excessive permissions, or monolithic system designs) further emphasizes the need to embed security and resilience into systems from the outset. |
Implement basic secure design principles, threat modelling, for critical systems and network segmentation, evolving towards more advanced techniques like zerotrust architectures and AI-driven threat modelling. |
| Protect confidentiality of source code | Highly capable AI-models can analyse leaked or exposed source code to identify vulnerabilities, backdoors, or proprietary algorithms, or even attempt to reverse engineer protected code in search of known vulnerabilities. |
Protect proprietary source code and critical configuration confidentiality to reduce the attack surface available for automated discovery, slow down reconnaissance, improve the effectiveness of deception operations and limit the ability to exploit application weaknesses quickly and systematically. |
| Reduce the attack surface | A larger attack surface provides more entry points for cyberattacks, which highly capable AI models may rapidly scan and analyse to identify weak spots, misconfigurations, or unpatched vulnerabilities at scale. The broader and more complex the attack surface, the easier it is for AI-powered adversaries to find and prioritize exploitable targets quickly. | Eliminate unnecessary exposures, enforcing segmentation, and decommissioning legacy systems. This can be achieved by applying, as a minimum, basic hygiene measures (e.g., inventory management), and evolving into more advanced techniques like AI-driven attack surface management. |
| Proactive and automated patches for high/risk systems across all environments | AI-driven attacks operate at machine speed, enabling vulnerability detection and exploitation in a very short time span. Traditional patching processes relying on periodic and reactive approach may not be sufficient to ensure a timely reaction. | Following a risk-based approach investigate proactive and automated patch processes for high-risk systems and patches, and aim towards extending these processes to all environments, including disaster recovery (DR) and backup systems. Consider newly introduced or enhanced risks and ensure sufficient mitigating controls, such as clear criteria for which patches and systems to include, sufficient (automated) testing, monitoring, the deployment schedule, redundancies, or robust fallback plans and rollback procedures. |
| Ensure that access management minimises permissions and reduces the likeliness of unauthorised access | AI-driven attacks can bypass controls based on traditional methods, such as static passwords or perimeter-based security, mimic legitimate behaviour, and exploit trust relationships faster than legacy defences can respond. |
The risk toolkit includes strict access controls, continuous monitoring, and multi-factor authentication (MFA) to limit the impact of breaches; as the maturity of the control environment grows, foundational requirements like basic MFA and least-privilege access may evolve into advanced techniques like behavioural analytics and just-in-time (JIT) access. |
| Assess, monitor, and enforce cybersecurity standards across the whole supply chain | In a supply chain attack, an attacker may compromise an entity through an ICT third-party service provider; this can be further exploited by sophisticated AI models, which can identify weak links in the supply chain and automate multi-stage attacks. |
Assess, monitor, and enforce cybersecurity standards across the whole supply chain, with more rigorous controls for greater exposure and more complex supply chains. This includes not only services providers and partners but also soft- and hardware providers and opensource communities. |
| Strategy | Risk | Potential actions to consider |
| Apply continuous vulnerability scanning and monitoring | Periodic vulnerability scanning may no longer be sufficient in the face of AI-driven attacks, which can uncover zero-day vulnerabilities and exploit them immediately. | Employ continuous scanning and monitoring to detect and remediate weaknesses before they are exploited. Align the frequency and depth of scanning with the financial entity’s risk profile: from basic automated scans to AI-driven, realtime vulnerability management. |
| Implement comprehensive logging and behavioural monitoring while avoiding data overload | AI-assisted attackers can generate unusual activity patterns that traditional signature-based detection may miss. | Implement comprehensive logging and behavioural monitoring strategies to detect anomalies, use deception techniques, identify lateral movements, and respond to intrusions before they cause significant damage. |
| Increase the frequency of scans, tests, and compliance checks | Adaptive Angriffe können Kontrolllücken zwischen planmäßigen Prüfungen ausnutzen; jährliche Penetrationstests oder Compliance-Audits könnten daher nicht genügen. | Increase the frequency of scans, tests, and compliance checks, to keep pace with dynamic threats, moving towards continuous or near-real-time monitoring when possible |
| Strategy | Risk | Potential actions to consider |
| Update incident reporting and Business Continuity Processes frameworks to account for AI-assisted threats and multi-system failure | Incident response and business continuity plans are often designed for single-system failures or linear attack progression and may not be adequate under AI-assisted highly complex scenarios, such as the simultaneous exploitation of vulnerabilities in diverse systems. | Update and regularly test incident reporting and Business Continuity Processes frameworks for AI-assisted threats and multi-system failure, ensuring coordinated response and effective recovery. Implement strong data backup capabilities and ensure that backups are not exposed to the same risks as primary systems. |
| Execute periodic operational resilience testing and evolve the testing towards AI-enhanced threat scenarios | AI-driven attacks can trigger cascading failures across interconnected systems, disrupting operations in ways that traditional resilience tests may not anticipate. |
Operational resilience testing evolves to simulate AIenhanced threat scenarios, and financial entities should test their ability to withstand AI-assisted cyber-attacks. Scalable testing frameworks may provide a structured, but flexible threat-led approach to allow for a proportional approach to resilience testing. |
| Identify and monitor dependencies across the full ICT infrastructure | AI-driven attacks can analyse and exploit dependencies across a financial entity’s ICT infrastructure, such as software dependencies (e.g., open-source libraries, third-party APIs), infrastructure dependencies (e.g., cloud providers, DNS services) or operational dependencies (e.g., outsourced IT/SOC). | As threat actors can use AI to map these dependencies, identify single points of failure, and chain exploits for maximum impact, it is important to identify and monitor their dependencies, assess their criticality and risk, and implement measures to mitigate AI-driven exploitation. |
| Management body accountability to evolve from periodic oversight to continuous, informed decision making | AI-driven attacks target not only technical systems but also governance weaknesses, decision making gaps, and risk oversight failures. Without clear accountability at their highest level, financial entities may underestimate AI-specific risks, fail to allocate sufficient resources, or lack coordinated responses to complex, automated attack patterns. |
Evolvement of the management accountability should evolve from periodic oversight to continuous, informed engagement, integrating cybersecurity into strategic decisions and that sufficient resources are allocated to manage these risks. |
| Implement automated risk monitoring and escalation procedure | As AI-driven threats evolve rapidly, requiring real-time visibility and escalation to ensure timely response and decision-making, the frequency of risk reporting may reveal to be insufficient for detecting and mitigating AI-enhanced attacks. | Adoption of more automated monitoring processes, as well as faster and more adaptive escalation procedures, so to contain threats before they spread into wider incidents. |
| Evolve cybersecurity awareness to a more reactive and proactive mindset | AI-driven attacks can generate unusual or highly complex behavioural patterns that current security tools may not be able to identify; social engineering has also evolved the ways to target and exploit financial entities’ vulnerabilities. |
Advance cybersecurity awareness to tackle new threats; move from a purely preventive mindset to a more reactive one, empowering staff members to detect and report anomalies as a complementary element in the cybersecurity toolbox. |
The Annex containing the ESAs’ mitigation proposals should not be reinterpreted as a supposedly binding list of new minimum DORA requirements. Rather, it is a supervisory-oriented catalogue of risks and possible measures. Its value lies in applying DORA’s open and risk-based requirements to the threat landscape altered by frontier AI.
For each area for action, the financial entity should therefore consider:
- Is the risk described by the ESAs specifically relevant to the entity?
- Which existing technical or organisational controls address this risk?
- Are these controls still appropriate in view of the increased speed, scalability and adaptability of AI-enabled attacks?
- Is there a need for adjustment or remediation?
- Which of the proposed measures is suitable and proportionate for the specific risk profile?
- How is a decision not to implement a measure, or to implement it only partially, justified, approved and subsequently reviewed?
In this way, the Annex can be used in particular for the annual review of the ICT risk management framework under Article 6(5) DORA, DORA gap assessments, control assessments, BCM and testing programmes and ICT third-party management.
Outlook: frontier AI in the context of CTPP oversight
Finally, the statement contains an important indication regarding future oversight practice in relation to critical ICT third-party service providers.
The Lead Overseers have already initiated targeted discussions with relevant Critical ICT Third-Party Providers (CTPPs). In doing so, they are examining how these providers identify and assess the new risks, which safeguards they have implemented and how they make use of the defensive capabilities of powerful AI.
The insights gained are intended to feed into the annual risk assessment cycle and the prioritisation of oversight activities for 2027. The ESAs have also begun incorporating AI-related risks into their Oversight Examination Methodology. These risks are expected to be reflected in the scope of examinations and further oversight activities in 2027.
The statement is therefore more than an abstract description of risk. Its content is already being incorporated into supervisory planning and examination methodology under DORA. This is likely to shape the requirements that Lead Overseers apply to the control systems, supply-chain management and customer interfaces of Critical ICT Third-Party Providers (CTPPs) in the course of their examinations. At the same time, the providers concerned can be expected to further develop the corresponding evidence and cooperation processes vis-à-vis their financial-sector customers.
Conclusion
The new ESA statement does not create any new DORA obligations, but it changes the supervisory frame of reference for assessing whether existing ICT controls remain appropriate both when frontier AI is used and when assessing the threat landscape created by such technology. Financial entities do not have to implement every measure mentioned in the paper. They should, however, conduct and document an assessment of whether their asset inventories, patching and monitoring processes, resilience testing, BCM scenarios, third-party management and governance are keeping pace with the speed and complexity of AI-enabled attacks.
The Annex provides a particularly useful basis for this assessment. At the latest during the next review of the ICT risk management framework under Article 6(5) DORA, the ESAs’ new risk assessment should be taken into account.
