How to Recalculate CVSS Scores in an OT Context

How to Recalculate CVSS Scores in an OT Context 

Author: Roger Hill

In the IT world, a critical vulnerability with a CVSS score of 9.8 triggers alarms, tickets, executive notifications, and a countdown to remediation. That number carries urgency. It drives board-level discussions, internal SLAs, and compliance audits. But in OT, that same 9.8 might be functionally irrelevant—or, at the very least, deeply misleading. 

The Common Vulnerability Scoring System (CVSS) has become the de facto standard for evaluating software vulnerabilities, and for good reason. It offers a consistent, structured way to assess technical severity. However, its original design never accounted for the unique constraints, architectures, and business dependencies that define operational technology environments. 

If you’re leading cybersecurity for a power utility, a food manufacturing plant, or a pharmaceutical operation, you’ve likely encountered this disconnect. A centralized scanner flags dozens of critical devices. Security leadership wants a resolution. But your plant floor teams are quick to point out that many of those devices aren’t exposed, accessible, or, in some cases, even patchable. 

So where does that leave us? CVSS is not wrong—it’s just incomplete. If you’re going to use it in OT, you need to recalibrate it through the lens of context, compensating controls, and business impact. 

Why Raw CVSS Doesn’t Work in OT 

Let’s be clear: CVSS Base Scores were never designed to capture the realities of physical operations. They focus on inherent exploitability—network access, required privileges, user interaction—and potential technical impacts like confidentiality, integrity, and availability. 

However, in OT, exploitability is often contained by design. Assets are physically separated, network traffic is tightly scoped, and changes require specialized access. You can have a critical vulnerability on a PLC, but if that device sits behind two layers of segmentation, requires proprietary software to interact with, and has no internet exposure, the real-world risk is nowhere near the base score. 

Conversely, a low-severity vulnerability on a misconfigured historian server with persistent access to Level 2 networks might present far more risk than its CVSS number suggests. This inversion is common and dangerous if misunderstood. 

The Missing Variable: Environment 

CVSS includes an “Environmental Score” component, but few organizations use it. In OT, this piece becomes essential. It’s where we introduce the true variables of risk: 

• Network segmentation and firewall rules 

• Physical access controls 

• Device role and functional criticality 

• Dependency mapping (what breaks if this breaks?) 

• Monitoring and detection coverage 

Applying the environmental score means asking the right questions: 

• Can this vulnerability be exploited remotely? 

• Is it accessible from any unmanaged asset? 

• Does it control or influence a safety function? 

• How often is the device used, updated, or accessed? 

When you apply this context, CVSS 9.8 might drop to a real-world risk score of 4.2. Or it might stay high. But at least you’re seeing the truth, not just the math. 

A Practical Example 

Take a Level 1 device—a servo controller in a packaging line. The scanner reports a CVSS 10 vulnerability related to remote code execution. Sounds dire. But let’s dig deeper. 

• The device communicates via a proprietary protocol that is not routable beyond the cabinet. 

• It sits behind an unmanaged switch, meaning no external visibility unless intercepted through an engineering workstation. 

• The production line is segmented from the corporate network with a firewall and dual NIC jump host architecture. 

• The vulnerability requires a specific firmware version that this device doesn’t run. 

When you factor all this in, the real-world risk is negligible. Yet the vulnerability still triggers a critical alert in a dashboard. If your program is driven solely by base CVSS scores, you’ll waste time, budget, and credibility chasing ghosts. 

Creating Your OT Risk Lens 

It’s time to stop accepting raw CVSS scores as gospel. Instead, use them as inputs—starting points for a more mature, OT-aware evaluation process. 

Here’s a simplified structure I often recommend: 

1. Start with CVSS Base Score – It provides a standardized measure of inherent technical severity. 

2. Apply Asset Role Weighting – Is the asset a PLC controlling critical batch processes or a maintenance laptop? 

3. Assess Network Context – Is the asset routable from business networks, remote access systems, or the cloud? 

4. Evaluate Compensating Controls – Are there isolation measures, jump hosts, NAC policies, or read-only access enforcement? 

5. Account for Business Process Impact—If the asset goes down, what will be the operational cost, compliance exposure, or safety risk? 

The output is a context-calibrated risk score—call it “OTCVSS” if you like. What matters is that your prioritization is rooted in reality, not in theory. 

Why This Matters for Leadership 

CISOs and CIOs must be able to explain to the board why a flood of critical vulnerabilities doesn’t automatically equate to a crisis. Without that translation, security teams look like they’re asleep at the wheel—or worse, ignoring real threats. 

When you build a context-aware scoring model, you create alignment. You can show why one site’s 30 unpatched criticals are lower risk than another site’s 3 that reside on high-impact assets with exposed interfaces. You shift the narrative from “Why haven’t you patched this” to “How are we reducing risk in the smartest way possible.” 

This approach also builds credibility with plant leadership. Instead of bringing them problems, you’re showing them a path forward—one that respects production constraints and regulatory realities. 

CVSS Isn’t Going Away—But It Must Evolve 

We’re not advocating for the abandonment of CVSS. It’s valuable. But in OT, it must evolve. And that evolution starts with you. 

If you’re leading vulnerability management for industrial environments, your responsibility is not just to identify issues—it’s to interpret them accurately and prioritize response based on real operational impact. 

That means pulling in context from engineering, operations, and compliance. It means looking past the red flags on dashboards and asking: What’s the actual exposure? What does this asset do? Who can touch it? What happens if it fails? 

These questions aren’t outside the scope of cybersecurity—they are cybersecurity in OT. 

Next week, we’ll take this further by introducing the RISE Model—a practical framework for prioritizing OT vulnerabilities based on Risk, Impact, Scoring Improvement, and Effort. Once you understand your risk, the next challenge is knowing where to act. 

Visit Author’s LinkedIn: https://www.linkedin.com/in/rogerlhill/