Breach and Attack Simulation (BAS)

Breach and attack simulation (BAS) is an approach to security validation that continuously tests whether controls work as intended by running automated adversary techniques in a repeatable way. For IT environments, BAS often helps teams measure control coverage, tune detections, and reduce the time between configuration changes and proof of effectiveness.

For operational technology (OT) and critical infrastructure, the same promise is attractive, but the constraints are different. You cannot treat production PLCs, safety systems, and historian workflows like disposable test targets. Many BAS implementations also validate individual techniques in isolation rather than the full sequence of actions that turns an initial foothold into process impact. That gap matters because real attackers operate through attack paths, not single steps.

This page explains BAS in practical terms, outlines what it can and cannot prove in industrial environments, and provides a framework for using BAS as a foundation rather than the final word on risk. If you want the wider context of industrial risks and constraints, see the Complete Guide to OT Security: Protecting Industrial Control Systems [2026]. If you are specifically focused on ICS architecture and validation constraints, the ICS and SCADA Security: Architecture, Risks, and Safe Validation for Critical Infrastructure overview complements the BAS discussion. And if you are evaluating how to test without touching production systems, How Digital Twins Enable Safe, Comprehensive OT Security Testing is the most relevant background for the approach discussed here.

Definition: what breach and attack simulation means in practice

Breach and attack simulation is the continuous, automated execution of adversary techniques against an environment to validate security controls. In practice, BAS platforms schedule or trigger tests that resemble parts of a kill chain, then measure outcomes such as whether an endpoint control blocked execution, whether a network control prevented lateral movement, whether credentials were exposed, or whether a detection rule fired.

A useful way to think about BAS is that it produces evidence. It answers questions like: Did the control stop the technique? Did logging capture it? Did detection or alerting occur? Did the response workflow start? In mature programs, it also becomes a regression test suite for security changes, such as verifying that a segmentation change did not accidentally reopen a path between zones.

BAS is not the same as a penetration test. It tends to be automated, repeatable, and focused on validating control behavior. A pen test is typically deeper, more exploratory, and includes manual decision-making that adapts to what is found. BAS also differs from red teaming, which is scenario-driven and measures end-to-end outcomes, including the human response process.

For OT environments, definitions must include safety constraints. Any BAS-like activity in OT should be designed so the test itself cannot create process risk. That requirement changes where, how, and what you can test.

Why BAS became popular: what it improves over point-in-time testing

Security controls drift. Detection rules change, agents get upgraded, firewall objects are added, and asset inventories shift as plants modernize. Traditional assessment methods often provide a snapshot that becomes outdated quickly. BAS gained traction because it offers a systematic way to validate controls continuously, not just during annual audits or major projects.

In environments with frequent configuration changes, BAS can provide a practical feedback loop: run a known technique, see if it is blocked or detected, and tune accordingly. It also supports operational discipline. Security engineering teams can treat control validation like software teams treat testing, with repeatable checks after changes.

For OT and critical infrastructure operators, the desire is similar, but the driver is often risk acceptance and safety. Leaders want a defensible answer to, “Are our controls actually preventing the outcomes we care about?” BAS can contribute, especially when used to validate segmentation, authentication controls, and logging coverage.

However, the benefits only translate if the test design respects operational constraints and if results are tied to realistic attack paths rather than isolated technique checklists.

Where BAS fits in OT security validation

OT environments have characteristics that make direct BAS execution challenging: legacy operating systems, deterministic communications, tight maintenance windows, vendor support constraints, and safety systems whose behavior must not be disrupted. At the same time, OT networks often contain high-value pathways between IT and OT, between zones, and between engineering workstations and controllers.

In OT, BAS is most valuable when it validates control assumptions that are hard to prove through documentation alone, such as whether a firewall rule actually enforces zone boundaries, whether an engineering workstation is overly permissive, whether a jump host is the only viable path into a control zone, or whether centralized logging captures meaningful telemetry.

Many teams start with BAS-like tests in the IT side of the enterprise where the initial access often occurs, then attempt to extend into OT. That extension is where gaps show up, especially when the BAS platform assumes common IT tooling, typical endpoint agents, or permissive test execution.

If you are designing BAS validation around SCADA and ICS segmentation, it helps to ground the exercise in architecture. The SCADA Security: Architecture, Risks, and Safe Validation for Critical Infrastructure resource is a good reference for common zones, conduits, and risk points that BAS should be mapped to.

Common BAS limitations in complex environments

BAS is frequently positioned as “continuous validation,” but what gets validated depends on how tests are constructed and what the platform can safely execute. In real deployments, limitations show up in four recurring areas.

First, technique isolation. Many BAS programs validate a technique like credential dumping or SMB lateral movement without validating the preceding conditions that make it possible, such as specific credential exposures, privilege relationships, or weak workstation hardening. This can lead to a pass or fail that is not representative of a real intrusion path.

Second, limited visibility into OT-specific attack steps. Industrial protocols, engineering software behaviors, and controller interactions do not always produce the same telemetry as IT techniques. If BAS relies on endpoint agents or typical EDR telemetry, the OT side may appear “quiet,” and results can be misleading.

Third, safety constraints restrict execution. Even when a BAS platform technically supports running a test, operators may prohibit it because it could affect process availability or vendor support agreements. The end result is often a BAS program that stops at the OT perimeter.

Fourth, environment realism. BAS often runs in production or near-production contexts but cannot safely simulate the disruptive parts of attacker behavior, including misconfiguration of setpoints, manipulation of logic, or disruption of communications. Those outcomes are the ones critical infrastructure cares about most. If a method cannot validate them safely, it cannot fully measure real-world risk.

These limitations do not mean BAS is not useful. They mean BAS should be treated as a component in a broader validation strategy, especially when risk is defined in terms of process impact rather than endpoint compromise.

BAS vs penetration testing vs adversary simulation: how to choose

Security teams often ask whether BAS replaces a traditional penetration test. In practice, they answer different questions.

BAS is best when you want repeatability, measurement over time, and fast feedback on control changes. A penetration test is best when you need exploratory coverage, validation of unknowns, and a prioritized view of exploitable weaknesses across a defined scope. Adversary simulation is best when you need scenario-driven validation of a realistic threat path from initial access to operational impact, including the detection and response process.

For OT, this distinction matters because the highest risk is often not “can an attacker run a command,” but “can an attacker reach engineering functions, manipulate a controller, or disrupt an operational workflow without being detected and stopped.” That is fundamentally an attack-path question.

A practical approach is to use BAS as a control validation layer, then use deeper scenario-driven adversary simulation when you need to validate full paths and impact outcomes under strict safety constraints. This is where safe test environments become critical, because the most relevant scenarios are often the least safe to test directly in production.

A practical BAS framework for OT: from techniques to attack paths

To make BAS results meaningful for critical infrastructure, tie BAS execution to attack paths that represent how an adversary would actually move through your environment. The goal is to connect technique-level outcomes to risk-level outcomes.

The framework below is designed to be usable by OT security architects, vulnerability management teams, and red teams working with plant engineering constraints.

Define the operational impact outcomes you care about. Examples include loss of view for operators, loss of control for a process, unauthorized logic change, disruption of safety-related communications, or compromise of a historian that undermines reporting and quality.
Map critical assets and trust boundaries. Identify engineering workstations, jump hosts, domain trust relationships, remote access systems, historians, SCADA servers, and PLC networks. Focus on zones and conduits, not just individual hosts.
Enumerate plausible initial access vectors. Typical entry points include remote access, vendor connections, exposed services, phishing leading to IT compromise, and weak authentication on engineering assets.
Build attack paths, not checklists. For each outcome, document the sequence: initial foothold, credential access, lateral movement, privilege escalation, access to engineering functions, and the operational action that causes impact.
Select BAS tests that validate assumptions along each path. Examples include testing whether jump host MFA blocks reuse of credentials, whether segmentation blocks specific east-west communications, whether EDR detects common tooling on engineering workstations, and whether logging captures key authentication and remote execution events.
Define success criteria that reflect detection and prevention. A “blocked” technique is good, but so is a “detected and triaged within X minutes” outcome if prevention is not feasible in OT.
Run continuously where safe, and schedule deeper tests during maintenance windows or in a safe replica environment. Treat BAS as a regression suite for your most important controls.
Review results with OT operations and engineering. Validate that mitigations are operationally feasible and that proposed control changes do not introduce new failure modes.

How to make BAS safe in OT: constraints and design patterns

The biggest objection in OT is disruption risk. This concern is valid. Many industrial systems were not designed to tolerate frequent scanning, agent installation, or aggressive test execution. BAS must be designed to respect system fragility and operational requirements.

Several design patterns reduce risk while improving the usefulness of BAS.

Start by separating test intent from test execution. You can validate many assumptions about access paths, segmentation, and authentication without running intrusive payloads on controllers. For example, you can test whether a route exists, whether a port is reachable from a given zone, whether authentication is enforced, and whether key events are logged, without attempting to modify process values.

Next, limit tests to representative endpoints when production constraints are tight. Engineering workstations, jump servers, and DMZ systems often provide more realistic telemetry and control validation than attempting to execute on PLCs.

Finally, use controlled environments for high-risk steps. The most meaningful validation often involves actions you cannot safely perform in production, such as testing the ability to alter control logic or simulate operator-view manipulation. This is where digital-twin-based testing becomes the practical path to realism without operational risk. For a deeper explanation of the digital twin approach to OT security testing, refer to How Digital Twins Enable Safe, Comprehensive OT Security Testing.

FAQs

Will breach and attack simulation disrupt production in OT environments?

It can if it is executed directly against fragile production assets or if it includes intrusive payloads. In OT, BAS should be constrained to safe validations in production, such as access-path and segmentation checks, authentication enforcement, and logging and detection verification on representative systems. For higher-risk steps that could affect process availability or safety, use a controlled environment such as a digital twin so you can validate realistic scenarios without touching production systems.

Is BAS better than a traditional penetration test for ICS and SCADA?

They are different tools for different questions. BAS is better for continuous, repeatable validation of specific controls and for regression testing after changes. A penetration test is better for exploratory discovery and identifying exploitable weaknesses across a scope at a point in time. For OT risk, scenario-driven adversary simulation is often needed to validate end-to-end attack paths to operational impact, which BAS alone may not represent.

How long does BAS take to implement in a critical infrastructure environment?

Initial safe tests can start relatively quickly when scope is limited and stakeholders align on what is permitted in production. Broader OT coverage takes longer because of architecture validation, maintenance windows, and safety reviews. If you include digital-twin-based testing for full attack paths, expect an iterative rollout: start with a high-value subset of the environment and expand fidelity and coverage over time.

What do we get at the end of a BAS-driven validation program?

You should get evidence of which controls prevent or detect specific techniques, tracked over time, plus actionable gaps in logging, detection, segmentation, and identity controls. For OT, the most useful deliverable is an attack-path view tied to critical assets and operational outcomes, with prioritized remediation steps that engineering and operations teams can implement safely.

Do we need perfect data sets to build a digital twin for safe OT testing?

No. You need enough fidelity to represent the trust boundaries, pathways, and behaviors that determine whether an attacker can progress toward critical functions. Most programs start with a subset of the environment and iterate. The key is to define the outcomes you want to validate, then collect only the data necessary to model those paths credibly.

Next Steps

Breach and attack simulation is a strong foundation for continuous security validation, but OT risk is defined by attack paths and operational impact. If you want to validate real attacker behavior without risking production, request an OT Security Assessment with Frenos to map your highest-risk paths and define a safe, continuous validation plan.

Breach and Attack Simulation (BAS): What It Is, What It Proves, and Where It Falls Short in OT