Home / News & Updates / Redefining Vulnerability Assessment and Penetration Testing in OT Environments

The common acronym of Vulnerability Assessment & Penetration Testing (VAPT) in industrial control systems and operational technology (OT) settings can distort an important fact: VA and PT are two very different fields, both of which are necessary in the creation of cyber-resilience. In OT, whether it is the power plant and pipeline or water treatment plants, any wrong step can make operations go wrong and place safety at risk or lead to environmental hazards.

Thus, to continue operations clearly and precisely, it is vital to identify and implement these practices, rigorous Vulnerability Assessment (VA) and carefully scoped Penetration Testing (PT), in a manner that aligns with the unique operational constraints of OT environments.

This article provides an in-depth overview of both VA and PT in OT environments, as well as the practical realities of industrial systems, the rigor required in executing VA and PT safely, and the operational limitations that shape how these activities must be performed.

Setting the Context: Why OT Is Different

Operational Technology (OT) covers control systems, supervisory components, programmable logic controllers (PLCs), distributed control systems (DCS), supervisory control and data acquisition (SCADA) networks, and safety instrumented systems. These systems are the core of critical infrastructure including oil and gas, utilities, manufacturing, transport, building automation, etc., and therefore have special needs:

  • Availability first: As opposed to normal IT systems, OT assets in most cases cannot be dis-allocated over a long period without any major impact.
  • Legacy and heterogeneity: Most OT systems are running on old systems (e.g. proprietary OS, decade-old controllers) that do not have any modern security controls.
  • Physical safety implications: Failing or compromising may result in not only loss of data, but also physical damage, safety accidents and violation of regulations.
  • Network segmentation and operational constraints: OT networks are often air-gapped or heavily segmented with rigorous procedures governing change-control and little tolerance to scanning or intrusive testing.

These distinguishing factors mean that tools and tactics from the IT world must be adapted or in some cases, avoided in OT environments. Hence, simply applying a “scan-and-exploit” mindset is inadequate and potentially dangerous.

Defining the Disciplines: Vulnerability Assessment (VA) vs Penetration Testing (PT)

Vulnerability Assessment (VA)

VA is recognizing, classifying, prioritizing and preparing against known vulnerabilities in systems without necessarily trying to take advantage of them. It is focused on visibility, context, planning, and operational alignment, rather than just creating a list of CVSS scores.

In OT, a rigorous VA involves:

  • Detailed asset inventory to know what hardware, firmware, software versions are installed in the system, which hardware is connected to the network and geographical location, etc.
  • Identifying known vulnerabilities (CVE, CWE, CVSS) & mapping them to specific assets.
  • Risk assessment to identify vulnerabilities of the assets in this environment.
  • The priorities are based on the criticality of the asset, impact of the asset to the operations, exploitability, and the feasibility of its remediation.
  • Planning recovery/mitigation in a way that is consistent with operational limits.

 

Penetration Testing (PT)

PT is an active simulation of an attack, controlled, intended to exploit vulnerabilities (only when it is safe to do so) and confirm the usefulness of the existing controls. In the OT context, PT:

  • Efforts to show real attack paths (e.g. sideways movement, switching of IT to OT, privilege escalation).
  • Often is scoped on a narrow basis because of operational risk, non-critical systems only, manufacturing test benches or off-peak.
  • Gives tangible demonstrations of what an attacker might do with the vulnerabilities present in the environment.
  • Best used once the defenses have been in place, and the organization is prepared to take some action on the results.

Most notably, PT is not a replacement activity to VA, it is a supporting tool that proves the effectiveness of control, but not the primary work of the assessment and planning.

 

The Analogy: Clarifying the Sequence

To illustrate the difference and proper sequence:

  • VA is like noticing holes in an umbrella: You observe the holes, recognize the risk of getting wet, and decide whether you need a better umbrella or repair the holes.
  • PT is like throwing a rock at a glass window: You test whether the glass breaks under stress, meaning the protection failed and must be replaced, as well as decide which type of glass you need for more protection.
  • In OT: First you identify the vulnerabilities (VA), fix the weak points (controls implemented), then test whether the protection holds up. Opting for PT first without doing VA is like throwing the rock at a window knowing it is unlocked, is inefficient, risky, and may ignore the real weaknesses.

The sequence is crucial: Assessment → Remediation → Testing.

OT-Specific Challenges for VA and PT

Challenge

Implications for VA

Implications for PT

System availability constraints

VA tools must be non-intrusive or scheduled carefully to avoid downtime.

PT must avoid live systems whenever possible; scope must exclude critical assets unless downtime is scheduled.

Legacy/unpatched systems

VA must account for unsupported firmware, old protocols, and lack of vendor fixes.

PT may be limited in exploit scope or may require indirect methods; direct exploitation may be forbidden.

Network segmentation and air gaps

VA must map network reachability and segmentation controls.

PT is not restricted to upper-tier segments (e.g., DMZ, IT-OT boundary) rather than fieldbus or PLC networks.

Physical and process vulnerabilities

VA must include physical access controls, vendor remote access, USB policy, engineering workstation controls.

PT may include social engineering or physical access tests but in OT these are often heavily restricted.

Safety/regulatory risk

VA must plan around regulatory requirements, maintenance windows, and safe operations.

PT must often shift to simulation, lab-environment, or scheduled shutdowns to avoid safety risk.

In short, OT environments require risk-aware planning, coordination with operations and maintenance teams, and tailored methodologies not simply applying standard IT vulnerability scanning or penetration testing checklists.

Characterizing VA vs PT in OT Environments

Feature

VA

PT

Intrusiveness

Usually passive or minimally intrusive; focuses on asset inventory, configuration review, scanning with caution.

Intrusive by design actively exploiting vulnerabilities to prove attack vectors but in OT often restricted to non-critical domains.

Depth of scope

Broad: includes all layers (from field devices to enterprise systems), plus people, process, design.

Narrower: typically focused on specific networks/devices, often those accessible from IT networks or during project phases.

Primary objective

Build a comprehensive picture of where vulnerabilities exist and how they can be remediated.

Validate how effective the implemented controls are and demonstrate actual breach/attack capability.

Timing in cybersecurity journey

Early stage: foundational work that must occur for meaningful security improvement.

Later stage: after defense layers are implemented, to test and validate.

Frequency

Routinely scheduled (e.g., annually, bi-annually) depending on asset criticality.

Event-driven or periodic (e.g., post-major upgrade, after major remediation) due to cost, risk, and scope limitations.

Outcome

Comprehensive list of vulnerabilities (technical, process, human) with prioritization and remediation roadmap.

Demonstrated exploit path(s), proof of concept, validation of controls but not exhaustive.

Practical Steps for Rigorous Vulnerability Assessment (VA) in OT

A robust VA process in OT must be structured, repeatable, and context aware. Key steps include:

  1. Asset Inventory & Classification
    • Collect data: make, model, firmware version, network location, owner, redundancy, criticality.
    • Include operating system, software versions, installed patches for all computers.
    • Map physical and logical relationships, including vendor remote access points.
  2. Advisory Monitoring & Vulnerability Matching
    • Track vendor bulletins, advisory feeds for CWE/CVE/CVSS information.
    • Compare advisories against asset inventory to identify impacted assets.
    • Determine actual applicability (e.g., even if a CVE exists, if the asset uses a patched feature in a safe configuration, risk may be lower).
  3. Risk-Based Assessment & Prioritization
    • Combine technical severity (e.g., CVSS) with business/operational impact: how critical is the asset, what is the availability requirement, what is the potential for safety or regulatory impact?
    • Focus effort on the small subset of vulnerabilities that could halt production or cause major safety issues.
    • Document remediation options for patching, firmware upgrade, configuration change, alternative compensating controls.
  4. Remediation Planning and Execution
    • For each vulnerability, determine the need for the asset to be patched/upgraded without operational disruption and whether an alternative control is viable
    • Follow change-management processes, coordinate with operations/maintenance teams, schedule within maintenance windows.
    • Document remediation status, track closure, verify effectiveness.
  5. Continuous Monitoring and Repeat Cycles
    • Maintain visibility of new advisories and newly deployed assets.
    • Repeat the VA process regularly (or when major changes occur) to maintain resilience.

When Penetration Testing Makes Sense and its Limitations

Once a comprehensive VA has been executed and remediation is well underway, PT can be employed to validate the security posture. However, in OT contexts, the following should be considered:

  • Scope carefully: Focus on test environments, segments where downtime risk is acceptable, or simulate operations offline.
  • Define objectives: For example, “can we pivot from IT network into OT DMZ and escalate privileges to operator workstation?”
  • Manage risk: Use safe techniques to avoid live systems where unintended consequences might disrupt operations.
  • Understand what PT will (and will not) show: PT results demonstrate exploitability, but they do not guarantee the absence of other vulnerabilities. They are point-in-time snapshots, not substitutes for comprehensive VA.

In practice, many penetration testing exercises end up exposing issues, such as open ports, missing patches, and misconfigurations that a well-executed Vulnerability Assessment would have already identified. This happens because, in OT environments, penetration testers are often restricted from attempting deeper exploitation due to operational and asset-owner constraints, limiting the ability of PT to uncover anything beyond what VA should already capture.

Sequence to Operational Resilience in OT

For organizations seeking to improve OT cybersecurity resilience, the recommended sequence is:

  1. Conduct a full-scale Vulnerability Assessment: build visibility, identify vulnerabilities across technology, process, and people.
  2. Translate assessment findings into governance and risk-based controls: align with operational priorities and regulatory obligations.
  3. Implement the control measures: patching, hardening, network segmentation, access control, training, process improvements.
  4. Engage Penetration Testing: validate whether the implemented controls hold up under simulated attack conditions.
  5. Repeat the cycle: Security is not a one-time event; it’s an ongoing journey of assessment, remediation, testing, monitoring.

 

Crucially: VA is not optional and cannot be replaced by PT. Without the foundational visibility and planning provided by VA, PT may either be unsafe, ineffective or misdirected.

Final Reflections: Beyond CVSS to Real-World Operational Resilience

In OT environments, chasing CVSS scores alone is insufficient. A device may have a high severity score, but if it is isolated, redundant, and has compensating controls, the real risk may be low. Conversely, a low-score vulnerability on a mission-critical PLC may warrant immediate action.

True operational resilience emerges from context-aware vulnerability management along with the ability to identify the right vulnerabilities, prioritize them correctly, remediate them safely, and validate the controls. It’s a process that demands technical depth, operational maturity, and cross-discipline coordination (IT, OT, safety, maintenance, engineering).

For organizations responsible for critical infrastructure, the message is clear, build the foundation, align your controls with operations, and validate only when ready. The integrity of OT systems and ultimately the safety and continuity of physical operations depend on it.

If your organization is looking to strengthen its OT cybersecurity posture, now is the time to take a structured, risk-aware approach. Start by assessing where your vulnerabilities truly lie, build a remediation roadmap aligned with operational needs, and validate your resilience with controlled testing.
To learn more about how to build a tailored VA-PT strategy that supports both operational continuity and long-term resilience, visit our website to connect with our OT cybersecurity specialists.

Related Articles