Breach and attack simulation vs penetration testing
Two line items keep showing up in the same security budget, and buyers keep treating them as substitutes. Breach and attack simulation. Penetration testing. They answer different questions, and only one of them closes the obligation your supervisor will ask about.
What each one actually proves
Breach and attack simulation replays known attacker techniques inside your environment and watches what your defences do. Did the endpoint agent catch it, did the SIEM raise it, did the mail gateway strip it. The category has since been folded into what Gartner now calls adversarial exposure validation, defined as technologies that deliver consistent, continuous and automated evidence of the feasibility of an attack. That same 2026 market guide notes AEV formally replaces the older breach and attack simulation and automated penetration testing categories, and projects that 60% of organisations will run a structured validation practice by 2029.
A penetration test starts from the other end. It takes a defined scope, hunts for weaknesses nobody has catalogued yet, and proves them by exploiting them. No simulated technique, no assumption that the flaw is already in a library.
The short version: simulation asks whether your alarm rings. A pentest asks whether the window opens.
A control that fires on a replayed technique has not proved your application is safe. It has proved your alarm works.
Who is actually in this category
Two heritages sit under the same AEV label now, which is why the shortlists look interchangeable and are not.
On the simulation side: Cymulate, SafeBreach, AttackIQ and Picus. They replay catalogued techniques against the controls you already bought and score detection and prevention coverage. On the exploitation side: Pentera, which came out of automated penetration testing and chains findings to prove reachable impact rather than measuring whether an alert fired.
So the common shortlist question, Pentera vs Cymulate, is not a feature comparison. It is a choice between validating the controls you own and validating the exposure nobody has catalogued yet. A blue team with a mature SIEM and unclear coverage numbers wants the first. An entity that has to file a testing obligation wants the second, and needs it signed by someone independent.
That last clause is the one that decides audits, and it is where both categories stop. TechTarget's walkthrough of seven of these platforms is worth reading before the demo call.
What the regulation actually asks for
This is where the substitution argument falls apart.
DORA Article 25 sets out the test types a financial entity has to perform, and the list names vulnerability assessments and scans, source code reviews, scenario-based tests, compatibility testing, performance testing, end-to-end testing and penetration testing. Penetration testing is written into the text. Control simulation is not a listed substitute for it.
Article 24 then sets the cadence and the independence bar: entities must ensure at least yearly that appropriate tests are conducted on all ICT systems and applications supporting critical or important functions, and that tests are undertaken by independent parties, whether internal or external. For the entities a competent authority designates, Article 26 adds threat-led penetration testing at least every 3 years, performed on live production systems.
NIS2 is where simulation earns its budget. Article 21(2)(f) requires policies and procedures to assess the effectiveness of cybersecurity risk-management measures. Measuring whether the controls you bought actually work is precisely the job BAS was built for.
So the honest mapping is not either-or. Pentest answers the testing obligation. Simulation answers the effectiveness obligation. A GRC team that files one against the other will get the question at the wrong moment.
Where simulation runs out of road
Three limits worth knowing before the renewal conversation.
It only tests techniques someone already wrote down. Novel business-logic abuse in your own quote flow or claims portal was never in the technique library, so it will never be replayed.
It validates controls you already own. If the exposure sits in an application nobody put behind a control, there is nothing for the simulation to trigger.
And the tooling carries real operating cost. Trade-press reviews of the main platforms document implementation difficulty, scalability limits, and integration gaps across the category, which is a fair warning for a small security team.
There is also an independence question. A tool your own team configures and runs sits awkwardly against the Article 24 requirement for independent parties, especially where the same team owns the controls under test.
Four questions before you sign either one
- Which written obligation does this line item close. Name the article. If nobody can, the budget is buying comfort.
- Who ran it. DORA wants independent parties and a documented absence of conflict of interest between the people designing the test and the people who own the system.
- Does it hand you evidence or a dashboard. A supervisor reads a scoped, dated, validated report. A score in a console is not an audit artefact.
- What happens between the tests. Your attack surface changes with every release. Annual depth plus nothing in between is the gap most entities are still carrying.
Both categories are converging on the same promise of continuous evidence. The part that decides an audit is still whether a named, independent party validated the finding and signed the report.
Fleuret runs continuous agentic pentest on EU infrastructure, with findings validated before they reach the report your auditor reads. See Fleuret in action.
Sources
- DORA Article 24: general requirements for the performance of digital operational resilience testing, Regulation (EU) 2022/2554
- DORA Article 25: testing of ICT tools and systems, Regulation (EU) 2022/2554
- DORA Article 26: advanced testing of ICT tools, systems and processes based on TLPT, Regulation (EU) 2022/2554
- NIS 2 Directive Article 21: cybersecurity risk-management measures, Directive (EU) 2022/2555
- What the 2026 Gartner Market Guide for Adversarial Exposure Validation means for offensive security, Hadrian, 2026
- Pros and cons of 7 breach and attack simulation tools, TechTarget
Related reading
- Bug bounty vs penetration testing vs DAST: the same buying question, across three other categories.
- DORA penetration testing requirements in 2026: what the testing programme has to contain.
- Why annual pentests are broken: the case for closing the gap between tests.