Threat scenarios for OT systems need to be detailed enough to drive concrete design, hardening, and response decisions, but not so granular that they become unmaintainable or fictional. You are modeling plausible, high-impact attack paths, not writing a full red-team script for every device.
Minimum useful level of detail
For regulated, brownfield OT environments, a threat scenario is usually detailed enough if it answers all of the following:
- Actor and intent: Who is the attacker class (e.g., ransomware group, insider with engineer access, supplier with VPN access) and what are they trying to achieve (encrypt HMIs, manipulate batch parameters, exfiltrate production data)?
- Entry point: Through which real interface do they first touch your environment (remote access, engineering workstation, vendor tunnel, USB, shared historian, misconfigured firewall rule)?
- Propagation path: How do they move from the entry to the OT target, given your actual network zones, protocols, and trust relationships (e.g., jump from IT to DMZ to historian to control network via shared credentials or unpatched service)?
- Targeted assets and functions: Which specific systems and functions are at risk (e.g., particular PLC families, batch servers, recipe management, quality data archive, safety instrumented systems)?
- Feasible technique: The type of technique used, at a realistic level (credential reuse, phishing + remote tools, use of default PLC password, abuse of engineering software, exploitation of known CVE on a particular OS). You rarely need packet-level exploit detail, but you should be past generic “malware” language.
- Operational impact and safety context: What can actually happen in your plant (e.g., loss of view, missequenced steps, incorrect setpoints, delayed alarms, unreconciled genealogy data), including impacts on quality records and regulatory evidence.
- Existing safeguards and detection: Which concrete controls could block, slow, or detect this path (network segmentation rules, application allowlisting, one-way data diode, procedures, dual-review for recipe changes, backup/restore practices).
- Residual risk and response: What still fails if the scenario occurs, and how you would contain and recover, considering realistic recovery times for OT assets and validated configurations.
If a scenario cannot be traced to specific assets, interfaces, and controls, it is usually too abstract to drive action. If it requires step-by-step exploit code or assumes redesign of your entire architecture, it is likely too detailed or unrealistic for planning.
Where OT scenarios should be more detailed than IT
Compared with pure IT threat modeling, OT scenarios typically need more detail in a few areas:
- Physical and process effects: Scenarios should identify which steps, equipment states, or recipes can be influenced, and what the credible worst-case outcomes are for production, product quality, and safety systems. You do not need full process simulation, but you do need to distinguish between, for example, “nuisance downtime” and “potential misbatch affecting thousands of units”.
- Legacy and vendor constraints: Detail which assets cannot be patched or easily reconfigured because of vendor qualification, validation burden, or obsolescence, and how attackers can exploit these stable weaknesses.
- Dependence on operational procedures: Many OT controls are procedural (lockout/tagout, dual sign-off for parameter changes, manual verification of alarms). Scenarios should capture when those procedures are bypassed, rushed, or dependent on a single person.
- Long lifecycle and static exposures: Because OT assets live for decades, scenarios must reflect long-lived exposures (e.g., a permanently unsupported OS on a critical HMI) rather than assuming quick tech refresh.
Where too much detail is counterproductive
There are clear points where more detail typically reduces, not increases, value:
- Overly specific attacker tools: Assuming a particular named malware family or exact exploit chain often ages poorly. Focus on classes of techniques and access vectors instead.
- Imaginary architectures: Scenarios that rely on not-yet-funded redesigns or tools provide little value. Scenarios must match the actual topology, as-built firewall rules, remote access paths, and user behaviors.
- Unmaintainable scenario catalogs: Hundreds of micro-scenarios that differ only slightly are hard to update through change control and validation. Most sites get more value from a smaller set of canonical scenarios mapped to multiple assets and lines.
- Granular exploit details without outcome clarity: Packet-level write-ups without a clear line to operational impact, evidence integrity, or regulatory exposure rarely help operations or quality leadership make decisions.
Balancing breadth vs. depth
In regulated manufacturing, threat scenarios must be scoped so they can be maintained under normal change control and validation practices. A practical approach is:
- Start with 10–20 core scenarios that cover your main classes of risk, for example:
- Remote vendor access abused to change PLC logic.
- Ransomware in IT spreading to HMIs and historians.
- Malicious or coerced insider using engineering tools to alter a recipe.
- Compromise of a shared database affecting batch records or genealogy.
- Misuse of a maintenance laptop as a propagation vector between lines or plants.
- Define each scenario at the level of zones, interfaces, and roles rather than at the level of every single device.
- Map assets and lines to these canonical scenarios (e.g., which areas of the plant are in scope for each scenario, which vendor tunnels or jump hosts participate).
- Deep-dive on a few high-consequence scenarios where you work through detailed steps, including exact systems, alarm behavior, and recovery times. These become reference scenarios for testing and exercising.
This provides enough detail to guide design, monitoring, and incident response, while remaining tractable as your environment and vendor stack evolve.
Integration with existing OT, MES, and quality systems
In brownfield plants, threat scenarios need to coexist with legacy MES, historians, QMS, and ERP. Key implications for level of detail include:
- Map scenarios to real integration points: Be specific about interfaces such as OPC servers, historians synchronizing to MES, or scripts pushing test results into QMS. These are frequent pivot points for attackers.
- Traceability and evidence: Scenarios should explicitly describe how attacks may corrupt or delay production records, electronic batch records, device history records, or calibration data, and how you would detect that using existing systems.
- Change control and validation: Only describe security improvements that you can realistically implement and validate across your mixed vendor environment. Aggressive redesign scenarios that would require requalification of major systems are often not actionable.
- Long maintenance windows: The detail you choose should acknowledge downtime limits. For example, specifying frequent, manual firmware updates for dozens of PLCs is not realistic in many regulated plants and should be reflected in the scenario residual risk.
How to know if your scenarios are at the right level
In practice, your threat scenarios are detailed enough if:
- Operations, engineering, and IT/OT security can all walk the path and agree it matches reality.
- They support concrete decisions: firewall changes, remote access policies, backup priorities, monitoring use cases, training, or procedural controls.
- They can be updated when assets, vendors, or integrations change, using your normal change control process.
- They are usable for tabletop exercises and incident response planning without needing extensive reinterpretation.
If they are too generic to guide any of those activities, they are not detailed enough. If every small change in a PLC firmware or vendor contract forces you to rewrite large parts of the scenario library, they are probably too detailed.