ECB Cyber Resilience AI Deadline: The Complete Guide

"ECB Cyber Resilience AI Deadline" is a search that conflates three different regulatory instruments. Letter SSM-2026-0301, "Addressing AI-enabled cybersecurity threats", signed by Claudia Buch, Chair of the ECB Supervisory Board, dated 7 July 2026, is a supervisory communication requiring eurozone banks to submit a comprehensive action plan by 31 October 2026. It is not a regulation. The EU Cyber Resilience Act (Regulation (EU) 2024/2847) is a full regulation with phased application: the vulnerability-reporting obligation under Article 14 applies from 11 September 2026, and the balance of essential cybersecurity requirements applies from 11 December 2027. The EU AI Act (Regulation (EU) 2024/1689) is a full regulation with phased application through 2 August 2027.

Underneath the three regulatory instruments sits a single systemic-risk assessment. On 25 June 2026, the European Systemic Risk Board adopted Warning ESRB/2026/3 on "systemic cyber risks stemming from frontier artificial intelligence models", naming Frontier AI Models (FAIMs) as the driver of the escalation. The specific deadlines matter, but they all point at the same underlying obligation: continuous testing evidence against AI-class attacks. The deadlines expire; the obligation stays.

Ethiack's agentic AI pentester Hackian is one way organisations produce that continuous testing evidence, with reproducible proof of exploit for every validated vulnerability. This guide untangles all three instruments, gives you the definitive comparison table, walks through what each requires, and shows which one applies to your organisation and when.

Key takeaways

• Three different instruments, one underlying systemic-risk assessment (ESRB Warning ESRB/2026/3, 25 June 2026), one shared obligation: continuous testing evidence against AI-class attacks
• ECB AI Cybersecurity Action Plan: Letter SSM-2026-0301 (7 July 2026, Claudia Buch), a supervisory communication (not a legislative act) addressed to eurozone significant institutions; 31 October 2026 deadline; no direct fines but SREP consequences (Pillar 2 capital add-ons, remediation orders)
• The ECB letter's Annex 1 identifies six focus areas the action plan must cover: attack surface protection, vulnerability and patch management at scale, monitoring and detection, governance and supply chain assurance, defence-in-depth and infrastructure modernisation, operational resilience and information sharing
• EU Cyber Resilience Act (Regulation (EU) 2024/2847), entered into force 10 December 2024: two enforcement moments matter. Article 14 vulnerability-reporting obligation applies from 11 September 2026 with fines up to €15M or 2.5% of worldwide annual turnover. Essential cybersecurity requirements, CE marking, and their corresponding fines apply from 11 December 2027
• CRA reporting mechanism: manufacturers submit through the Single Reporting Platform (SRP), a single electronic system established under Article 16 and operated by ENISA. A single submission routes simultaneously to the designated CSIRT coordinator and to ENISA
• CRA SME exception: under Article 64(10)(a), microenterprises and small enterprises (as defined in EU Recommendation 2003/361/EC) are exempt from administrative fines for failure to meet the 24-hour early warning deadline. The reporting obligation itself still applies
• EU AI Act (Regulation (EU) 2024/1689): AI-system providers and deployers, phased application through 2 August 2027, fines up to €35M or 7% of worldwide annual turnover
• The practical answer: map your organisation to which of the three instruments apply, on what timeline
• Common overlap: continuous testing evidence (adversarial exposure validation, BAS, red teaming) satisfies parts of all three
• Common gap: none of the three fully covers AI-model internals testing (weights, training data); pair with a model-testing specialist for that layer

Why now: the ESRB warning on Frontier AI Models

The three regulatory instruments did not emerge in isolation. On 25 June 2026, the European Systemic Risk Board adopted Warning ESRB/2026/3, published in the Official Journal as C/2026/3795, on "systemic cyber risks stemming from frontier artificial intelligence models". The warning is the systemic-risk assessment that gives the ECB letter its direction and frames all three regulatory instruments in this guide.

The ESRB warning names Frontier AI Models (FAIMs) as the specific driver of the risk escalation. FAIMs are highly capable in the cybersecurity domain, able to validate vulnerabilities and craft working exploits at speed, scale and accuracy rivalling leading human experts. The warning quantifies the shift starkly: "The crafting of weaponised exploits was previously largely done manually and took human experts days or weeks, whereas it can now be done by FAIMs in a matter of minutes or hours." That collapse of the defensive time buffer is the systemic signal all three instruments answer.

Three asymmetries in the ESRB warning frame the supervisory concern. First, the geographical asymmetry between EU and third-country jurisdictions, given the concentration of leading AI providers outside the Union. Second, the asymmetry between attackers and defenders, as FAIMs reduce the cost of admission for offensive operations while defenders remain constrained by regulatory obligations. Third, the asymmetry between well-resourced and less well-equipped financial institutions.

The three regulatory instruments each respond to a different facet of this systemic risk. Letter SSM-2026-0301 covers eurozone banking supervision. The CRA covers products with digital elements sold in the EU, including AI-embedded products. The EU AI Act covers AI systems specifically, with a four-tier risk classification. Together, they form the EU's coordinated regulatory response to the FAIM-driven cyber threat landscape.

The three deadlines at a glance

The comparison table below is the definitive answer to the "which deadline" confusion. Rows are the three instruments; columns cover legal instrument, issuer, scope, key deadlines, consequences, and continuous-testing role.

The ECB AI Cybersecurity Action Plan (deadline: 31 October 2026)

The ECB AI Cybersecurity Action Plan refers to Letter SSM-2026-0301, "Addressing AI-enabled cybersecurity threats", signed by Claudia Buch, Chair of the ECB Supervisory Board, dated 7 July 2026. It is a supervisory communication, not a legislative act, and there are no direct fines. Consequences flow through the Supervisory Review and Evaluation Process (SREP). The letter is addressed to CEOs of eurozone significant institutions (SIs), built on the Digital Operational Resilience Act (DORA).

What it requires: six focus areas

By 31 October 2026, each significant institution must submit a comprehensive action plan to its Joint Supervisory Team (JST). The action plan must contain, per the letter, "concrete measures to strengthen relevant controls, allocating the necessary resources, assigning clear roles and responsibilities, and defining timelines for implementation". The letter's Annex 1 sets out six focus areas the action plan must cover, four short-term and two structural.

Short-term focus areas (Annex 1, areas 1-4):

• Prioritise the protection of potential attack surfaces (ICT asset identification including third-party software and open-source components; minimisation and continuous monitoring of internet-facing and externally exposed assets)
• Accelerate vulnerability and patch management at scale (prioritised vulnerability validation; AI-based approaches subject to human oversight; ICT change management for rapid, risk-based remediation)
• Enhance monitoring, detection and AI-enabled defensive capabilities (strengthened monitoring of application and access logs, network traffic and other indicators of compromise)
• Strengthen governance, funding, awareness training and supply chain assurance (management-body assessment of ICT budgeting, staffing, tooling; risk appetite framework review; supply chain preparedness for accelerated vulnerability disclosure)

Structural focus areas (Annex 1, areas 5-6):

• Reinforce defence-in-depth and cyber hygiene, modernise infrastructure (segmentation, zero-trust principles, strong baseline controls, security-by-design in software development, replacement of legacy technologies)
• Improve operational resilience and information-sharing arrangements (crisis management aligned with DORA, high-speed high-volume attack exercises, secure frameworks for cross-institution cyber information exchange)

Who it applies to

Letter SSM-2026-0301 is addressed directly to significant institutions supervised by the ECB (typically banks with more than €30 billion in total assets, cross-border operations, or top-3 status in a Member State). While the letter is addressed directly to significant institutions, similar expectations are widely anticipated to extend to less significant institutions through national competent authorities, with some NCAs already issuing parallel guidance. Non-eurozone banks are not in the letter's direct scope.

What happens after 31 October 2026

Submission is the beginning, not the end. The JST engages with the bank to discuss the action plan and monitor progress. The ECB has committed to a horizontal analysis of submitted action plans to identify trends, challenges and areas for improvement, and will share conclusions with SIs. In recognition of the resource demands, the ECB has extended the annual IT Risk Questionnaire deadline from September 2026 to February 2027. See the ECB AI Cybersecurity Action Plan Complete Guide for the primary-source deep dive on Letter SSM-2026-0301, the six focus areas in full detail, SREP consequences, step-by-step compliance, and DORA integration.

The EU Cyber Resilience Act (CRA, phased application through 11 December 2027)

The EU Cyber Resilience Act (Regulation (EU) 2024/2847) is a full regulation adopted on 23 October 2024, published in the Official Journal on 20 November 2024, and entered into force on 10 December 2024 (Article 71). It targets manufacturers of products with digital elements (PDEs) placed on the EU market. Application is phased: reading the timeline correctly is what separates a compliance-ready programme from one that overstates its immediate fine exposure.

What is a product with digital elements (PDE)?

A product with digital elements is a hardware or software product whose intended and reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. The category is broader than most manufacturers assume. Connected IoT devices, smart cameras, connected vehicles, industrial controllers, mobile applications, operating systems, browsers, and software libraries all qualify. AI-containing PDEs (smart cameras with ML, connected vehicles with AI features, software libraries with ML models) are in scope.

Three application dates: 11 June 2026, 11 September 2026, 11 December 2027

Article 71 sets three application dates. On 11 June 2026, Chapter IV (Articles 35 to 51) applies: notification of conformity assessment bodies. On 11 September 2026, Article 14 applies: manufacturer reporting obligations for actively exploited vulnerabilities and severe incidents. On 11 December 2027, the balance of the Regulation applies in full: essential cybersecurity requirements (Annex I), CE marking, conformity assessment procedures, and market surveillance. Manufacturers plan against all three dates; the December 2027 date is what The full legislative text is published as EUR-Lex Regulation (EU) 2024/2847, and all article-level references in this guide (Articles 14, 16, 64(10)(a), and 71) map to the numbering in that consolidated version..

Article 14: the September 2026 reporting obligation and the 24h / 72h / 14-day cadence

From 11 September 2026, manufacturers must notify actively exploited vulnerabilities contained in their PDEs and severe incidents having an impact on the security of their PDEs. Three deadlines run from the moment of awareness. An early warning within 24 hours. A vulnerability notification (or severe-incident notification) within 72 hours, containing the general information available. A final report within 14 days for vulnerabilities (or one month for severe incidents), including a description of the vulnerability, its severity, information on any corrective or mitigating measures taken, and any measures the manufacturer recommends users to take.

Article 16: the Single Reporting Platform (SRP) mechanism

The reporting mechanism is a single-submission architecture, not parallel notifications to separate authorities. Article 16 establishes the Single Reporting Platform (SRP), a single electronic notification system operated by ENISA. A manufacturer submits a notification once, and the SRP routes it simultaneously to the designated CSIRT coordinator (determined by the manufacturer's main establishment) and to ENISA. The receiving CSIRT then disseminates the notification to other relevant CSIRTs where the manufacturer has indicated the product is made available. This replaces the pre-SRP scenario in which a multi-market manufacturer would have needed to notify each national CSIRT separately.

Product categories: default, important (Annex III), critical (Annex IV)

From 11 December 2027, the CRA classifies PDEs into three tiers by risk. Default PDEs (the majority) can self-assess conformity with essential cybersecurity requirements. Important PDEs (Annex III: identity management systems, browsers, password managers, network management systems, boot managers, and similar) can self-assess but face higher scrutiny. Critical PDEs (Annex IV: hardware devices with security boxes, smart meter gateways, smart cards, and similar categories to be specified) require conformity assessment by a Notified Body.

CE marking and conformity assessment

From 11 December 2027, the CRA requires CE marking as evidence that a PDE conforms with essential cybersecurity requirements. Manufacturers of default and important-category products self-assess and self-declare, maintaining technical documentation for market surveillance authority inspection. Manufacturers of critical-category products engage a Notified Body for third-party conformity assessment. CE marking under the CRA sits alongside (does not replace) CE marking obligations under other product-safety regulations.

Fines: two enforcement moments (September 2026 and December 2027)

Fine exposure needs to be read against the phased application timeline. From 11 September 2026, non-compliance with the vulnerability-reporting obligation under Article 14 can attract fines of up to €15 million or 2.5% of worldwide annual turnover (whichever is higher). The fines for essential cybersecurity requirements and CE marking apply from 11 December 2027. Lower fine tiers apply to other obligation breaches (up to €10 million or 2% of turnover) and to supplying incorrect or misleading information to authorities (up to €5 million or 1% of turnover). Enforcement sits with national market surveillance authorities.

SME exception: Article 64(10)(a)

Under Article 64(10)(a), microenterprises and small enterprises are exempt from fines specifically for failure to meet the 24-hour early warning deadline, though the reporting obligation itself still applies. The SME definition follows the Annex to Commission Recommendation 2003/361/EC: small enterprises are those with fewer than 50 employees and annual turnover or balance-sheet total not exceeding EUR 10 million; microenterprises are those with fewer than 10 employees and annual turnover or balance-sheet total not exceeding EUR 2 million. The carveout is narrow and specific: it applies only to the 24-hour early warning fine, not to the 72-hour notification, the 14-day final report, or any other CRA obligation.

Where AI fits into the CRA

The CRA is not AI-specific, but any PDE containing AI (smart cameras with ML, connected vehicles with AI features, software libraries with ML models) is in scope. AI-containing PDEs must satisfy the essential cybersecurity requirements plus vulnerability-handling and CE marking obligations. Where the same product is also an AI system under the EU AI Act, both regulations apply in parallel. Continuous testing evidence (application-layer exploitability validation, vulnerability discovery, coordinated vulnerability disclosure programme) supports both.

The EU AI Act (deadlines: phased through 2 August 2027)

The EU AI Act (Regulation (EU) 2024/1689) is the world's first comprehensive AI regulation. It was adopted on 13 June 2024 and entered into force on 1 August 2024. Application is phased across three years, with different obligations coming into effect at different milestones.

The four-tier risk classification

The Act classifies AI systems by risk. Unacceptable risk (social scoring by public authorities, real-time biometric identification in public spaces, cognitive behavioural manipulation) is prohibited outright. High risk (AI systems in critical infrastructure, education, employment, essential services, law enforcement, migration, justice, and Annex III categories) faces substantive obligations. Limited risk (AI systems that interact with users, generate content, or perform emotion recognition) faces transparency obligations. Minimal risk faces voluntary codes of conduct.

The phased application timeline

Four dates matter. Prohibited AI practices applied from 2 February 2025. General-purpose AI (GPAI) obligations, including model documentation, transparency to downstream deployers, and systemic-risk assessment for the largest GPAI models, applied from 2 August 2025. Most other obligations (high-risk classification, conformity assessment, transparency, governance structure) apply from 2 August 2026. Specific high-risk AI systems embedded in regulated products under existing product-safety legislation apply from 2 August 2027.

High-risk AI: Annex III

Annex III lists high-risk AI use cases: biometric identification, critical infrastructure management, education access and evaluation, employment and worker management, essential public and private services (including credit scoring), law enforcement, migration and border management, administration of justice, and democratic processes. Providers of Annex III systems must implement risk-management systems, data governance, technical documentation, human oversight, and cybersecurity measures under Article 15.

Penalties for non-compliance

Prohibited-practice violations can reach €35 million or 7% of worldwide annual turnover (whichever is higher). Non-compliance with other obligations, including for high-risk AI systems, can reach €15 million or 3% of turnover. Supplying incorrect or misleading information to authorities can reach €7.5 million or 1% of turnover. Small and medium-sized enterprises face lower fine caps proportionate to their scale.

Interaction with cybersecurity: Article 15

Article 15 requires high-risk AI systems to achieve appropriate levels of accuracy, robustness, and cybersecurity throughout their lifecycle. This includes resilience against adversarial inputs, resilience against errors, and cybersecurity measures proportionate to the risk. Continuous testing of the AI system's application layer supports Article 15; specialist model-robustness testing addresses the internals. The two are complementary rather than substitutable.

How the three interact (overlap and gap analysis)

The three instruments sit on a shared regulatory base and point to the same underlying obligation: continuous testing evidence."

The three regulatory instruments overlap and diverge in specific ways. A bank shipping an AI-driven customer app is subject to all three: Letter SSM-2026-0301 (bank-supervision layer), the CRA (the app as a PDE), and the EU AI Act (the AI system inside the app). A standalone AI SaaS company is subject to the EU AI Act primarily. A hardware manufacturer with AI-enabled products is subject to the CRA and EU AI Act. Understanding the overlaps is the difference between compliance duplication and coherent execution.

Overlap on continuous testing evidence

All three instruments point at continuous testing evidence, from different angles. Letter SSM-2026-0301 asks for it explicitly, as defensive testing against AI-class cyberattacks under the six Annex 1 focus areas. The CRA asks for it as part of vulnerability handling (from 11 September 2026) and, from 11 December 2027, as part of essential cybersecurity requirements. The EU AI Act asks for it as part of Article 15 cybersecurity obligations for high-risk AI. A well-designed continuous testing programme produces evidence artefacts that serve all three. Duplicating the programme per instrument is the opposite of good practice.

Overlap on vulnerability handling

The CRA requires manufacturers to establish vulnerability-handling processes and, from 11 September 2026, to report actively exploited vulnerabilities within 24 hours through the Single Reporting Platform. The ECB letter expects banks to demonstrate vulnerability-handling maturity as part of the AI-cyber programme (Annex 1 focus area 2, vulnerability and patch management at scale). The EU AI Act's Article 15 cybersecurity obligation implicitly requires vulnerability handling for high-risk AI. A coordinated vulnerability disclosure (CVD) programme with clear intake, triage, remediation, and reporting procedures serves all three.

Gaps and where each instrument stops

None of the three fully covers AI-model internals testing (weights, training data, adversarial robustness at the model layer). The CRA covers the product; the EU AI Act covers the AI system; Letter SSM-2026-0301 covers the bank's defensive posture. Specialist model-testing capability sits alongside and complements all three. None replaces DORA (Regulation (EU) 2022/2554) for financial-entity ICT risk management, and none replaces NIS2 (Directive (EU) 2022/2555) for critical infrastructure operators.

Which deadline applies to your organisation? (scope decision tree)

The practical question every executive needs answered: which of the three applies to us, and what is the earliest deadline we need to hit? Four organisation classes map onto the three instruments as follows.

Reading the table honestly means starting with your organisation's earliest binding deadline and working the programme backwards from there. For most banks that is 31 October 2026. For most product manufacturers it is 11 September 2026. For most AI providers it is 2 August 2026. Overlap between the three, when they all apply, is the design goal: one continuous testing programme serving multiple obligation streams at once.

What organisations need to do (step-by-step)

Six operational steps from mapping to reporting. Written for a CISO or Head of Product scoping the programme. Each step names concrete deliverables.

Step 1: Map your organisation to the three instruments

Start by identifying which of the three apply, on what timeline. Look at legal entity structure (are you an EU-supervised bank? an EU-facing product manufacturer? an AI system provider?), product portfolio (which products contain AI or fall under PDE definition?), and geographic footprint (which subsidiaries face EU market surveillance?). The mapping determines the earliest binding deadline and the scope of the programme. Legal counsel should validate the mapping.

Step 2: Assign named owners for each instrument that applies

Different instruments demand different owners. Letter SSM-2026-0301 expects a CISO or Chief Risk Officer at executive level. The CRA is typically owned by the Head of Product or VP Engineering, with security involvement. The EU AI Act is often owned by a combination of Chief Data Officer, CISO, and legal counsel. One-person accountability across all three rarely works; explicit shared responsibility with a coordinating owner does.

Step 3: Scope AI systems and PDEs in your estate

Inventory customer-facing AI (chatbots, virtual assistants, RAG-powered search), internal AI (copilots, RAG document search, agentic workflows), AI features embedded in products or services (fraud detection, KYC, credit scoring), and third-party AI dependencies (DORA Article 28 for financial entities). Separately inventory PDEs (all connected products, software libraries, mobile applications placed on the EU market). Missing internal RAG copilots and third-party AI dependencies is the most common scoping error at first submission.

Step 4: Budget for continuous testing evidence

Allocate budget across three testing modalities: adversarial exposure validation for application-layer exploitability against AI-driven services, breach and attack simulation for control efficacy, and specialist red team or manual pentesting for depth. Add coordinated vulnerability disclosure (CVD) programme costs for CRA scope. Add model-internals testing budget for EU AI Act Article 15 high-risk scope. Under-budgeting is the most common finding across all three regulator communications.

Step 5: Implement continuous testing and produce reproducible evidence

Continuous testing means dated validated vulnerabilities with reproducible proof, produced at a cadence that matches the pace of AI-service change. Adversarial exposure validation runs continuous adaptive attacks on the application layer of AI-driven services with reproducible proof of exploit for every validated vulnerability. Breach and attack simulation runs continuous scenarios against controls. Both feed a live evidence stream. TIBER-EU or equivalent set-piece red team validation sits above them on a set-piece cadence.

Step 6: Report through the required channels

Different instruments demand different reporting channels. Letter SSM-2026-0301 reports to the Joint Supervisory Team feeding the SREP. Under CRA Article 14 (from 11 September 2026), actively exploited vulnerabilities and severe incidents are reported through the Single Reporting Platform (established under Article 16 and operated by ENISA), which routes notifications simultaneously to the designated CSIRT coordinator and ENISA, on the 24-hour early warning / 72-hour notification / 14-day final report cadence. The EU AI Act reports to national market surveillance authorities and, for GPAI systemic-risk models, to the EU AI Office. Integration reduces reporting overhead; parallel silos produce contradictory evidence.

Common mistakes organisations make

Five patterns show up repeatedly in early regulator feedback and industry commentary. Avoiding them is easier than fixing them post-enforcement.

Mistake 1: Conflating the three instruments

Treating "the AI cyber deadline" as a single obligation and building one programme against a general expectation. The three instruments have different scope, different teeth, and different consequences. Programme design starts with which instruments apply, not with a generic AI-cyber posture. The disambiguation is the load-bearing intellectual work, backed by the ESRB warning's systemic-risk framing across all three.

Mistake 2: Overstating immediate CRA fine exposure

Reading the €15M / 2.5% headline as applicable to every CRA obligation from 11 September 2026. It is not. Only Article 14 (reporting) is enforceable from that date, and only the reporting fines apply to it. The essential cybersecurity requirements, CE marking, and their corresponding fines apply from 11 December 2027. Overstating immediate exposure in a board memo is a credibility risk; understating December 2027 exposure is a bigger one.

Mistake 3: Missing PDE scope on internal AI copilots

The CRA applies to products with digital elements placed on the EU market. Some organisations assume internal AI systems are out of scope. In many cases they are (internal use is not "placing on the market"), but organisations that resell, sub-licence, or embed internal AI into commercial products bring those products into CRA scope. Legal counsel should map product-to-scope carefully; edge cases are common.

Mistake 4: Treating CRA vulnerability reporting as a legal formality

The 24-hour early-warning obligation under CRA Article 14 is a real operational commitment. Manufacturers need vulnerability-intake processes, triage capability, decision authority to escalate, and Single Reporting Platform registration ready before 11 September 2026. Building this after the deadline is not a viable plan. Coordinated vulnerability disclosure programmes give the underlying capability. Microenterprises and small enterprises are exempt from fines for missing the 24-hour deadline specifically (Article 64(10)(a)), but the reporting obligation itself still applies to them.

Mistake 5: Running the three programmes in parallel silos

Reporting Letter SSM-2026-0301 compliance, CRA compliance, and EU AI Act obligations as three separate programmes with three separate teams and three separate evidence streams. This doubles cost, produces contradictory evidence, and misses the strategic point: continuous testing evidence produced once serves all three where scope overlaps. Integrated programmes are the mature form; parallel silos read as governance immaturity.

Approaches compared: how continuous testing satisfies all three

Four approaches produce evidence that supports parts of all three instruments. Most organisations combine two or three. The right mix depends on programme maturity, exposure profile, and whether the organisation ships PDEs or high-risk AI systems.

Adversarial exposure validation (AEV)

AEV runs continuous adaptive attacks on the application layer of AI-driven services, producing reproducible proof of exploit for every validated vulnerability. It answers the ECB letter's defensive-testing expectations (particularly Annex 1 focus areas 2 and 3) directly, supports CRA essential cybersecurity requirements at the application layer (enforceable from December 2027) and vulnerability-handling maturity (relevant from September 2026), and contributes to EU AI Act Article 15 evidence for high-risk AI. See AI security testing for the specific application-layer scope.

Breach and attack simulation (BAS)

BAS runs library attack techniques (typically mapped to MITRE ATT&CK) against the control stack (EDR, SIEM, SOAR) and scores control efficacy. It complements AEV: BAS validates whether controls would catch a technique; AEV validates whether attackers can exploit exposure. Together they cover the two questions all three instruments ask. See the CTEM vs BAS piece for the detailed comparison.

Manual pentesting and internal red team

Manual pentesting delivers depth on specific bespoke scenarios and creative attacks that automation cannot yet reach. It fits the annual set-piece cadence and depth-critical investigations, but does not satisfy the "continuous evidence" expectation by itself. Most organisations pair manual with continuous mechanisms. See the Manual vs Automated Pentesting piece for the tradeoff structure and division of labour.

Coordinated vulnerability disclosure (CVD) programmes

CVD programmes give manufacturers the intake, triage, and remediation infrastructure the CRA vulnerability-handling obligation demands. Bug-bounty platforms and CVD platforms provide the operational layer. CVD is complementary to AEV, BAS, and manual testing: it channels external researcher findings and interfaces with the Single Reporting Platform for actively exploited vulnerabilities from 11 September 2026. Product manufacturers under CRA scope should have a CVD programme running and SRP-ready before that date.

How Ethiack helps organisations meet these deadlines

This is where Ethiack sits explicitly, applied to the specific parts of each instrument Ethiack's platform addresses. Scope is applied honestly, including what Ethiack does not cover.

What Ethiack covers

Ethiack runs continuous adaptive AI-driven attacks on the application layer of AI-driven services with reproducible proof of exploit for every validated vulnerability. Purpose-built agentic AI pentesting through Hackian chains vulnerabilities, generates payloads on the fly, and adapts to context. False-positive rate below 0.5% (Ethiack-reported); 30x faster than manual pentesting on the same surface (Ethiack-reported). This directly supports Letter SSM-2026-0301 Annex 1 focus areas 2 (vulnerability and patch management at scale) and 3 (monitoring, detection and AI-enabled defence), CRA vulnerability-handling maturity (relevant from September 2026) and essential cybersecurity requirements at the application layer (enforceable from December 2027), and EU AI Act Article 15 obligations for high-risk AI.

The scope guardrail (what Ethiack does not cover)

Ethiack tests the customer-side application layer of AI-driven services (chatbots, RAG applications, AI agents on customer infrastructure) and third-party integrations reachable from the customer's surface. Ethiack does not test AI models themselves (weights, training data, model internals). Ethiack does not perform CE marking conformity assessment for CRA compliance. Ethiack does not operate a coordinated vulnerability disclosure programme or file Single Reporting Platform notifications on the customer's behalf. Organisations under CRA scope should pair Ethiack with a CVD platform and, for critical PDEs, a Notified Body. Organisations under EU AI Act Article 15 for high-risk AI should pair Ethiack with a model-testing specialist.

Compliance evidence and EU compute

The evidence Ethiack produces is designed for supervisory review: reproducible proof of exploit dated per validated vulnerability, mapped to specific controls, integrated into the adversarial exposure validation compliance workflow. Ethiack's engine servers are located in Belgium, keeping the compute layer within the EU regulatory perimeter. Especially relevant for eurozone banks under Letter SSM-2026-0301, EU manufacturers under the CRA, and EU-market AI providers under the EU AI Act. See Ethiack for financial services.

See what a real AI-driven attack validates on your AI services. Ethiack runs an external test in 24 hours with reproducible proof of exploit for every validated vulnerability, and packages the output for whichever regulator asks. Book a demo aligned to your regulatory deadlines, or run a free external test to see the output format first.

Frequently asked questions about ECB Cyber Resilience AI Deadline

What is the Cyber Resilience Act September 2026?

11 September 2026 is when Article 14 of the EU Cyber Resilience Act (Regulation (EU) 2024/2847) becomes applicable. From that date, manufacturers of products with digital elements placed on the EU market must report actively exploited vulnerabilities and severe incidents through the Single Reporting Platform (established under Article 16 and operated by ENISA), which routes notifications simultaneously to the designated CSIRT coordinator and ENISA. The three-stage cadence is 24-hour early warning, 72-hour notification, 14-day final report (vulnerabilities) or one month (severe incidents). Full CRA applicability follows on 11 December 2027.

What is the ESRB warning on Frontier AI Models?

ESRB Warning ESRB/2026/3, adopted on 25 June 2026, is the European Systemic Risk Board's assessment of systemic cyber risks stemming from Frontier AI Models (FAIMs). It identifies FAIMs as able to craft weaponised exploits "in a matter of minutes or hours" and frames three regulatory instruments (Letter SSM-2026-0301, the CRA, the EU AI Act) as the EU's coordinated regulatory response.

Has the EU AI Act been passed?

Yes. The EU AI Act (Regulation (EU) 2024/1689) was adopted on 13 June 2024 and entered into force on 1 August 2024. It applies in stages: prohibited AI practices from 2 February 2025; general-purpose AI obligations from 2 August 2025; most other obligations from 2 August 2026; specific high-risk AI systems from 2 August 2027. It is legally binding and enforceable.

What is the EU Cyber Resilience Act AI?

The EU Cyber Resilience Act (CRA) is not AI-specific, but it applies to any product with digital elements placed on the EU market that contains AI (smart cameras with ML, connected vehicles with AI features, IoT devices, software libraries with ML models). AI-containing PDEs must satisfy the CRA's essential cybersecurity requirements (from 11 December 2027), vulnerability-reporting obligations under Article 14 (from 11 September 2026), and CE marking obligations (from 11 December 2027).

What is the EU AI Act 2026?

The most significant 2026 EU AI Act date is 2 August 2026, when most of the Act's obligations become applicable. These include classification and conformity requirements for high-risk AI systems (Annex III), transparency obligations for certain AI systems, and the governance structure (national competent authorities, EU AI Office). Prohibited practices already applied since 2 February 2025.

What is Letter SSM-2026-0301?

Letter SSM-2026-0301, "Addressing AI-enabled cybersecurity threats", signed by Claudia Buch, Chair of the ECB Supervisory Board, dated 7 July 2026, is the ECB's supervisory communication (not a legislative act) requiring eurozone significant institutions to submit a comprehensive action plan by 31 October 2026. Its Annex 1 sets out six focus areas the action plan must cover. It is not a regulation with fines; consequences flow through SREP.

Is Letter SSM-2026-0301 the same as the Cyber Resilience Act?

No. Letter SSM-2026-0301 is a supervisory communication issued by the ECB's SSM to eurozone significant institutions. The Cyber Resilience Act (Regulation (EU) 2024/2847) is a full EU regulation that applies to manufacturers of products with digital elements placed on the EU market. Different issuer, different scope, different legal weight, different deadlines. Both may apply to the same organisation.

Does the EU Cyber Resilience Act apply to AI?

The CRA applies to products with digital elements (PDEs) placed on the EU market, regardless of whether they contain AI. It applies to AI-containing products (smart devices with ML, connected vehicles with AI, software libraries with ML models) as PDEs. It does not apply directly to standalone AI systems that are not products (the EU AI Act covers those). Many products fall under both.

What happens on 11 September 2026?

On 11 September 2026, Article 14 of the EU Cyber Resilience Act becomes applicable. Manufacturers of products with digital elements placed on the EU market must report actively exploited vulnerabilities and severe incidents through the Single Reporting Platform (established under Article 16 and operated by ENISA), which routes notifications simultaneously to the designated CSIRT coordinator and ENISA. Cadence: 24-hour early warning, 72-hour notification, 14-day final report (vulnerabilities) or one month (severe incidents).

What are the fines under the Cyber Resilience Act?

Fine exposure depends on the phased application timeline. From 11 September 2026, non-compliance with the vulnerability-reporting obligation under Article 14 can attract fines of up to €15 million or 2.5% of worldwide annual turnover (whichever is higher). The fines for essential cybersecurity requirements and CE marking apply from 11 December 2027. Lower tiers apply to other obligation breaches (up to €10M or 2%) and to supplying incorrect information (up to €5M or 1%). Under Article 64(10)(a), microenterprises and small enterprises are exempt from fines specifically for failure to meet the 24-hour early warning deadline, though the reporting obligation itself still applies. Enforcement is by national market surveillance authorities.

Are small businesses exempt from CRA fines?

Under Article 64(10)(a) of Regulation (EU) 2024/2847, microenterprises and small enterprises (as defined in the Annex to Commission Recommendation 2003/361/EC) are exempt from administrative fines specifically for failure to meet the 24-hour early warning deadline under Article 14. The reporting obligation itself still applies, and the exemption does not extend to the 72-hour notification, the 14-day final report, or any other CRA obligation. Small enterprises are those with fewer than 50 employees and turnover or balance-sheet total not exceeding EUR 10 million; microenterprises are those with fewer than 10 employees and turnover or balance-sheet total not exceeding EUR 2 million.

What are the six focus areas of the ECB action plan?

Annex 1 of Letter SSM-2026-0301 identifies six focus areas. Short-term: (1) attack surface protection, (2) vulnerability and patch management at scale, (3) monitoring, detection and AI-enabled defensive capabilities, (4) governance, funding, training and supply chain assurance. Structural: (5) defence-in-depth and infrastructure modernisation, (6) operational resilience and information sharing.

How do continuous testing and adversarial exposure validation help across all three deadlines?

Continuous testing produces the evidence type all three instruments call for. AEV runs adaptive AI-driven attacks against the live application surface with reproducible proof of exploit for every validated vulnerability at a false-positive rate below 0.5% (Ethiack-reported). That evidence satisfies Letter SSM-2026-0301 Annex 1 focus areas 2 and 3, contributes to CRA vulnerability-handling maturity from September 2026 and essential cybersecurity requirements from December 2027, and supports EU AI Act Article 15 obligations for high-risk AI.