For decades, the Common Vulnerability Scoring System (CVSS) has been the lingua franca of information security. It provides a standardized way to quantify the severity of a vulnerability based on technical characteristics like exploit complexity, confidentiality impact, and availability requirements. In a pure IT environment, this metric is invaluable. A Critical score of 9.8 immediately signals that an organization must drop everything and patch.
However, in Operational Technology (OT) and Industrial Control Systems (ICS), CVSS is not just imperfect; it is actively misleading. When plant managers, OT engineers, and CISOs rely on raw CVSS scores to prioritize remediation, they are often optimizing for the wrong outcomes. They may be patching a low-risk server while leaving a high-risk Programmable Logic Controller (PLC) exposed, or halting production for a vulnerability that has no practical attack vector in their specific architecture.
The core problem is not that CVSS is bad technology. The problem is that it measures the potential for technical impact, while OT security is entirely about operational impact. To secure critical infrastructure effectively, we must move beyond generic scoring and embrace context-aware risk assessment methodologies.
The Fundamental Mismatch: Confidentiality vs. Availability
CVSS v3.1 and v4.0 include three base metric groups: Confidentiality, Integrity, and Availability (CIA). In IT, confidentiality is often the primary concern. A leaked database can result in financial loss or reputational damage. However, in OT environments, the priority triad shifts dramatically.
In an ICS environment, Availability and Safety are almost always paramount. Consider a vulnerability in a Rockwell Automation or Siemens controller that allows for remote code execution. CVSS might assign this a Critical 9.8 because it bypasses authentication entirely. But if that controller is on an air-gapped segment, communicating only via Modbus TCP to a specific HMI, and the vendor has explicitly stated that the vulnerability requires physical access to the programming port, the technical severity does not match the operational risk.
Conversely, a vulnerability in a widely used OPC UA server might receive a Moderate 5.5 score because it only allows information disclosure. If that server is directly connected to cloud-based predictive maintenance platforms and lacks micro-segmentation, the confidentiality breach could lead to industrial espionage or supply chain compromise. Here, the CVSS underestimates the risk.
When we ignore this nuance, we create a prioritization paradox. We rush to patch high-CVSS items that are technically unexploitable in our context, while ignoring moderate-CVSS items that are critical to our business continuity and physical safety.
The Hidden Variable: Operational Context
Context is the missing variable in standard CVSS scoring. In OT, a vulnerability’s exploitability is dictated by factors that CVSS simply cannot see:
- Protocol Specificity: Does the vulnerability require a specific industrial protocol handshake? Is the device capable of processing malicious packets, or will it silently drop them?
- Network Architecture: Is the asset in a DMZ? Is it behind a firewall? Is there a data diode preventing inbound traffic?
- Legacy Constraints: Can the asset even be patched? Many IEC 62443-compliant environments contain legacy systems where patching is prohibited due to vendor support contracts or stability risks.
- Safety Impact: Does exploiting this vulnerability risk a process excursion, equipment damage, or personnel injury?
Red Trident’s internal assessments consistently reveal that operators lack a clear, evidence-based view of these contextual factors. Without understanding the specific interaction between a vulnerability and the operational environment, any score is just a number.
Learning from Engagement Data: The Reality of Endpoint Risk
To understand why context matters, we must look at real-world findings. Generic scoring often fails to capture the severity of configuration errors that enable lateral movement within an OT network. In our recent engagements, we have seen specific recurring patterns that highlight this gap.
For instance, in 2 of 2 endpoint assessments from the same industrial organization, the PowerShell process execution policy was reported as Bypass, while PowerShell Transcription and Module Logging were both reported as not configured. In a standard IT CVSS model, a configuration issue might be scored based on local impact. However, in an OT environment where engineers use these endpoints for engineering workstation tasks, this configuration allows for unmonitored script execution that can easily facilitate the deployment of malware or ransomware.
This finding was not about a CVE with a 9.8 score. It was about a configuration state that completely nullified detection capabilities. If we had relied solely on CVSS for known vulnerabilities, we might have missed this critical risk entirely. The absence of logging is the vulnerability; the lack of context-aware monitoring is the failure.
Building a Context-Aware Scoring Model
So, how do we fix this? We cannot abandon CVSS entirely—it provides a useful baseline for technical severity. Instead, we must layer contextual modifiers on top of it. This approach aligns with the principles outlined in NIST SP 800-82 and IEC 62443, which emphasize risk management over mere compliance.
Step 1: Asset Criticality Mapping
Before scoring a vulnerability, you must score the asset. Not all assets are equal. A valve controller in a water treatment plant has a different risk profile than a HVAC server in an office building. Use a framework like CVRA (Cyber Vulnerability Risk Assessment) to assign a criticality score based on:
- Safety Impact: Potential for injury or loss of life.
- Production Impact: Cost per minute of downtime.
- Environmental Impact: Risk of spills, emissions, or regulatory fines.
Step 2: Exploitability Assessment
Modify the CVSS base score based on your specific network architecture. Apply a “reachability modifier.” If an asset is behind multiple layers of segmentation and requires physical access, the effective exploitability score drops significantly. Conversely, if an asset is exposed to the internet or a poorly segmented DMZ, the score should increase.
Step 3: Operational Feasibility
Consider the cost and risk of remediation. Patching a legacy Siemens S7-300 PLC might require a shutdown lasting weeks and testing by OEM engineers. If the vulnerability is not actively exploited in the wild, the operational cost of patching may outweigh the risk. In such cases, compensating controls like enhanced monitoring or micro-segmentation are more appropriate than immediate patching.
The Role of Passive Discovery and Continuous Monitoring
Context-aware scoring is impossible without accurate asset inventory and visibility. Many operators still rely on static spreadsheets that are weeks out of date. Red Trident’s engagement findings repeatedly highlight incomplete asset inventories as a root cause of security failures.
To build an effective context model, you must start with passive discovery. Passive network analysis, configuration review, PCAPs, flow logs, and asset inventories can reveal a large amount of risk without touching fragile endpoints. Active scanning, while necessary in some cases, must be approved, rate-limited, and adapted to industrial protocols to avoid causing network congestion or device resets.
Furthermore, security roles and responsibilities must be clearly defined. Who owns the risk? Is it the IT team, the OT engineering team, or a joint committee? Without clear ownership, even the most sophisticated scoring model will fail to drive action.
Conclusion: From Technical Scores to Business Risk
The goal of OT cybersecurity is not to eliminate all vulnerabilities. That is impossible. The goal is to manage risk to an acceptable level based on business objectives. CVSS provides a technical baseline, but it cannot tell you whether a vulnerability matters to your specific plant.
By integrating context-aware scoring into your risk management framework, you align security efforts with operational reality. You prioritize remediation based on safety, production continuity, and actual exploitability rather than generic metrics. This is not just a technical adjustment; it is a strategic imperative for protecting critical infrastructure.
At Red Trident, we help industrial operators bridge the gap between IT security metrics and OT operational reality. We provide evidence-based assessments that go beyond CVSS to deliver actionable, context-aware risk insights.
Ready to move beyond generic scoring? Contact us today for a free OT security assessment consultation.
