Why CVSS Scores Fail the Factory Floor: A New…

An OT security practitioner has introduced a five-step framework to evaluate the actual exploitability of vulnerabilities in manufacturing environments, where immediate patching is often impossible.

Why CVSS Scores Fail the Factory Floor: A New Framework for OT Vulnerability Management

On June 4, 2026, an OT security practitioner published an operational framework on Help Net Security designed to manage vulnerabilities in manufacturing environments. The author argues that relying solely on CVSS scores triggers unjustified alarms and distorts resource allocation. The proposal addresses a concrete industrial reality: operational availability takes precedence over confidentiality and integrity, and patching cycles cannot mirror the pace of enterprise IT.

Key Takeaways

A five-step framework—inventory, vulnerable function verification, existing mitigations, exploitation path, and remediation—evaluates actual exploitability in OT environments.
Vulnerability scanners frequently rely on self-reported software versions, generating false positives that do not reflect real system exposure.
Network segmentation (DMZs, firewall ACLs, jump servers) reduces the exploitability of even high-CVSS vulnerabilities, yet automated reports fail to account for these mitigations.
OT risk acceptance requires a formal, documented process with compensating controls and fixed re-evaluation dates as an alternative to immediate patching.

Why a CVSS 10 Isn't Always a CVSS 10

CVSS scores measure the intrinsic severity of a vulnerability, not the risk to a specific organization. In a standard IT environment, a CVSS 10 on the WAN demands urgent patching. On the factory floor, that same vulnerability might reside on a PLC behind three layers of segmentation, with no external network route and controlled physical access. The difference is structural, not nominal.

The source cites CVE-2025-27495, with a CVSS of 9.8, as a prime example: port 8000 is open by default, allowing unauthenticated exploitation via the internet. In this specific case, the attack path is simple, and the score reflects the operational risk. However, the same nominal severity on a different asset with a segmented topology and active ACLs describes a radically different scenario. The practitioner notes that scanning tools fail to distinguish between these contexts, assigning the same priority to both tickets.

The Five Steps of the Proposed Framework

The framework establishes a decision-making sequence that precedes any remediation. The first step is an accurate inventory: listing assets while verifying their operational function, role in the production process, and criticality for continuity. The second step verifies whether the vulnerable function is actually active in the target system; a library that is present but never invoked, a disabled service, or an unimplemented feature renders the vulnerability technically irrelevant.

The third step maps existing mitigations: NAT, segmented VLANs, stateful firewalls, DMZs for exposed services, and jump servers for administrative access. The fourth step traces the complete exploitation path from the potential entry point to the target asset, verifying if every hop is traversable in practice. The fifth step addresses remediation, which in OT often involves compensating controls and formal risk acceptance rather than patching.

"In a normal IT environment, you patch it then close the ticket and call it a day. If, however, you're in OT or dealing with ICS in a live manufacturing facility, it's rarely that simple."

The Software Version False Positive Problem

A primary cause of distortion in OT vulnerability reports is the reliance on self-reported versions. Scanners identify the version number declared by an application and compare it against known CVE databases without verifying if the vulnerable code is actually present or if the build includes a backported patch. The practitioner cites a case involving seven different Adobe versions, all flagged as vulnerable, resulting in manual verification overhead that revealed no real exposure.

The source describes the mechanism: "We have not tested for these issues but instead relied only on the application's self-reported version number." This methodological limitation, while known in IT, is critical in OT. Every alert requires coordination with process engineering, downtime planning, and vendor validation of firmware compatibility. A false positive is more than an inefficiency; it is an operational risk that consumes limited maintenance windows on non-existent problems.

Documenting Risk Acceptance as a Control

When patching is impractical—due to continuous production constraints, lack of vendor patches, or functional regression risks—the framework treats risk acceptance as a structured path rather than an informal waiver. The source specifies requirements: a written record of the accepted risk, active compensating controls, and a strict re-evaluation date. This formalization serves a dual purpose: operational traceability and legal defense for management during audits or incidents.

The practitioner emphasizes the value of technical language in executive communication. Translating a "CVSS 10" into "exploitability conditioned by X controls, with impact mitigated to Y, requiring investment Z for scheduled remediation" distinguishes a reactive security function from true risk management. The source concludes: "A CVSS 10 buried three networks deep behind two firewalls with proper ACLs in place is completely different than a CVSS 10 on a flat network accessible by anyone on the internet and a default password."

Analysis and Limitations

The dossier does not specify the author's institutional identity or provide quantitative data on the problem's prevalence, such as false positive percentages, average OT remediation times, or framework adoption rates. It remains unclear if the method is original or derived from existing standards like NIST SP 800-82 or IEC 62443. Empirical validation is absent; there are no documented use cases, peer reviews, or measurements of effectiveness compared to traditional prioritization processes.

Furthermore, the source does not indicate the current status of CVE-2025-27495—whether it is patched, widespread in industrial environments, or relevant in 2026. The reference is illustrative rather than analytical. Unit 42 sources included in the dossier do not corroborate the proposed framework; they cover Linux vulnerabilities, macOS malware, the 2026 World Cup attack surface, and cloud identity tools, none of which directly intersect with manufacturing OT vulnerability management.

The contribution's value lies in providing operational language for a recognized problem: the gap between IT-centric security metrics and environments where stopping a production line costs millions per hour. For CISOs and manufacturing security leads, the framework provides a structure for internal discussions that might otherwise devolve into irrational pressure for immediate patching or dangerous stagnation.

Information is based on the cited source and is current at the time of publication.

Sources

Sources and references