Back to Blog

ESRB warning on frontier AI: Why finance teams should rethink phishing training

Frontier AI does not change cyber risks only technically. It shortens response windows, increases attacker speed, and forces finance teams to treat awareness, reporting, and retraining as a measurable resilience process.

By Autophish Team|Published on 7/20/2026
Cover image for ESRB warning on frontier AI: Why finance teams should rethink phishing training

The European Systemic Risk Board (ESRB) has officially warned of systemic cyber risks posed by frontier AI models. For banks, payment services, insurers, FinTechs, and other financial companies, the practical message is clear: cyberattacks are becoming faster, more scalable, and more precise. Security awareness should therefore no longer be treated as an annual box-ticking exercise.

Phishing simulations do not solve this new risk landscape on their own. But when used correctly, they help train part of the human attack surface in a controlled way, measure reporting behavior, document triggered follow-up training, and provide audit-ready evidence for DORA, NIS2, and internal resilience discussions.

That is exactly where AutoPhish comes in: not as a "compliance stamp," but as a platform for repeatable, privacy-conscious phishing simulations with feedback, training, and robust reporting.

Security note: This article describes defensive awareness and resilience measures. It does not include instructions for real phishing attacks, credential theft, payload delivery, or bypassing security controls.

What the ESRB is actually warning about

The warning ESRB/2026/3 was adopted on 25 June 2026 and published in the Official Journal of the EU on 16 July 2026 as C/2026/3795. The ESRB describes Frontier AI Models, or FAIMs for short, as advanced general-purpose models that can significantly influence offensive or defensive cyber operations.

The key points are unusually clear:

  • FAIMs can find vulnerabilities, develop exploits, and automate attacks against complex systems.
  • They are far ahead of earlier AI models in cost, speed, and accuracy.
  • They can threaten the ICT environments on which financial infrastructure depends.
  • The window between vulnerability discovery and exploitation is shrinking from days or weeks to minutes or hours.
  • Reactive patching processes can become overloaded when too many critical vulnerabilities surface in a short time.
  • In the short to medium term, offensive advantages are likely to outweigh defensive ones.

The ESRB names four resilience areas that come under particular pressure: time, defenders’ capabilities, concentration risks, and the capabilities of supervisors.

For financial teams, that means the classic assumption "we detect, prioritize, test, and patch in orderly cycles" is becoming less reliable. That affects technical controls, but also people, processes, and decision chains.

Why this is not just a patch-management issue

The first reaction to the ESRB warning is obvious: speed up vulnerability management, reduce internet-facing assets, and tighten third-party risk checks. That is correct, but too narrow.

The ECB Banking Supervision wrote to significant institutions on 7 July 2026 and requires an Action Plan by 31 October 2026. In the short term, the ECB names, among other things:

  • protection of exposed attack surfaces
  • accelerated vulnerability and patch management
  • stronger monitoring, detection, and AI-supported defense capabilities
  • governance, funding, awareness training, and supply-chain assurance

The fourth point is crucial for security awareness teams. In the annex, the ECB states that training and awareness for employees, customers, counterparties, third parties, and other relevant stakeholders must be risk-based, needs-based, and aligned with the changing threat landscape.

That is not an invitation to make more slides. It is an expectation of a living protection process.

When attacks get faster, it is no longer enough to remind staff once a year to "spot phishing." Teams need a system that regularly trains behavior, strengthens reporting channels, evaluates results, and documents concrete improvements.

How frontier AI changes phishing risk

Frontier AI does not need to invent an entirely new phishing category to become dangerous. It is enough to make existing social-engineering patterns faster, cheaper, and better.

For financial organizations, four changes are especially relevant.

1. Better pretexts in less time

Phishing has always been a context problem. Good attacks fit the role, language, process pressure, and timing. AI lowers the cost of that tailoring.

An attacker no longer has to manually write every version for every target group. They can vary templates faster, improve localization, and make roles such as Finance, Treasury, HR, Executive Assistants, IT Service Desk, or Vendor Management seem more believable.

Awareness programs should therefore move away from generic "package delivery" tests. Good simulations should train real decision moments: payment approvals, supplier changes, MFA prompts, HR documents, shared files, support escalations, and account recovery situations.

2. Less time for verification

The ESRB speaks of the collapse of defensive time buffers. That applies technically to patches, but organizationally it also applies to verification.

If an attack escalates faster, the first person in the process must know how to respond:

  • do not forward the message; report it
  • verify payment or data requests through a second channel
  • never enter codes, tokens, or passwords
  • escalate unusual account recovery requests
  • use internal reporting paths before a deadline creates panic

Phishing simulations are valuable here when they measure reporting behavior and reinforce it positively. A pure click rate only shows who made a mistake in a simulation. Resilience emerges only when teams can see who reports, how quickly they report, and whether the organization learns from those reports.

3. More attacks on shared dependencies

The ESRB emphasizes common exposures: critical third parties, shared technological ecosystems, cloud providers, open-source components, and widely used software. Those same dependencies also create social-engineering surfaces.

Typical pretexts include:

  • supposed updates from SaaS or cloud providers
  • vendor portals and contract approvals
  • changed bank details or invoicing processes
  • support tickets about vulnerabilities
  • fake communication around incident response or patch windows

A good awareness program must therefore account for roles and third-party processes. A generic inbox test does not adequately reflect the risk picture of a financial team.

4. More pressure on governance and evidence

The European Supervisory Authorities support the ESRB warning and point to DORA and the AI Act as an existing foundation. The message: financial companies should adapt their cybersecurity capabilities, and supervisory authorities should incorporate these developments into their work.

That makes awareness more measurable. The question is not whether a company once offered a training session. The question is whether it can show:

  • which target groups were covered
  • how scenarios were adapted to new risks
  • what results were produced
  • which follow-up trainings were triggered
  • what improvements were decided after reviews
  • how personal data was limited, protected, and aggregated

That is the difference between "we did awareness" and "we operate a controlled human-risk process."

What financial teams should check in their phishing program now

An AI-resilient phishing and awareness program does not need to become louder or harsher. It needs to be better governed.

1. Tie scenarios to real financial processes

Start with the workflows that can cause real damage if social engineering succeeds:

  • payment approvals and treasury processes
  • vendor onboarding and bank account changes
  • executive and board communication
  • IT service desk and account recovery
  • customer service and identity verification
  • finance, legal, and compliance documents
  • SaaS, cloud, and third-party access

A simulation should not be an attack manual. It should reflect the decision pressure employees face in the real process and train the safe next step.

2. Treat reporting as a core metric

Click Rate is easy to understand, but it is not the best resilience metric.

Financial teams should at least track:

  • Report Rate
  • Time to Report
  • repeated reports from critical roles
  • share of correctly identified simulations
  • share of reported real suspicious cases
  • follow-up training after risky interaction
  • change over multiple campaigns

In this context, AutoPhish should be positioned as a reporting and feedback loop: simulations create the learning moment, but the value comes from reporting, feedback, training, and evidence.

3. Automate follow-up, keep escalation controlled

If employees report a simulation, positive feedback should come quickly. If they interact in a risky way, a short, relevant refresher should follow. If patterns emerge in critical roles, a person should review them before manager- or HR-adjacent escalation happens.

Good automation means:

  • repeatable rules
  • short learning modules
  • documented completion
  • traceable triggers
  • human review for sensitive cases
  • no shaming, no public exposure, no unnecessary monitoring

Especially in the EU environment, trust is a control factor. A program that feels like employee surveillance loses effectiveness and creates side battles with data protection, works councils, or internal stakeholders.

4. Build in privacy and aggregation from the start

The new threat landscape does not automatically justify maximum appetite for personal data.

Before rollout, financial teams should define:

  • who may see individual data
  • which reports are output only in aggregated form
  • how long raw data is retained
  • which exports are allowed
  • how repeat-offender logic is limited
  • how coaching stays separate from disciplinary measures
  • how employees are informed transparently

AutoPhish fits well here if the platform is described as a privacy-aware awareness system: enough data for effective improvement, but no more personal visibility than necessary.

5. Prepare evidence for DORA and internal reviews

DORA does not say "buy a phishing tool and you are done." DORA defines digital operational resilience as a management discipline for ICT risks, testing, incident handling, third-party risk, and governance.

Phishing simulations can support that discipline when they provide evidence:

  • campaign objective and approval
  • target groups, inclusion and exclusion
  • scenario type and risk assumption
  • sending and training period
  • reporting and interaction metrics
  • follow-up training and completion
  • review notes
  • improvement actions
  • privacy and access settings

That is exactly the kind of material that is more useful in management, audit, and supervisory discussions than an isolated dashboard screenshot.

What AutoPhish should deliver in this new environment

The AutoPhish positioning should remain deliberately sober:

AutoPhish does not automatically make a financial company DORA-, NIS2-, or ESRB-compliant. But AutoPhish can help run the human side of cyber resilience in a repeatable, measurable, and privacy-conscious way.

The strongest argument is:

  • AI is accelerating social engineering and technical attack chains.
  • Financial teams need faster learning and reporting loops.
  • Phishing simulations must be safe, relevant, and non-punitive.
  • Follow-up training and evidence belong in the same workflow.
  • Reporting must help Security, Compliance, and leadership without creating unnecessary surveillance.

That is a better claim than "stop AI phishing." No one stops this trend with awareness alone. But teams can reduce the chance that social engineering goes unnoticed, escalates incorrectly, or fails to be learned from.

Practical 30-day checklist

Financial teams that want to respond to the ESRB and ECB signals can start with a small, robust program.

Week 1:

  • Define critical roles and workflows
  • Review the reporting channel and escalation path
  • Clarify privacy and access rules
  • Collect existing awareness evidence

Week 2:

  • Select two to three risk-relevant scenarios
  • Set safety boundaries: no real passwords, no tokens, no sensitive data
  • Prepare feedback and follow-up training
  • Define success criteria: Report Rate, Time to Report, Completion, Review

Week 3:

  • Launch a controlled simulation with a clear target group
  • Confirm reports quickly and positively
  • Pair risky interactions with brief retraining
  • Document unexpected technical or organizational outcomes

Week 4:

  • Review results in aggregate
  • Check follow-up completion
  • Identify process gaps
  • Decide improvements for the next campaign
  • File the evidence package for governance or compliance

The point is not to be perfect in 30 days. The point is to start a controlled learning cycle that can grow with the threat landscape.

Conclusion

The ESRB warning on frontier AI is not some abstract paper about the future. It describes a short-term shift in the cyber economy: attackers can search faster, vary faster, and exploit faster, while defenders remain constrained by stability, regulation, change processes, and real operational risk.

For financial teams, that means awareness has to move closer to resilience. Not as theater, not as blame, not as a compliance shortcut. But as a measurable process of simulation, reporting, feedback, retraining, review, and evidence.

AutoPhish is relevant precisely when Security and Compliance teams want to run that process without operational sprawl: repeatable, safe, privacy-conscious, and with reporting that supports decisions.

If your financial team wants to run phishing simulations as an ongoing resilience process rather than a one-off awareness campaign, test AutoPhish.

FAQ

What is the ESRB warning C/2026/3795?

C/2026/3795 is the Official Journal publication of the ESRB warning from 25 June 2026 on systemic cyber risks arising from frontier AI models. The ESRB warns that such models can find vulnerabilities faster, develop exploits faster, and enable cyberattacks with greater speed, scale, and accuracy.

Does the warning only affect banks?

The focus is on the EU financial system, including banks, financial market infrastructures, and other financial companies. In practice, however, their ICT providers, cloud dependencies, software vendors, and critical third parties are relevant too.

Why is phishing training relevant in an AI cyber warning?

AI can make social engineering faster and more context-aware. At the same time, the ECB expects in its letter on AI-enabled cybersecurity threats that training and awareness be risk-based and aligned with the changed threat landscape. Phishing training is not the whole answer, but it is an important part of the human resilience loop.

Does AutoPhish make a company DORA-compliant?

No. No phishing simulation tool on its own makes a company DORA-compliant. But AutoPhish can help run awareness activities in a repeatable way, document follow-up training, improve reporting, and provide evidence for governance or compliance reviews.

Which metrics matter more than Click Rate?

Report Rate, Time to Report, Follow-up Completion, target group coverage, repeat patterns, review decisions, and improvement actions are usually more valuable for resilience and compliance discussions than Click Rate alone.

Sources


Run your first phishing test in 10 minutes.

Sign up free — no credit card. Try Pro free for 7 days when you're ready.