Why does CVSS mis-rank vulnerabilities in IoT and OT environments?

Why CVSS can understate real-world IoT and OT urgency

cvss is a useful common language for severity, but it is not an environment-aware prioritisation model. In connected-device estates, the same vulnerability can produce very different operational outcomes depending on network reachability, whether the device is exposed to a routable path, and how essential that asset is to production or safety.

That is why a score alone can mislead. A device with a modest score but direct exposure and an exploitable firmware path may need action before a higher-scoring issue that sits behind segmentation, maintenance windows, or compensating controls.

For vulnerability prioritisation in operational environments, the more useful question is not “how severe is the flaw in the abstract?” but “can this flaw be reached and used here, on this asset, right now?”

Which device and network factors change the answer?

Three variables usually matter most: asset reachability, firmware state, and the path from attacker to device. Reachability determines whether exploitation is practical from the current environment. Firmware state determines whether the exposed code path actually exists on that device. The network path determines whether segmentation, jump hosts, protocol restrictions, or remote access controls reduce real exploitability.

In IoT and OT, those factors often outweigh the headline score. A device running older firmware on a flat or weakly segmented network can be far more urgent than a well-scored vulnerability on an isolated sensor that cannot be reached from an attacker-controlled foothold.

That is also why asset context matters. Operational technology and medical-device inventories are often incomplete, so the first mistake is treating every finding as equally actionable before confirming where the vulnerable instance sits and how it is connected.

What prioritisation should look like instead

Use CVSS as an input, not a decision rule. The practical sequence is to confirm exposure, confirm the running firmware or software line, then decide whether the exploit path is actually available in the production topology. In Vulnerability Management Guide, the right pattern is risk-based prioritisation, not score-only triage.

For connected devices, prioritisation should also reflect whether the vulnerability could affect safety, uptime, or process integrity if used successfully. In OT and IoMT, a reachable flaw can become operationally material even when the numerical score is not the highest item in the queue.

Where device inventory is weak, build the list from the environment outward: discover the asset, identify the firmware, check exposure, then compare that result against the score. The score should refine the order, not define it.

Risk and Threat Considerations

IoT and OT environments create a common failure mode: teams trust a severity score that does not account for reachability, segmentation, or device state. That can leave an exploitable exposed device untreated while effort goes to less reachable assets that are easier to classify on paper.

Failure mechanism: Attackers exploit the gap between abstract severity and practical accessibility, then use exposed firmware paths, weak network boundaries, or unmanaged device inventory to reach the most operationally valuable systems.

Impact: The result can be loss of availability, unsafe process behaviour, or a foothold for lateral movement into more sensitive OT or clinical environments, even when the original CVSS score did not look exceptional.

Practitioner Guidance

What to verify: Before you trust a CVSS-based queue, confirm whether the vulnerable instance is actually reachable from a realistic attacker path, whether the affected firmware is present, and whether segmentation changes the exploitability of the finding.

Decision rule: If a lower-scoring issue sits on an exposed device with an exploitable path, treat it as higher priority than a higher-scoring issue on an isolated asset. If the device cannot be reached from a credible path, the score should not drive urgency by itself.

What practitioners underestimate: OT and IoMT environments are often prioritisation problems as much as vulnerability problems. The right fix is usually a combination of exposure reduction, firmware remediation, and asset context, not a blind rush to the numerically highest CVSS item.

Practitioner takeaway: CVSS is a starting point, but in IoT and OT the environment decides urgency, so exposure and reachability must outrank score-only triage.

Related resources from NHI Mgmt Group

• How should organisations manage privileged access in IoT and ot environments?
• Why do IoT and ot environments create different security risks from standard IT systems?
• Why do traditional network controls often fail in OT and IoT environments?
• What breaks when certificate management is handled manually in IoT and OT environments?