OT Adversary Simulation Scenarios: A Practical Library for ICS and SCADA Teams

OT adversary simulation scenarios help industrial security teams answer a practical question: Could a realistic attacker reach systems that affect operations, safety, quality, or availability, and would existing defenses stop or detect the path?

A useful scenario is more than a list of attacker techniques. It connects an initial foothold to a credible operational consequence through the actual relationships among enterprise IT, remote access, industrial DMZs, engineering workstations, historians, SCADA servers, human machine interfaces, and controllers.

This scenario guide provides a reusable library for ICS and SCADA teams. Each scenario includes an objective, attack-path hypothesis, controls to evaluate, evidence to collect, and safety considerations. The scenarios are intentionally outcome-focused. They do not include exploit instructions or recommend intrusive activity against production assets.

How to use this OT adversary simulation scenario library

Select scenarios according to business consequence and architecture, not only threat popularity. A water utility, manufacturer, pipeline operator, and power organization may share technologies while facing different operational impacts.

For each scenario, define:

1. Protected outcome: The process, service, safety function, or production capability that must remain dependable.
2. Starting position: The access an adversary is assumed to have, such as a compromised IT account, vendor credential, or exposed remote access service.
3. Target: The OT system or trust boundary the scenario attempts to reach.
4. Attack-path hypothesis: The sequence of access, relationships, weaknesses, and control gaps that could connect the starting position to the target.
5. Constraints: Systems and actions excluded because of safety, uptime, regulatory, or equipment concerns.
6. Expected controls: Preventive, detective, and recovery measures that should interrupt the scenario.
7. Evidence: Logs, policy decisions, configuration data, modeled paths, alerts, and response records needed to support a conclusion.
8. Success criteria: The specific condition that constitutes prevention, detection, containment, or validated exposure.

Technique-level control checks can be useful, but they should not be mistaken for complete adversary simulation. Frenos explains the distinction between individual control validation and end-to-end paths in its guide to [BAS vs adversary simulation](https://frenos.io/resource/bas-vs-adversary-simulation).

Scenario 1: Compromised IT identity pivots into OT

Objective: Determine whether a compromised enterprise identity could help an attacker traverse IT and OT trust boundaries.

Attack-path hypothesis: An attacker obtains an IT user or administrator account, accesses shared infrastructure, reaches the industrial DMZ, and then discovers an allowed route or reusable identity leading toward OT management systems.

Evaluate:

• Separation of IT and OT identity systems
• Privileged access management and multifactor authentication
• Firewall rules between enterprise, DMZ, and control zones
• Administrative jump hosts and session controls
• Credential reuse and service account exposure
• Detection of unusual authentication and cross-zone movement

Evidence of value: Identify the exact identity, host, conduit, and policy relationships that make the route possible. A finding such as “MFA is missing” is less actionable than proof that the missing control enables access to a specific critical zone.

Scenario 2: Vendor remote access is misused

Objective: Test whether a stolen or abused third-party account could provide unauthorized access to industrial assets.

Attack-path hypothesis: An attacker uses valid vendor credentials, enters through an approved remote access service, gains access beyond the vendor’s intended scope, and reaches engineering or supervisory systems.

Evaluate:

• Vendor-specific accounts and least privilege
• Time-limited access approval
• Multifactor authentication
• Segmentation behind remote access gateways
• Session recording and command oversight
• Dormant account removal
• Incident response ownership across organizational boundaries

Success criteria: The session is denied, restricted to approved assets, or detected and contained before it reaches a critical OT target.

Scenario 3: Industrial DMZ control failure

Objective: Validate whether the industrial DMZ prevents direct or indirect enterprise-to-control traffic.

Attack-path hypothesis: A dual-homed server, permissive firewall rule, management interface, data replication service, or overlooked conduit allows movement through the DMZ instead of forcing controlled mediation.

Evaluate:

• Deny-by-default firewall policies
• Dual-homed systems and routing behavior
• Historian, patching, antivirus, and file-transfer flows
• Administrative access paths
• Firewall management plane exposure
• Alerts for prohibited cross-zone connections

Evidence of value: Document which policy and system relationships permit the path, which controls should have blocked it, and the smallest change that would break the route without disrupting required operations.

Scenario 4: Engineering workstation compromise

Objective: Assess the consequences of an attacker gaining control of an engineering workstation.

Attack-path hypothesis: The attacker reaches an engineering workstation through remote administration, removable media, compromised software distribution, or an upstream identity. The workstation’s trusted relationships then provide access to control assets.

Evaluate:

• Application allowlisting
• Local and domain privilege
• Project file integrity and backup
• Controller authentication and access control
• Engineering protocol monitoring
• Workstation hardening and recovery procedures
• Separation between engineering and general-purpose activity

Because controller interaction can create physical consequences, validate dangerous actions in a representative lab or cyber digital twin rather than on production equipment.

Scenario 5: SCADA or HMI service disruption

Objective: Determine whether compromise of supervisory systems could impair operator visibility or control.

Attack-path hypothesis: The attacker reaches a SCADA server or HMI, abuses excessive privileges, interferes with services or configurations, and reduces the operator’s ability to monitor the process.

Evaluate:

• Redundancy and failover
• HMI and SCADA account privileges
• Configuration integrity monitoring
• Endpoint controls compatible with vendor requirements
• Alarm availability and independent process indications
• Restoration from known-good configurations
• Operator procedures for degraded visibility

Success criteria: Prevent compromise, generate timely detection, preserve alternate visibility, or recover within the organization’s defined operational tolerance.

Scenario 6: Historian becomes a bridge between zones

Objective: Test whether a historian or data integration server creates an unintended bidirectional attack path.

Attack-path hypothesis: A system designed to move process data to enterprise applications also exposes management services, reusable credentials, or permissive connections that support movement back toward the control network.

Evaluate:

• Directionality and necessity of data flows
• Service account scope
• Server placement and dual-homing
• Administrative access restrictions
• Database and application integrations
• Monitoring for reverse or unusual connections

This scenario is particularly valuable when asset inventories show the historian but do not reveal how identities, firewall rules, and application dependencies combine into an exploitable route.

Scenario 7: Ransomware reaches OT-supporting systems

Objective: Assess whether an enterprise ransomware event could interrupt OT operations even without directly manipulating a controller.

Attack-path hypothesis: Ransomware spreads from IT into shared identity, virtualization, backup, remote access, engineering, historian, or production management systems required to operate or recover the plant.

Evaluate:

• Segmentation and protocol restrictions
• Shared services and hidden dependencies
• Backup isolation and restoration readiness
• Privileged identity boundaries
• Endpoint containment procedures
• Manual operating capability
• IT and OT incident coordination

Measure operational dependency, not only malware propagation. A blocked path to PLCs does not mean production is resilient if essential engineering or supervisory services cannot be restored.

Scenario 8: Unauthorized controller access

Objective: Determine whether an adversary could reach a PLC, RTU, safety-related system, or other controller through trusted upstream assets.

Attack-path hypothesis: The attacker compromises a system permitted to communicate with controllers, inherits its network position or credentials, and attempts unauthorized control-related access.

Evaluate:

• Controller access control and operating modes
• Engineering workstation trust
• Zones, conduits, and industrial firewall policy
• Protocol-aware monitoring
• Logic and configuration change detection
• Independent safety protections
• Known-good logic backups

Do not test process-changing actions on live controllers unless they are explicitly engineered, approved, and proven safe. A digital twin can model the path and evaluate defensive decisions without issuing commands to production.

Scenario 9: Monitoring and response blind spot

Objective: Determine whether the security operations function can detect and investigate a multistage IT-to-OT intrusion.

Attack-path hypothesis: An attacker uses valid credentials and permitted services to move gradually, avoiding a single obvious malicious event.

Evaluate:

• Authentication telemetry across IT and OT
• Firewall, VPN, endpoint, and network sensor coverage
• Time synchronization
• Asset and identity context in alerts
• Escalation from the SOC to plant personnel
• Investigation procedures for industrial protocols
• Authority to isolate systems during an event

Success criteria: The team correlates weak signals into an attack path, identifies affected operational assets, and takes an approved action within the required time.

Scenario 10: Recovery control failure after compromise

Objective: Validate whether the organization can restore critical OT functions after a successful intrusion.

Attack-path hypothesis: An attacker compromises supervisory or engineering assets and damages configurations, credentials, or recovery dependencies before containment.

Evaluate:

• Offline and immutable backups
• Controller logic and configuration backups
• Recovery order and dependency mapping
• Replacement hardware and vendor availability
• Golden images and software licensing
• Credential reset procedures
• Recovery time assumptions
• Validation before reconnection to production

Adversary simulation should not stop at compromise. For many industrial organizations, the decisive control is the ability to restore a trustworthy operating state safely.

How to prioritize scenarios

Score candidate scenarios using five factors:

Start with high-consequence scenarios that have plausible routes and unproven controls. Avoid choosing scenarios only because a technique is fashionable or a vulnerability has a high severity score.

What a scenario report should deliver

A useful report should give engineers and security leaders more than a pass or fail result. Include:

• The starting condition and protected operational outcome
• A visual, evidence-supported attack path
• Assets, identities, vulnerabilities, and policies involved
• Preventive controls that held or failed
• Expected telemetry and observed detection coverage
• Operational constraints and assumptions
• Prioritized actions that break multiple attack paths
• Owners and validation criteria for each remediation
• Residual risk after proposed changes

This evidence helps vulnerability and assessment teams prioritize reachable, consequential weaknesses instead of producing another unranked findings list.

Validate scenarios without touching production

Live testing in OT can introduce unacceptable safety, uptime, equipment, and warranty risk. Limiting every exercise to harmless production actions reduces danger, but it can also leave the most important attack-path questions unanswered.

A cyber digital twin offers another option. Available firewall, network, asset, identity, vulnerability, and configuration data can be normalized into a model of the environment. Adversary techniques can then be simulated against that model to determine whether combinations of access and weaknesses create paths to critical systems.

Frenos uses agnostic data ingestion, operationalized intelligence, and empirical evidence to validate IT-to-OT and OT attack paths without touching production. The approach complements asset visibility, monitoring, vulnerability management, and human expertise. It does not replace those controls or the teams responsible for operating them.

For a broader explanation of methodology and scope, see the [OT red teaming guide to adversary simulation for ICS](https://frenos.io/resource/ot-red-teaming-complete-guide-to-adversary-simulation-for-ics). Teams evaluating the safety trade-offs can also review how [digital twins enable OT security testing](https://frenos.io/blog/how-digital-twins-are-changing-ot-security-testing).

Build a repeatable adversary simulation program

Run an initial set of scenarios against the most consequential systems, remediate validated paths, and repeat the scenarios after architecture, firewall, identity, or application changes. Over time, expand the library to include site-specific vendors, processes, threat intelligence, and recovery dependencies.

Useful program metrics include:

• Percentage of critical assets covered by at least one scenario
• Number of validated paths to critical zones
• Median time to detect and contain simulated movement
• Number of paths removed through remediation
• Percentage of remediations successfully retested
• Recovery objectives validated under realistic assumptions

The goal is not to run the largest number of scenarios. It is to prove which attack paths exist, determine where defenses hold, and direct engineering effort toward changes that reduce operational risk.

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