How to Build an OT Adversary Simulation Program

An OT adversary simulation program tests whether realistic attack paths can reach critical industrial systems and whether existing defenses can stop them. Unlike a one-time exercise or a vulnerability scan, the program establishes a repeatable process for selecting threats, modeling the environment, simulating adversary behavior, validating controls, and measuring risk reduction.

Building this capability requires a different approach from conventional IT testing. Safety, availability, deterministic processes, legacy assets, and vendor support constraints limit what can be tested directly in production. A mature OT program must preserve operational integrity while still producing evidence about exploitability and attack paths.

This implementation guide provides a practical roadmap for moving from an initial use case to continuous OT security validation.

1. Define the program’s purpose and outcomes

Start with the decisions the program needs to support. “Run adversary simulations” is an activity, not an outcome.

Useful program objectives include:

• Determine whether an attacker can move from enterprise IT into critical OT zones
• Validate whether segmentation and industrial DMZ controls block unauthorized paths
• Test defenses against specific threat actor tactics, techniques, and procedures
• Identify exploitable combinations of vulnerabilities, credentials, routes, and trust relationships
• Prioritize mitigations based on operational consequence and proven reachability
• Measure whether remediation closes an attack path
• Improve detection logic and incident response procedures

Document the initial use case in a short program charter. The charter should identify the environments in scope, critical consequences to prevent, accountable owners, required evidence, safety constraints, and reporting cadence.

The first phase should be narrow enough to deliver evidence quickly. For example, begin by asking whether a compromised engineering workstation or IT identity could provide a path to a safety-relevant OT zone. Expand scope after the team has established a repeatable workflow.

2. Establish joint IT, OT, and engineering governance

OT adversary simulation cannot be owned by the security team alone. Results may affect firewall rules, remote access, engineering workflows, vendor connections, maintenance schedules, and safety controls.

Create a cross-functional working group that includes:

• An executive sponsor who can resolve ownership and funding issues
• An OT security program owner
• Plant operations and engineering representatives
• IT security, identity, network, and incident response teams
• Control system or SCADA engineers
• Safety and compliance stakeholders when relevant
• Asset owners and third-party vendors for systems in scope

Define responsibilities before the first simulation. Security teams may own scenario design and evidence analysis, while asset owners approve models and remediation actions. Engineering should review assumptions involving protocols, system dependencies, and physical consequences.

Governance should also define how sensitive outputs are handled. Validated paths, credentials, network relationships, and defensive gaps may require tighter access controls than a typical assessment report.

3. Set explicit safety and testing rules

Live adversary activity can create unacceptable risk in industrial environments. Fragile controllers, unsupported operating systems, proprietary protocols, and process dependencies may respond unpredictably to scanning or exploitation.

Write rules of engagement that address:

• Whether any action may interact with production assets
• Prohibited techniques and systems
• Safety system and controller exclusions
• Approved data sources
• Credential and sensitive-data handling
• Simulation approval and review requirements
• Escalation procedures for unexpected findings
• Conditions that require a pause or stop

A cyber digital twin can separate attack-path testing from production execution. The twin models assets, vulnerabilities, network routes, trust relationships, security controls, and potential adversary actions using available environment data. Simulations can then evaluate dangerous or disruptive paths without sending exploit traffic to live controllers.

This does not eliminate the need for model governance. Teams should record data freshness, inferred relationships, known blind spots, and confidence levels. Simulation results are strongest when their assumptions and supporting evidence are transparent.

4. Build an environment model from available data

Perfect visibility is not a prerequisite for starting, but the program needs enough context to represent relevant attack paths.

Potential inputs include:

• Asset inventories and passive discovery data
• Firewall rules and network configurations
• Network flow and communication data
• Vulnerability and configuration findings
• Identity, directory, and privileged access information
• Remote access and vendor connection records
• Architecture diagrams and zone definitions
• Endpoint, EDR, SIEM, and OT monitoring data
• Control inventories and compensating-control documentation

Normalize these sources into a model that connects assets, communications, vulnerabilities, identities, access conditions, and controls. Agnostic ingestion is valuable because OT data is commonly fragmented across security, infrastructure, engineering, and vendor systems.

Validate the model with people who understand the plant. A firewall rule may permit a route that operations believes is unused. An engineering relationship may exist even when it is missing from an inventory. These discrepancies are themselves useful findings.

Prioritize fidelity around critical assets and trust boundaries rather than delaying the program until every device is documented.

5. Identify critical assets and unacceptable consequences

Adversary simulation should begin with operational consequence, not a list of techniques.

Identify systems whose compromise could contribute to:

• Loss of control or visibility
• Unsafe process states
• Production interruption
• Environmental impact
• Equipment damage
• Manipulation of recipes, setpoints, or logic
• Loss of critical services
• Extended recovery due to specialized replacement requirements

Map the assets, applications, identities, and communication paths that support these functions. This produces a consequence-oriented target set and prevents the team from treating every reachable device as equally important.

6. Develop realistic adversary scenarios

Build scenarios around credible entry points, objectives, and paths. MITRE ATT&CK for ICS can provide a common vocabulary, but technique coverage should not become the sole measure of success.

Each scenario should define:

1. Starting condition: A compromised IT account, vendor laptop, remote access service, exposed host, or OT workstation.
2. Adversary objective: Reach an engineering system, disrupt visibility, modify control logic, or establish access to a critical zone.
3. Relevant behaviors: Discovery, credential access, lateral movement, remote services, valid account use, command and control, or manipulation of control functions.
4. Defenses expected to intervene: Segmentation, identity controls, endpoint protection, monitoring, allowlisting, or operational procedures.
5. Success criteria: Evidence that the path is blocked, detectable, partially viable, or exploitable.

Begin with three to five high-value scenarios. Include at least one IT-to-OT path, one remote access or third-party path, and one path that begins inside OT. Add threat-specific scenarios when intelligence indicates that a particular adversary is relevant to the organization.

7. Simulate complete attack paths

Testing isolated techniques can confirm that a control responds to a known action. It does not necessarily establish whether an adversary can combine weaknesses to reach a critical system.

A complete simulation should evaluate chains such as:

• Initial access to a reachable IT asset
• Credential or privilege acquisition
• Movement through an enterprise or industrial DMZ
• Entry into an OT zone
• Access to an engineering workstation or management service
• Reachability of a critical control asset
• Defensive opportunities at each step

For each step, preserve the evidence supporting the conclusion. Useful evidence includes the required access condition, allowed communication, relevant vulnerability, credential relationship, control state, and reason the step could or could not succeed.

This evidentiary approach also helps teams evaluate AI-generated analysis. Findings should be reviewable and linked to the environment conditions that make a path possible, rather than presented as unexplained conclusions.

8. Prioritize paths by consequence and exploitability

Do not rank results solely by vulnerability severity. A high-scoring vulnerability may be isolated from critical operations, while several moderate weaknesses may combine into a viable path to a high-consequence asset.

Prioritize each validated path using factors such as:

• Operational consequence of the target
• Evidence that the path is reachable
• Number and strength of controls an attacker must bypass
• Credential and privilege requirements
• Exposure through IT, remote access, or third parties
• Availability of practical mitigations
• Detection and response coverage
• Confidence in the underlying model

Translate each path into an engineering-relevant action. Recommendations may include removing an unnecessary route, narrowing a firewall rule, separating administrative identities, hardening remote access, deploying a compensating control, improving monitoring, or changing an operational process.

The output should explain which action breaks the path and what residual risk remains.

9. Validate remediation through retesting

An adversary simulation program creates value when it proves that defenses improve. After remediation, rerun the affected scenario and confirm whether the path is closed, displaced, or still exploitable through an alternative route.

Use a simple lifecycle:

1. Validate the attack path.
2. Assign an owner and mitigation.
3. Model or implement the change.
4. Rerun the scenario.
5. Record the new result and residual risk.
6. Monitor the environment for changes that could reopen the path.

Digital-twin simulation can help teams compare proposed controls before modifying production. It can also support more frequent reassessment after firewall changes, new vendor connections, asset additions, vulnerability disclosures, or architecture updates.

Simulation should enhance existing vulnerability management, monitoring, penetration testing, and engineering processes. It does not replace those teams or controls.

10. Measure program performance

Vulnerability counts and the number of simulated techniques are activity measures. Program metrics should show whether exposure to operational consequences is declining.

Track metrics such as:

• Number of validated paths to critical assets
• Percentage of critical assets covered by scenarios
• IT-to-OT paths identified and closed
• Time from path validation to mitigation
• Percentage of remediated paths successfully retested
• Detection coverage across simulated paths
• Number of paths blocked at each security boundary
• Model freshness and data-source coverage
• Recurrence rate for previously closed paths
• Change in attack-path exposure over time

Report technical details to engineers and aggregate consequence-based trends for leadership. Executives need to understand which operational risks were reduced, not how many simulation actions were executed.

A phased OT adversary simulation implementation roadmap

First 30 days: Establish the foundation

• Approve the program charter and governance model
• Select one environment and critical consequence
• Define safety rules and data-handling requirements
• Gather available architecture, asset, firewall, flow, identity, and vulnerability data
• Build and validate the initial environment model

Days 31 to 60: Run the initial scenarios

• Select three to five realistic scenarios
• Map relevant ATT&CK for ICS techniques and expected controls
• Simulate complete paths in the digital twin
• Review evidence with security and engineering stakeholders
• Assign mitigations for the highest-priority paths

Days 61 to 90: Operationalize the program

• Retest completed mitigations
• Establish dashboards and reporting
• Document scenario and model update procedures
• Integrate results with vulnerability management and risk processes
• Define triggers for reassessment
• Plan expansion to another plant, zone, or consequence category

Common implementation mistakes

Avoid these frequent failure modes:

• Treating vulnerability discovery as proof of exploitability
• Copying an IT red-team methodology into OT without safety constraints
• Measuring success only by technique coverage
• Building scenarios without operations and engineering input
• Waiting for a perfect inventory before beginning
• Producing attack diagrams without supporting evidence
• Reporting findings without naming the control that can break the path
• Running a one-time exercise without remediation retesting
• Assuming a closed path cannot return after an architecture change

Build from a focused assessment to continuous validation

A successful OT adversary simulation program starts with a specific operational question, produces transparent evidence, and creates a closed loop between testing and remediation. Over time, the program can expand across plants, threat actors, remote access paths, critical functions, and control families.

Frenos uses cyber digital twins and simulated adversary techniques to validate IT-to-OT and OT attack paths without testing live production systems. Its approach combines agnostic data ingestion, operationalized intelligence, and empirical evidence so teams can focus on exploitable paths rather than vulnerability lists alone.

At S4x26, Frenos reported simulating 154,000 OT attack paths in 17 minutes and validating 18 exploitable paths. This was a specific event example, not a universal performance expectation. Actual scope and performance depend on the environment, available data, and assessment objectives.

Request a demo to see attack paths in your OT environment and assess defenses without production impact.