Operational Technology (OT) security has reached a point where high-level awareness is no longer the primary challenge. Many organizations operating industrial control systems (ICS) now know that there’s a problem with their environments being exposed, interconnected, and vulnerable to intentional cyber threats. But they do not know where to start and how to assess OT cyber risk accurately, safely, and in a way that meaningfully informs risk reduction.
Terms such as vulnerability assessment, threat modeling, penetration testing, red teaming, and purple teaming are often used interchangeably, even though they represent fundamentally different activities with distinct objectives, assumptions, and operational impacts. In IT environments, this ambiguity often leads to inefficiency. In OT environments, it can lead to unsafe conditions, production disruptions, or a false sense of security.
This blog series will describe clear technical boundaries among these assessment approaches, explain their appropriate use in OT environments, and provide guidance on how each, when properly applied, contributes to an overall industrial cyber risk management strategy.
The Problem with Applying IT Security Assessment Models to OT
Many security assessment methodologies currently used in OT originated in enterprise IT contexts. These methods assume systems that are:
- Designed for frequent patching and updates
- Built on standardized operating systems and protocols
- Recoverable through reboot, reimaging, or redundancy
- Tolerant of transient outages during testing
Industrial control systems violate nearly all these assumptions.
OT environments commonly include:
- Embedded controllers with limited memory, CPU, and fault tolerance
- Legacy operating systems that are no longer supported by vendors
- Proprietary or semi-proprietary protocols with undocumented behavior
- Tight coupling between cyber components and physical processes
- Safety functions that rely on deterministic timing and state stability
As a result, assessment techniques that are routine in IT, such as aggressive network scanning, automated exploitation, or uncontrolled credential testing, can cause process instability, device faults, or permanent equipment damage when applied indiscriminately in OT.
More importantly, IT-centric assessments often fail to answer the most important OT risk questions:
- Which failures would result in unsafe process conditions?
- Which cyber paths could realistically lead to loss of control or loss of view?
- Which mitigations reduce operational risk, not just technical exposure?
- Where do detection and response capabilities meaningfully degrade?
Before examining specific assessment techniques, it is necessary to clarify the intent of this series. The goal is to explain how different assessment methods function in OT, the decision-making value they provide, and where they are often misapplied. Each assessment type answers a different question. Confusing those questions leads to poor scoping, unnecessary risk, and misplaced confidence. This series is structured to clearly separate those methods and evaluate them through the lens of operational safety and reliability.
Intended Audience
This series is written for:
- OT security practitioners responsible for assessment planning
- Control engineers evaluating security proposals
- Architects designing industrial security controls
- Technical leaders that are accountable for operational risk
It assumes a working familiarity with industrial control systems, networking, and basic cybersecurity concepts.
Defining the Purpose of OT Security Assessments
Before discussing individual assessment types, it is important to clarify what an OT security assessment is and is not intended to accomplish.
An effective OT security assessment should:
- Characterize risk in terms of operational impact, not just technical weakness
- Respect system constraints, including safety, availability, and vendor supportability
- Provide actionable outcomes aligned with engineering and operations realities
- Ensure that all testing remains predictable, scoped, and recoverable within established operational and safety limits.
Assessments are not exercises in proving compromise at any cost. They are decision-support mechanisms that inform architectural changes, the selection of security controls, monitoring strategy, and incident response planning.
Types of Assessments
Each assessment method contributes to these objectives in a distinct way. Let’s dive into the different types, their purpose, and the methods that can be used to perform each of them.
Vulnerability Assessments in OT
Vulnerability assessments are often the most misunderstood element of OT security programs.
In IT, vulnerability assessments are often synonymous with authenticated or unauthenticated scanning, followed by Common Vulnerability and Exposures (CVE) enumeration and patch prioritization. In OT, this model is incomplete at best and misleading at worst.
OT vulnerability assessments must account for:
- Operational constraints that prevent patching or configuration changes
- Device-specific weaknesses and contextual exposure factors that affect exploitability (e.g., protocol exposure, network segmentation, physical access constraints)
- Compensating controls such as network zoning, access restrictions, and process safeguards
A technically sound OT vulnerability assessment focuses less on raw vulnerability counts and more on exposure conditions. The presence of a vulnerability does not inherently imply risk; risk arises from the intersection of vulnerability, access, threat capability, and process impact.
Within this series we will examine how to conduct vulnerability assessments that prioritize accuracy, system stability, and operational relevance.
Threat Modeling for Industrial Systems
Threat modeling is often underutilized in OT security programs, even though it is one of the most effective tools for prioritizing defensive investment.
Unlike vulnerability assessments, which start with identifying weaknesses, threat modeling starts by examining system functions and process impacts. It asks:
- What is the system designed to do?
- What happens if it behaves incorrectly, unexpectedly, or not at all?
- Who would benefit from inducing those conditions?
- What capabilities would be required to achieve them?
In OT environments, threat modeling must consider:
- Process dependencies and failure propagation
- Safety instrumented functions and interlocks
- Control hierarchies and trust boundaries
- Engineering workflows and maintenance access paths
Threat modeling shifts the conversation from “What vulnerabilities exist?” to “Which attack paths matter?” and makes a critical distinction when mitigation resources are limited.
Penetration Testing in OT Environments
Penetration testing occupies a complex role in OT security. It is one form of adversarial testing, intentionally attempting to exploit weaknesses to validate whether they can be abused under real-world conditions. Some argue that penetration testing should never be performed against live industrial systems. However, when properly designed and governed, it can provide meaningful validation that other assessment methods cannot.
A penetration test provides empirical validation of whether specific vulnerabilities can be exploited under real-world conditions. But it also introduces operational risk by intentionally attempting to manipulate or disrupt systems.
In OT, penetration testing must be:
- Tightly scoped
- Explicitly approved by asset owners and operations leadership
- Designed to avoid unsafe or irreversible actions
- Conducted with clear abort conditions and monitoring
Unlike many IT environments, OT systems cannot tolerate disruption during validation. In industrial contexts, the success of penetration testing is not defined solely by technical compromise. An exploit that causes controller faults, process trips, or operational instability may indicate that the test exceeded acceptable risk boundaries rather than that security was effectively assessed.
This series will address where penetration testing provides meaningful value in OT, how to scope it responsibly, and why it should never be treated as a default assessment.
Red Teaming in Industrial Contexts
Red teaming is the most comprehensive form of adversarial testing in OT environments. While penetration testing focuses on validating specific weaknesses, red teaming evaluates whether coordinated adversary behavior can achieve defined operational objectives across systems, people, and processes.
In OT environments, those objectives are rarely data centric. Instead, they may include:
- Sustained process disruption
- Loss of operator visibility
- Manipulation of control logic
- Interference with safety systems
True OT red teaming requires deep domain expertise, careful coordination, and a mature organizational risk posture. As a result, it is relatively rare and often misunderstood.
Many engagements labeled as “OT red teaming” are, in practice, aggressive network or application penetration tests that lack meaningful process interaction.
This series will differentiate between authentic OT red team exercises and rebranded IT testing and discuss when these activities are appropriate within an OT security lifecycle.
Purple Teaming and Defensive Validation
Purple teaming emphasizes collaboration between offensive testing activities and defensive operations. In OT environments, this approach is often more valuable than adversarial testing alone.
Purple teaming focuses on questions such as:
- Can we detect anomalous control behavior?
- Do alerts provide sufficient context for operators and responders?
- Are response actions safe, effective, and well understood?
- Do security tools integrate with engineering workflows?
In OT environments, incident response prioritizes stabilizing the physical process before eradicating the threat. As a result, validating detection accuracy and response safety is essential to ensure that defensive actions do not introduce additional operational risk.
This series will examine how purple teaming can be applied in industrial environments to improve monitoring fidelity, response coordination, and operational confidence without unnecessarily increasing risk.
Establishing and Scoping Assessment Guardrails
Across all assessment types, certain principles must guide execution in OT environments:
- Change control applies to security testing
- Safety systems are not test targets without explicit justification
- Testing should be observable, reversible, and documented
- Engineering authority must be respected
Assessments that violate these principles undermine trust and often lead to long-term resistance to security initiatives.
Alignment with Standards and Frameworks
This series will reference established standards and guidance where appropriate, including:
- IEC 62443 (particularly risk assessment and security level determination)
- NIST SP 800-82
- MITRE ATT&CK for ICS
- Industry-specific safety and reliability practices
However, threat and vulnerability assessments should never be a compliance checklist. Standards provide structure, but effective OT security requires interpretation and adaptation.
Structure of the Series
The following posts will address each assessment type in depth:
- Post 2: Vulnerability Assessments in OT: Scope, Limitations, and Practical Application
- Post 3: Threat Modeling Industrial Systems: From Process Understanding to Attack Path Analysis
- Post 4: Penetration Testing in OT Environments: Validation Without Disruption
- Post 5: Red Teaming in OT: Objectives, Constraints, and Realistic Expectations
- Post 6: Purple Teaming for Industrial Defense: Improving Detection and Response
Each post will focus on technical detail, operational impact, and decision-making relevance.
Conclusion
Threat and vulnerability assessments are not interchangeable. Each serves a specific purpose within an OT security program, and misuse can introduce risk rather than reduce it.
As OT environments continue to converge with enterprise systems and external connectivity grows, the need for precise, context-aware assessment methods becomes increasingly critical.
OT security assessments are most effective when part of a structured lifecycle. Vulnerability assessments identify technical weaknesses, while threat modeling determines which of those weaknesses are relevant to the physical process. Penetration testing verifies if those weaknesses can be exploited. Red teaming simulates attacker actions to assess if operational goals can be achieved. Lastly, purple teaming ensures that any unusual activity is detected and managed properly. Each method answers a different question. Together, they provide a layered understanding of risk.
This series aims to provide the technical clarity needed to choose the right tool for the right problem and to apply it effectively to strengthen industrial operations.
At Enaxy, we help organizations conduct both threat assessments and vulnerability assessments in OT environments with the operational context they require. Our team works alongside engineering, operations, and security stakeholders to identify real risks, validate findings safely, and ensure assessments improve resilience rather than disrupt production.
If you need support planning or executing OT threat and vulnerability assessments, contact Enaxy at info@enaxy.com.
In the next post, we will start with vulnerability assessments and explore why accuracy and context matter more than scan results.