Adversary Simulation for OT and ICS: A Complete Guide to Safe Attack-Path Validation

Adversary simulation is a security validation method that models how an attacker could move through an environment, combine techniques, cross trust boundaries, and reach systems that matter. In operational technology, the objective is not simply to determine whether a security control detects an isolated action. It is to establish whether a realistic sequence of actions can create operational or safety consequences.

That distinction matters in industrial control system environments. A vulnerability scan may identify thousands of findings. An asset inventory may reveal what is connected. A firewall review may identify permissive rules. None of these activities alone proves whether an attacker can move from an initial foothold in IT, traverse an industrial DMZ, compromise an engineering workstation, and reach a critical OT asset.

OT adversary simulation connects those individual facts into attack paths. When performed in a cyber digital twin rather than against live production systems, it can validate those paths without sending intrusive traffic to controllers, disrupting industrial protocols, or putting equipment and uptime at unnecessary risk.

This guide explains how adversary simulation works in OT and ICS, how it differs from related testing methods, what a safe program requires, and how to turn simulation results into engineering priorities.

What is adversary simulation?

Adversary simulation is the controlled modeling and execution of realistic attacker behaviors against a representation of an organization's environment. It evaluates how vulnerabilities, credentials, network access, trust relationships, security controls, and architectural conditions could combine into an end-to-end compromise path.

A useful simulation answers questions such as:

• Where could an attacker gain an initial foothold?
• Which reachable systems could support discovery or lateral movement?
• Can an attacker cross from enterprise IT into an OT environment?
• Which identity, network, or configuration conditions make that movement possible?
• Where should segmentation, access control, monitoring, or hardening stop the path?
• Which critical assets are reachable under the modeled conditions?
• Which changes would eliminate the greatest number of consequential paths?

The output should be evidence about exploitability and reachability, not just a list of possible weaknesses. This evidence helps teams distinguish a vulnerable asset from an asset that is both vulnerable and reachable through a viable sequence of attacker actions.

Adversary simulation versus adversary emulation

The terms are sometimes used interchangeably, but they can emphasize different objectives.

Adversary emulation commonly reproduces the tactics, techniques, and procedures associated with a known threat actor or campaign. The scope may focus on whether an organization can prevent or detect that specific behavior.

Adversary simulation can be broader. It may use known threat behavior, generalized attacker logic, environmental conditions, and many possible action sequences to identify plausible paths. It is particularly useful when defenders need to test more than one predefined campaign or determine which routes an adaptive attacker could select.

Both approaches can be valuable. For OT teams, the essential evaluation criterion is whether the method validates complete, environment-specific attack paths while respecting operational constraints.

Why adversary simulation is different in OT and ICS

Traditional IT testing often prioritizes confidentiality, rapid patching, endpoint control, and the ability to restore systems. Industrial environments introduce different operating conditions. Availability, process integrity, worker safety, product quality, and equipment protection may take priority over aggressive testing.

Several characteristics change how adversary simulation must be designed.

Safety and uptime constrain live testing

Legacy devices, controllers, engineering software, and proprietary industrial protocols may respond unpredictably to scanning or exploit activity. Even a technically valid test can create unacceptable operational risk if it consumes limited device resources, changes controller state, interrupts communications, or triggers an unsafe process condition.

A maintenance window does not automatically make every test safe. Some processes cannot be stopped easily, and latent effects may persist after a test concludes. OT simulation therefore requires explicit safety boundaries and a clear separation between modeled activity and any approved production validation.

Legacy and specialized systems remain in service

Industrial assets often have longer lifecycles than conventional IT systems. An organization may depend on equipment that cannot support modern endpoint agents, current operating systems, or routine patching. Vendor support agreements and certification requirements may also restrict changes.

Adversary simulation should account for those realities rather than assume every exposed condition can be solved by applying a patch. The best mitigation may be segmentation, access restriction, protocol filtering, jump-host controls, monitoring, or another compensating control.

IT and OT dependencies create extended attack paths

A consequential OT attack may begin outside the control network. Remote access services, identity infrastructure, file-transfer systems, historians, management platforms, vendors, and shared services can create routes between enterprise and industrial environments.

The simulation scope must therefore include relevant IT-to-OT dependencies. Testing only devices inside an OT zone can miss the initial access and pivot conditions that make the final compromise possible.

Consequence changes the meaning of risk

A severe software vulnerability on an isolated, noncritical asset may represent less immediate risk than a moderate weakness on a system that bridges zones or administers critical controllers. CVSS scores and vulnerability counts cannot capture this context by themselves.

OT adversary simulation adds reachability, exploit conditions, control effectiveness, asset function, and potential consequence to the prioritization process.

What adversary simulation should validate

A mature program evaluates more than whether an individual technique can execute. It validates the complete chain from a plausible starting point to a defined operational target.

Initial access assumptions

Every scenario needs a defensible starting condition. Examples include:

• A compromised enterprise workstation
• Stolen credentials for a remote access account
• Access through a vendor connection
• A compromised server in an industrial DMZ
• An exposed or misconfigured service
• A malicious or compromised insider account

The goal is not to predict one exact intrusion. It is to evaluate credible starting positions and understand what an attacker could reach from each one.

Discovery and lateral movement

The simulation should determine what the attacker could learn and access after the initial foothold. Relevant conditions include routable connections, authentication relationships, management interfaces, accessible services, credential exposure, dual-homed hosts, and permissive firewall rules.

An isolated finding becomes more important when it enables the next action. Simulation connects those actions and identifies the systems that act as bridges or force multipliers.

IT-to-OT boundary crossing

Industrial DMZs, firewalls, jump servers, identity controls, and remote access systems are intended to prevent uncontrolled movement into OT. Adversary simulation should test whether the modeled architecture and policies actually enforce that intent.

Questions include:

• Can a compromised IT identity authenticate to an OT-connected service?
• Do firewall rules permit a route that was not intended by the architecture?
• Can a historian, management server, or jump host be used as an intermediary?
• Does a vendor connection provide access beyond its required destination?
• Can an attacker bypass a documented conduit through an unmanaged route?

These are architecture questions as much as vulnerability questions.

Access to critical OT assets

The final stage evaluates whether a path reaches systems with operational significance. Depending on the environment, targets may include engineering workstations, human-machine interfaces, supervisory servers, controllers, safety-related assets, or systems that manage recipes, configurations, or process data.

Reaching a target does not mean the simulation must execute a dangerous process action. A safe assessment can establish the conditions that would make the action possible without issuing a command to production equipment.

Preventive and detective controls

Simulation should identify the control expected to stop or expose each step. That may include segmentation, multifactor authentication, application control, endpoint protection, network monitoring, logging, protocol inspection, or operator procedures.

The result should distinguish among:

• Controls that prevent the path
• Controls that detect but do not prevent it
• Controls that exist but are bypassable under modeled conditions
• Controls that lack sufficient data for a conclusion
• Steps with no effective control identified

This makes the findings useful to both security and engineering teams.

Adversary simulation compared with other assessment methods

No single security assessment answers every question. Organizations should select methods based on the evidence they need and the operational risk they can accept.

For a detailed comparison of control testing and full-path analysis, see [BAS vs adversary simulation](https://frenos.io/resource/bas-vs-adversary-simulation). Teams evaluating objective-driven exercises can also review [OT penetration testing versus red teaming](https://frenos.io/blog/ot-penetration-testing-vs-ot-red-teaming-whats-the-difference).

These methods are complementary. Asset visibility supplies foundational data. Vulnerability management identifies potential weaknesses. BAS can repeatedly check selected controls. Penetration testing can provide scoped empirical evidence. Adversary simulation connects conditions into paths and helps prioritize the paths that matter most.

How safe OT adversary simulation works

Safe simulation begins by separating analysis from production execution. A cyber digital twin represents relevant assets, network relationships, exposures, controls, and attacker options so that potentially disruptive actions can be evaluated outside the live control environment.

1. Define operational objectives and safety constraints

The assessment should begin with a shared definition of what matters. Security, operations, and engineering stakeholders identify critical processes, high-consequence assets, acceptable data sources, excluded systems, and escalation procedures.

Useful objectives include:

• Determine whether an enterprise compromise can reach a critical OT zone
• Validate segmentation between defined IEC 62443 zones and conduits
• Evaluate remote vendor access paths
• Test exposure to a selected threat actor's techniques
• Determine whether proposed firewall changes eliminate known paths
• Prioritize compensating controls for unpatchable systems

Safety constraints should document what will and will not interact with production. Any live confirmation must have separate authorization, rules of engagement, rollback planning, and operational oversight.

2. Ingest available environment data

A high-fidelity model can use data that already exists across the organization. Sources may include asset inventories, firewall configurations, network flows, vulnerability data, architecture diagrams, identity information, configuration records, and security platform exports.

Perfect visibility should not be treated as a prerequisite. An agnostic ingestion approach can normalize fragmented data into a working model, provided uncertainty and coverage gaps remain visible. The assessment should not claim complete coverage when discovery or source data is incomplete.

The process itself often reveals data-quality issues such as stale objects, undocumented routes, conflicting asset identities, or missing ownership information. Those issues are valuable findings because they affect both security analysis and operational response.

3. Build and verify the cyber digital twin

The twin should model security-relevant relationships, not merely produce a visual copy of the plant. At a minimum, it should represent:

• Assets and their functions
• Network zones, conduits, and reachable services
• Firewall policy and access relationships
• Known vulnerabilities and exploit conditions
• Identity and privilege relationships where available
• Security controls associated with each path
• Critical targets and relevant business or operational context

Subject matter experts should review material assumptions. An incorrect route, missing access condition, or misclassified critical asset can affect results. Model validation is therefore an essential quality-control step.

Digital twins are especially useful because they allow teams to explore scenarios that would be unsafe or impractical to execute against live industrial systems. Learn more about [how digital twins change OT security testing](https://frenos.io/blog/how-digital-twins-are-changing-ot-security-testing).

4. Select adversary behaviors and starting positions

Scenarios should reflect the organization's architecture, threat model, and operational priorities. MITRE ATT&CK for ICS can provide a common vocabulary for tactics and techniques, but mapping techniques is not the final objective. Teams must determine how those techniques relate to actual systems and access conditions.

Scenario selection can include known threat actor behavior, ransomware-style movement, credential compromise, remote access abuse, exploitation of exposed services, or an assumed breach in a specific zone.

A useful scenario states:

1. The assumed starting position
2. The attacker objective
3. The systems and boundaries in scope
4. The actions the model may evaluate
5. The conditions that count as success or failure
6. The controls expected to interrupt the path

5. Simulate possible attack paths

The simulation evaluates possible sequences of attacker actions across the modeled environment. AI-driven reasoning can help explore more combinations than a manual review, but speed or volume alone is not evidence of quality.

Each validated path should have transparent reasoning. Reviewers should be able to understand why an action is considered possible, what data supports it, which assumption was used, and what control should interrupt it.

The analysis should distinguish among:

• Theoretical paths unsupported by current conditions
• Plausible paths that require additional evidence
• Validated paths supported by modeled reachability and exploit conditions
• Blocked paths where a control prevents progression

This distinction prevents AI-generated findings from becoming another unreviewed alert queue.

6. Analyze control performance and blast radius

A path is more than a route to one asset. Teams should also understand what becomes reachable after each successful step. A compromised bridge system may expose multiple zones, assets, or processes.

Blast-radius analysis can identify:

• Systems that appear in many consequential paths
• Shared services that create systemic exposure
• Choke points where one control could stop multiple paths
• Critical assets with several independent routes of access
• Segmentation changes that materially reduce reachability

This helps move remediation from asset-by-asset work to path reduction.

7. Prioritize remediation using attack-path evidence

The highest CVSS score is not always the best first action in OT. Prioritization should consider:

• Whether the weakness is reachable
• Whether required exploit conditions exist
• Whether the system advances an attack toward a critical target
• The reliability of current preventive and detective controls
• The operational consequence associated with the target
• The feasibility and safety of remediation
• The number of paths a mitigation would eliminate

Recommended actions should fit industrial constraints. Options may include tightening firewall policy, removing an unused route, restricting remote access, separating identities, hardening a jump host, improving monitoring, changing an operating procedure, or applying a patch during an approved outage.

8. Re-simulate after changes

Validation is incomplete until teams confirm that remediation breaks the intended path and does not create a new dependency. The updated model should be rerun after a proposed or implemented control change.

This feedback loop turns a point-in-time assessment into continuous security validation:

1. Model the environment
2. Simulate adversary behavior
3. Validate consequential paths
4. Prioritize mitigations
5. Update controls
6. Re-simulate
7. Monitor architecture and threat changes

Continuous validation does not mean continuously attacking production. It means updating and testing the model as conditions change.

What a useful adversary simulation deliverable includes

A simulation report should support decisions by engineers, operators, vulnerability teams, security leaders, and executives. A large attack graph without prioritization is not enough.

Useful deliverables include:

An executive risk summary

Leadership needs to know which critical services or processes are exposed, what types of paths were validated, which control gaps drive the risk, and what investments would reduce it.

Evidence-backed attack paths

Each important path should show the starting point, intermediate systems, attacker actions, access conditions, trust-boundary crossings, target asset, and supporting evidence. Assumptions and confidence levels should be explicit.

Control-gap analysis

The report should identify where preventive controls failed, where detection may provide visibility, and where no control is associated with a step. It should also recognize controls that successfully block modeled behavior.

Engineering-ready remediation priorities

Recommendations should identify the owner, affected systems, operational dependencies, expected path reduction, validation method, and any required outage or vendor involvement.

Coverage and uncertainty documentation

Teams need to know which zones, data sources, scenarios, and techniques were included. Missing data, model assumptions, and excluded assets should be documented so that results are not interpreted as universal proof.

Metrics for continued validation

Programs can track validated attack paths to critical assets, critical targets reachable from IT, paths removed through remediation, control-validation coverage, time to remediate, and time to revalidate.

Common adversary simulation mistakes

Treating simulation as a larger vulnerability scan

The purpose is not to generate the maximum number of findings. It is to establish which combinations of conditions enable consequential movement and where defenses can interrupt it.

Testing only inside the OT network

An internal OT scope may miss enterprise identities, remote services, vendors, DMZ systems, and management dependencies that enable the initial pivot. Scope should follow realistic attack routes rather than organizational ownership boundaries.

Assuming visibility equals validation

Knowing that two assets communicate does not establish that an attacker can exploit the relationship. Conversely, an asset absent from a dashboard may still be represented indirectly through firewall, flow, or configuration data. Visibility is an input, while attack-path evidence is the outcome.

Claiming safety without defining isolation

A safe assessment should clearly explain which analysis occurs in the twin, whether any live traffic is generated, and how production confirmation is governed. Vague claims about non-disruptive testing are not a substitute for documented boundaries.

Trusting opaque AI conclusions

AI can help reason across large numbers of assets and possible action sequences. Findings still need traceable evidence, understandable logic, confidence indicators, and human review. Teams should be able to challenge assumptions and reproduce the reasoning behind priority paths.

Failing to involve operations and engineering

Security teams can identify technical routes, but operators and engineers understand process criticality, maintenance constraints, vendor requirements, and potential consequences. Their involvement improves both model fidelity and remediation feasibility.

Stopping after the report

A validated path should become a tracked remediation item. After a change, the scenario should be rerun to prove that the path has been broken.

How to evaluate an OT adversary simulation solution

Organizations comparing platforms or services should ask practical questions about safety, evidence, coverage, and actionability.

Environment modeling

• Which data sources can the solution ingest?
• How does it normalize inconsistent asset and network data?
• Can it model IT, DMZ, and OT dependencies together?
• How are missing data and uncertain relationships displayed?

Safety

• Does simulation occur in a cyber digital twin or on live production assets?
• What production interaction, if any, is required?
• How are dangerous actions represented without executing them?
• Can operations teams review boundaries before assessment?

Adversary reasoning

• Can the solution evaluate multiple paths rather than a fixed sequence?
• Does it support OT-specific techniques and industrial architecture?
• Can reviewers see the evidence and assumptions behind each action?
• How are impossible, plausible, and validated paths differentiated?

Results and remediation

• Are findings linked to critical assets and operational consequences?
• Can the solution identify choke points that eliminate several paths?
• Does it recommend compensating controls when patching is impractical?
• Can teams test proposed changes before implementing them?
• Can simulations be rerun as the environment changes?

Program fit

• Does it complement existing asset visibility, vulnerability management, monitoring, and assessment tools?
• Can security and engineering teams use the same evidence?
• Are outputs suitable for technical remediation and executive reporting?

The goal is not to replace existing controls or teams. Adversary simulation should validate those investments, expose the gaps between them, and help teams direct limited resources toward proven risk.

How Frenos approaches OT adversary simulation

Frenos is an AI-driven OT cybersecurity platform designed for critical infrastructure and industrial environments. It combines agnostic data ingestion, operationalized intelligence, and empirical evidence to model environments and validate attack paths.

The platform uses a cyber digital twin to simulate adversary techniques without testing live production systems. This allows teams to evaluate IT-to-OT and OT attack paths while avoiding intrusive activity against controllers and other sensitive assets.

Frenos focuses on proving exploitability and attack-path conditions rather than producing vulnerability lists alone. Its autonomous assessments are intended to help teams identify where defenses hold, where paths remain open, and which mitigations can produce the greatest practical reduction in risk.

At S4x26, Frenos reported a specific event example in which the platform simulated 154,000 OT attack paths in 17 minutes and validated 18 exploitable paths. This result reflects that event and environment, not a universal performance expectation.

Organizations can also begin with a one-day simulated OT penetration test focused on building a twin, identifying attack paths, and evaluating defenses.

Move from findings to proof

OT security teams already have asset inventories, vulnerability findings, architecture diagrams, firewall reviews, and monitoring alerts. The unresolved question is whether those pieces work together well enough to stop an attacker from reaching critical systems.

Adversary simulation answers that question by connecting environment data, attacker behavior, and control conditions into evidence-backed paths. A cyber digital twin makes it possible to explore those paths without forcing teams to choose between realistic testing and production safety.

Frenos helps critical infrastructure organizations validate IT-to-OT and OT attack paths, prioritize engineering action, and continuously reassess defenses without testing live production systems.

[Request a demo](https://frenos.io/contact) to see attack paths in your OT environment and assess defenses without production impact.