Vulnerability assessments answer an important but incomplete question: what weaknesses exist in our environment? On their own, however, they do not explain which weaknesses matter most, how they could be exploited, or the consequences of such exploitation.
Threat modeling addresses that gap.
In operational technology (OT) environments, threat modeling serves as the connective tissue between technical vulnerabilities and real-world risk. It shifts the focus from enumerating flaws to understanding how systems fail, how adversaries operate, and where defensive efforts yield meaningful risk reduction.
This post explores threat modeling for industrial systems: what it is, how it differs from IT-focused methods, and how to implement it in a way that reflects operational reality rather than just theoretical attack trees.
What Threat Modeling Means in OT
Threat modeling is a systematic analysis of how an adversary might intentionally compromise, disrupt, or manipulate a system.
In traditional IT environments, threat modeling usually focuses on risks like data exposure, unauthorized access, service downtime, and misuse of application logic. These issues align with the main goal of most enterprise systems: storing, processing, and transmitting data. However, OT environments face unique challenges. They interact directly with physical processes, so a breach’s impact goes beyond information security. A solid threat model must consider how the physical process behaves, how safety interlocks and fail-safe modes operate, and how operators monitor and control the system. Because of this, effective threat modeling in OT doesn’t start with attackers or vulnerabilities. It begins with understanding the process itself: what the system controls, how it normally behaves, and which outcomes must never occur.
Some example scenarios used in an OT threat modeling exercise could include an attacker manipulating process variables without triggering obvious alarms, reducing operators’ visibility into the process, or disruptions that spread through interconnected industrial systems.
These types of scenarios highlight both the value and the complexity of threat modeling in OT. While the insights can be powerful, developing them requires time, context, and cross-functional collaboration which are factors that are often difficult to align.
Why Threat Modeling Is Often Skipped in OT
Despite its value, threat modeling is often missing or superficial in OT security programs. Common reasons include:
- Perception that it is too abstract or theoretical
- Lack of cross-disciplinary participation
- Over-reliance on vulnerability scanning outputs
- Time and resource constraints
- Uncertainty about how to operationalize results
Ironically, many of the same organizations will later commission penetration tests or red team exercises without first determining which attack paths are relevant. Performing threat modeling is not optional groundwork; it is the foundation that makes other assessments meaningful. Without setting a firm foundation, vulnerability scans, penetration tests, and red team exercises risk focusing on technical weaknesses that may have little connection to real operational impact.
This gap often stems from applying IT-centric thinking to OT environments that start with systems and tools instead of what truly matters: the process itself.
Starting with Process, Not Technology
The primary distinction in threat modeling between IT and OT lies in their initial focus. IT threat modeling usually starts with software and system architecture.
In OT environments, threat modeling begins with understanding the process. Analysts must identify what the system controls, how it functions normally, and how it responds when components fail or conditions deviate from expectations. It’s also important to understand the safeguards put in place to prevent unsafe states, such as safety interlocks, automated shutdown procedures, and operator intervention actions. This involves collaborating with control engineers, operator teams, and safety personnel, not just security staff.
Image 1- OT Threat Modeling
As shown in Image 1- OT Threat Modeling, this process-driven approach begins with analyzing the physical or industrial process of a specific system. Once the process is well understood, the next step is to identify relevant vulnerabilities within the supporting systems and evaluate whether they are realistically exploitable in that context. Only then can the potential impact be accurately assessed. This sequence of understanding the process, analyzing vulnerabilities, evaluating exploitability, and assessing impact ensures that threat modeling remains grounded in actual operational risk rather than theoretical technical flaws.
Key questions that should be considered include:
- What physical outcomes are unacceptable?
- What variables, if manipulated, could cause those outcomes?
- How quickly would operators detect abnormal behavior?
- What automated protections would intervene?
Threat modeling for an OT/ICS environment that does not incorporate process behavior is, by definition, incomplete.
Once the process is understood, the next step is to consider how an adversary might attempt to influence it.
Defining Attacker Objectives in OT
Unlike many IT intrusions, attacks on OT environments are typically not motivated primarily by data theft. Instead, adversaries often aim to disrupt the physical process, operational continuity, or safety of the controlled system. In practice, this means the attacker’s goal is rarely to compromise a device itself. Rather, the breach is used to influence the process behavior or how operators perceive and manage it. Effective threat modeling, therefore, requires identifying the operational outcomes an attacker might try to achieve, as these outcomes determine which attack paths and vulnerabilities are relevant.
Examples of attacker objectives in OT environments may include:
- Disrupting production or service delivery
- Forcing a controlled shutdown of a process or facility
- Creating unsafe operating conditions
- Preventing operators from accurately observing the process state
- Manipulating sensor data to induce incorrect control actions
- Delaying or disabling safety responses
- Causing equipment damage or process instability
- Using operational disruption to achieve broader strategic goals
Defining these objectives helps threat modeling go beyond generic vulnerability lists and focus on realistic attack scenarios. Once the desired outcome is clear, analysts can determine which systems an attacker would need to access, the paths they might use to reach them, and the vulnerabilities that could enable those objectives.
Threat Actors and Capability Assumptions
Even when threat actors have the intent to target a specific system, threat modeling must account for their actual capabilities. Intent alone does not guarantee success. Just because an adversary wants to carry out an attack does not mean they have the means to do so.
In OT environments, threat actors may include:
- Opportunistic attackers who discover and exploit exposed systems such as internet-facing remote access services or poorly secured industrial gateways.
- Criminal groups that target organizations for financial leverage, often seeking to disrupt operations or deploy ransomware to pressure organizations into payment.
- Insiders with engineering knowledge who understand operational workflows, control logic, and maintenance procedures, giving them the ability to manipulate systems in ways that may be difficult to detect.
- Nation-state or state-aligned actors with advanced technical capabilities who may target industrial environments as part of broader strategic objectives, particularly in critical infrastructure sectors.
- Vendors or contractors with legitimate access whose credentials, remote access channels, or maintenance tools may unintentionally provide pathways into critical control systems.
Each class of actors has distinct access pathways, skill levels, and risk tolerance.
A threat model that assumes an “Advanced Persistent Threat” (APT) for every system is as unhelpful as one that assumes only script-kiddie behavior. The goal is to model credible adversaries based on the organization’s sector, exposure, and threat intelligence. At the same time, a threat model must make deliberate choices about where to focus. The scope of the system being analyzed, the criticality of the processes involved, and the maturity of the organization’s security program all influence which adversaries and attack scenarios deserve the most attention.
Mapping Attack Paths Through OT Architectures
Once adversary objectives and capabilities are defined, threat modeling shifts to identifying how those objectives could realistically be achieved. This requires mapping the attack paths that exist within the environment.
In operational technology environments, these paths rarely stay confined to a single network segment. Instead, they often cross multiple layers of infrastructure that were designed for operational convenience rather than strict security separation. A typical attack path might involve moving through enterprise IT networks, remote access systems, engineering workstations, control networks, and sometimes even safety systems or field devices. Unlike modern IT environments, where trust boundaries are often clearly enforced through segmentation, authentication controls, and monitoring, OT architectures tend to rely on implicit trust relationships. Flat networks, shared credentials, dual-connected systems, and engineering laptops that shift between networks are still common in many facilities. These architectural features create natural pathways that an attacker could exploit to move from less critical environments toward systems that control the physical process.
Threat modeling reveals these pathways by systematically analyzing how systems communicate and where trust assumptions are made. Questions that usually guide this analysis include:
- Where are the actual boundaries of trust within the environment?
- Where are trust boundaries assumed but not technically enforced?
- Which systems act as bridges between security zones?
- How could access escalate from business networks into control networks?
- What systems could allow an attacker to pivot deeper into the environment?
This process often shows that the biggest risks don’t come from advanced exploits. Instead, they stem from common architectural choices: a remote access server placed directly inside a control network, shared credentials across multiple systems, or maintenance laptops that regularly connect to various zones. By clearly mapping these paths, organizations can better understand how an attacker might realistically move through the environment and which architectural changes would most effectively lower the risk.
Ultimately, these attack paths tend to converge on a small number of critical outcomes most notably, the loss of visibility into the process or the loss of control over it.
Loss of View, Loss of Control, and Beyond
A key concept in OT threat modeling is the distinction between loss of view and loss of control. Loss of view occurs when operators cannot accurately observe the true state of the process. Loss of control occurs when operators or automation systems are no longer able to influence how the process functions.
Many high-impact OT incidents involve a loss of view that occurs before a loss of control. If operators cannot see what is happening inside the process, they might unknowingly make decisions that worsen unsafe or unstable conditions. Threat modeling must therefore consider scenarios where attackers manipulate the information operators depend on to understand the system, such as altering HMI displays, suppressing or falsifying alarms, delaying operators’ awareness of abnormal conditions, or exploiting operators’ trust in system feedback. However, loss of view and loss of control are just two examples of operational impacts an attacker might target. Frameworks like MITRE ATT&CK for ICS identify a broader range of potential objectives under the Impact category, including actions like manipulating control logic, inhibiting safety protections, damaging equipment, or forcing shutdowns of industrial processes.
In practice, attackers targeting OT systems may pursue multiple overlapping goals. They might try to manipulate process variables while hiding the effects from operators, reduce the reliability of control systems, or undermine trust in the information operators rely on. As a result, vulnerabilities that allow subtle manipulation or delayed detection can sometimes be more dangerous than those that cause immediate and obvious disruptions.
Effective threat modeling, therefore, considers not only whether a system can be compromised but also how that compromise could impact process visibility, control authority, safety mechanisms, and operational stability.
To make that analysis actionable, vulnerability data must be tied directly to these potential outcomes.
Integrating Vulnerability Data into Threat Models
Threat modeling does not replace vulnerability assessments; it contextualizes them. Vulnerability data becomes meaningful when mapped to:
- Specific attack steps
- Required access conditions
- Likely attacker behavior
- Process consequences
For example, a vulnerability on an engineering workstation may be low priority in isolation, but critical if it allows modification of control logic without detection.
This integration helps organizations prioritize remediation by risk contribution rather than by severity scores.
Some of the most important scenarios identified through this process involve the systems designed to prevent catastrophic outcomes.
Safety Systems and Threat Modeling
Safety instrumented systems (SIS) pose a unique challenge for threat modeling because they are designed to serve as an independent protection layer. Their role is not to control the process during normal operation but to intervene when the process approaches unsafe conditions.
Because SIS acts as a final line of defense against hazardous states, threat modeling must consider not only whether they can be compromised but also whether their independence from the basic control system is truly maintained.
Many organizations assume that safety systems are inherently isolated and therefore trustworthy. In practice, threat modeling often reveals operational dependencies that weaken this assumption. Shared engineering workstations, common maintenance procedures, network connectivity for monitoring or diagnostics, and configuration practices can create pathways through which SIS might be influenced indirectly.
Threat modeling does not assume safety systems are compromised by default. Instead, it assesses whether the design assumptions about their independence hold true in the real environment. If the systems meant to prevent unsafe conditions share the same infrastructure, credentials, or engineering tools as the systems they aim to protect, that independence might be weaker than intended.
Because of their role in preventing hazardous outcomes, even minor weaknesses in safety system isolation can greatly change the risk profile of an industrial environment.
But identifying these weaknesses is only part of the process, confirming that they reflect real operational conditions is just as critical.
Validating Threat Models with Reality
Threat models must be based on how systems actually operate, not just how they are documented or theoretically designed. Architectural diagrams, policy documents, and design assumptions often do not capture the full complexity of an operational environment. Therefore, threat models should be validated against real workflows, system configurations, and operational practices.
Validation usually involves combining different perspectives instead of relying on one technique. Walkthroughs with control engineers and operators can show how systems are actually used and maintained. Architecture reviews help verify whether trust boundaries and network separations are correctly implemented. Tabletop exercises can confirm if modeled attack scenarios match how incidents might happen in real operations. In some environments, carefully scoped and non-intrusive testing can verify if the proposed attack paths are technically possible. Past incidents, both internal and industry-wide, also offer valuable insights into how industrial systems have been compromised or disrupted. No single technique provides a complete picture. The goal is to cross-check the threat model with actual operational conditions until the modeled attack paths accurately reflect plausible scenarios in the environment.
Plausibility and consequence are evaluated by analyzing three factors: attacker capability, system architecture, and process impact. A technically advanced attack may appear unlikely if it requires unrealistic access or conditions, while a simple attack route can be highly impactful if it allows manipulation of critical process variables or safety systems. Therefore, threat modeling focuses on scenarios that are both technically feasible and operationally relevant. The aim is not to list every possible attack but to identify the scenarios most likely to disrupt operations, damage equipment, or create unsafe conditions.
From this analysis, the value of threat modeling becomes clear in how it informs decisions about design, protection, and response.
Outputs That Matter
A useful OT threat model produces outputs that directly inform engineering and security decisions.
These typically include:
- Clear articulation of high-risk scenarios
The threat model should identify specific situations where an attacker’s actions could cause significant operational effects. For example, it might describe how unauthorized access to an engineering workstation could enable modification of PLC logic controlling a critical pump, potentially resulting in equipment damage or unsafe pressure conditions. - Prioritized attack paths
Rather than listing every potential vulnerability, threat modeling pinpoints the most likely paths an attacker could take to access critical systems. An example might be a route starting with compromised remote access credentials, passing through a jump host or engineering workstation, and ultimately enabling changes to control logic on the plant network. - Identification of weak trust boundaries
Threat modeling often identifies hidden connections or shared dependencies between systems that are assumed to be separate. For example, a threat model might show that the engineering workstation used to manage control systems is also connected to the corporate network, unintentionally linking IT and OT environments. - Insight into detection and response gaps
Threat models can identify potential points of malicious activity that might go unnoticed. For instance, they may show that changes to PLC logic or safety system configurations are not sufficiently monitored or logged, making it difficult for operators or security teams to detect unauthorized modifications. - Guidance for control selection and investment
Threat modeling helps organizations focus on the most critical attack paths, enabling them to prioritize security improvements. This may include strengthening authentication for remote engineering access, isolating engineering workstations from enterprise networks, or adding monitoring to detect control-logic changes.
However, realizing these benefits depends heavily on how threat modeling is conducted. When key considerations are overlooked, the exercise can quickly lose its impact.
Common Threat Modeling Pitfalls
Even well-intentioned threat modeling efforts can diminish in effectiveness if common mistakes are not avoided. Some of the most frequent pitfalls include:
- Overly generic attacker profiles
Modeling every adversary as an “advanced persistent threat” creates unrealistic scenarios, while assuming only unsophisticated attackers can ignore credible risks. Threat models should represent adversaries that are plausible for the organization’s sector, exposure, and operational context. - Overdependence on IT-focused models can be problematic.
Traditional IT frameworks often concentrate on data theft, credential compromise, and service downtime. While these concerns remain important, OT threat modeling must also address process manipulation, operator awareness, and physical consequences. - Ignoring process and safety considerations
Threat models that focus solely on network diagrams or device inventories miss the most essential question: what physical consequences could result from system manipulation? Without understanding the process, it becomes difficult to determine which attack paths are genuinely significant. - Treating threat models as static documents
Threat models are sometimes created during an assessment and then left unchanged for years. In operational environments, however, systems evolve continuously.
Threat modeling should be considered an ongoing process rather than a one-off task. As systems are upgraded, vendors introduce new remote access methods, or operational practices evolve, the assumptions that once defined trust boundaries and attack paths might become outdated. Regularly revisiting the model helps ensure it accurately represents the current environment rather than an outdated architecture diagram.
Where Threat Modeling Fits in the Assessment Lifecycle
Threat modeling bridges the gap between vulnerability assessment and active testing.
It informs:
- Which vulnerabilities matter most
- Where penetration testing is justified
- What red team objectives should be
- Which detections should be validated through purple teaming
Without threat modeling, later assessment activities risk being unfocused or misaligned.
Conclusion
Threat modeling is not an abstract exercise reserved for mature security programs. In OT environments, it translates technical findings into a clearer understanding of operational risk. By starting with process behavior, defining credible adversaries, and mapping realistic attack paths, threat modeling helps organizations prioritize defenses where they matter most.
Once threat modeling identifies the most plausible attack paths, penetration testing can be used selectively to validate whether those paths are technically achievable. In the next post we will explore penetration testing, examining how and when it should be deployed.
At Enaxy, we help organizations apply threat modeling in a way that reflects the realities of industrial operations. Our team works with engineering, operations, and security stakeholders to identify credible threat scenarios, evaluate how attacks could affect critical processes, and prioritize mitigations that protect safety, reliability, and uptime.
If you need help building or refining an OT threat modeling program, contact Enaxy at info@enaxy.com.