When a vulnerability is disclosed in a Programmable Logic Controller (PLC) or Distributed Control System (DCS), the immediate reaction in many industrial operations is to open a ticket with the vendor support line. The standard IT playbook dictates: patch, reboot, verify, and close. But in Operational Technology (OT), that playbook often burns. You are dealing with legacy hardware, proprietary protocols like Modbus or DNP3, and safety-critical processes where an unplanned reboot can cost millions in lost production or trigger a physical hazard.
So what happens when the vendor says, “No patch available”? Or worse, “Patch unavailable for this firmware version due to compatibility concerns”? This is the silent crisis of OT cybersecurity. You are left with a known critical flaw and no technical fix. If you do nothing, you are exposed. If you over-engineer a fix, you risk operational stability.
At Red Trident, we have seen this dilemma repeatedly during our engagements. The challenge is not just identifying the vulnerability; it is determining how to score its risk when the traditional remediation path is blocked. We need a method to prioritize these “unpatchable” risks so you can allocate resources effectively without waiting for a miracle update from Rockwell, Siemens, or Schneider Electric.
The Failure of IT Risk Models in OT Environments
Most organizations default to CVSS (Common Vulnerability Scoring System) when assessing new threats. A CVSS score of 9.8 screams “critical.” It demands immediate attention. But CVSS is designed for confidentiality, integrity, and availability in IT contexts. In OT, the stakes are physical safety, environmental impact, and continuous production.
Consider a vulnerability that allows remote code execution on an HMI workstation. In IT, this is critical because it compromises data. In OT, if that HMI is air-gapped from the control network and only accessible via a secured jump box in the DMZ, its exploitability is low. Conversely, a minor configuration flaw on a field-level sensor that feeds into a pressure relief loop might have a CVSS of 5.0 (medium), but its operational impact could be catastrophic.
We cannot score these risks using a static number derived from a database. We must contextualize the vulnerability within the specific architecture of your facility. This requires moving beyond the CVSS base score to an Exploitability Subscore that accounts for the physical reality of your plant floor.
Assessing Attack Pathways: The “How” Matters More Than the “What
When a vulnerability exists, you must determine how an attacker could actually reach it. In many cases, the vulnerability is real, but the attack vector is blocked by physical or logical barriers. However, these barriers are often assumed rather than verified.
In one recent assessment we conducted, we found that while a specific PLC firmware had a known remote execution flaw, the device was located in a substation that required authentication to access. The initial risk seemed low. However, our network assessment revealed that the authentication credentials were shared across multiple contractors and had not been changed in three years. Furthermore, the network segmentation between the control zone and the corporate zone was weak, relying on a single firewall rule that permitted broad Modbus TCP access.
This is why we emphasize that network assessment and foundational reconfiguration are prerequisites to any remediation strategy. You cannot score a vulnerability in isolation. You must map the attack path:
- Physical Access: Can an attacker plug into the serial port or USB interface of the device?
- Network Reachability: Is the device on a segment accessible from the internet or the corporate LAN without traversing a secure boundary?
- Protocol Exposure: Does the vulnerability rely on a specific protocol command (e.g., OPC UA method call) that is currently blocked by a protocol-aware firewall?
If the answer to network reachability is “no,” your scoring drops significantly. If the answer is “yes, but it requires insider knowledge,” you shift from an external threat model to an insider threat model, which changes your mitigation strategy entirely.
Compensating Controls: The Only Real Remedy
When patching is off the table, compensating controls become your primary line of defense. These are not just “best practices”; they are mandatory mitigations that must be implemented to bring risk to an acceptable level. We categorize these into three tiers: Detection, Containment, and Restriction.
Detection and Monitoring
The first step is knowing when someone is trying to exploit the vulnerability. Since you cannot stop the exploit technically at the device level, you must detect it at the network level. This requires passive monitoring of OT traffic. Look for anomalous behavior specific to the protocol.
For example, if the vulnerability involves a specific function code in Modbus TCP, deploy network intrusion detection systems (NIDS) that are aware of Modbus semantics. Alert on any request from an unauthorized IP address to that specific function code. This does not stop the attack, but it provides the visibility needed for incident response. In our engagements, we often find that plants have monitoring in place, but it is tied to business objectives rather than security events. Ensure your monitoring rules are explicitly mapped to known vulnerability indicators of compromise (IOCs).
Containment via Segmentation
If the vulnerability cannot be patched, you must restrict its blast radius. This is where the concept of security zones and conduits becomes critical. Ensure that the device with the vulnerability is placed in a high-assurance zone. Access to this zone should be strictly controlled via firewalls or unidirectional gateways.
We have seen cases where operators attempted to segment devices by VLAN alone. This is insufficient if the core switch is compromised or misconfigured. You need Layer 3 boundaries with explicit allow-listing of only the required ports and protocols. For instance, if a PLC only needs to send data to a historian, it should never be able to initiate connections back to the control network.
Restriction of Remote Access
Vendors often require remote access for updates or troubleshooting. This is a major risk vector for unpatched vulnerabilities. If you must allow remote access, it must be done through a secure bastion host with multi-factor authentication (MFA) and session recording. Never allow direct VPN connections to the OT network from corporate endpoints. The jump box model is not just a recommendation; it is a requirement for securing legacy assets.
Prioritizing the Unpatchable: A Decision Matrix
With limited resources, you cannot mitigate every unpatched vulnerability with equal intensity. You need a framework to prioritize your efforts. We recommend a simple scoring matrix based on three factors:
- Operational Impact: What happens if the device is compromised? (Safety, Production, Quality)
- Exploitability: How difficult is it for an attacker to reach the device?
- Value of Asset: Is this a critical path asset or a redundant backup?
For assets with high operational impact and high exploitability, you must implement all compensating controls immediately. For assets with low operational impact but high exploitability (e.g., a testing environment connected to the production network), you might focus on strict network isolation rather than heavy monitoring.
This approach aligns with NIST SP 800-82 guidelines, which emphasize that risk management in OT must be driven by safety and security outcomes, not just technical compliance. It also mirrors the findings from our own assessments, where we often see that plants have identified thousands of vulnerabilities but lack a clear roadmap for remediation based on business context.
Building the Roadmap from Gap Analysis to Action
The gap between “we know we are vulnerable” and “we have fixed the risk” is where many OT programs stall. To move forward, you must treat unpatched vulnerabilities as a continuous lifecycle, not a one-time fix.
First, maintain an accurate asset inventory. You cannot protect what you do not know exists. In our walkdowns, we frequently find “shadow assets”—devices that were commissioned years ago but have never been documented in the CMMS or network management system.
Second, engage with your vendors proactively. Ask for security advisories and request written confirmation of patch availability timelines. If a vendor confirms no patch will be available for five years, you must plan for that long-term horizon.
Third, implement compensating controls in phases. Start with the highest-risk assets. Use network segmentation to isolate them. Enhance monitoring to detect exploitation attempts. Finally, review these controls annually as your threat landscape evolves.
The reality of OT cybersecurity is that perfection is impossible. Legacy devices will remain in use for decades. The goal is not to eliminate all vulnerabilities but to manage the risk to an acceptable level through robust compensating controls and continuous monitoring. By focusing on attack pathways and operational impact, you can prioritize effectively and protect your facility from the most dangerous threats.
Take Control of Your OT Security Posture
If you are struggling to prioritize unpatched vulnerabilities or need help developing a practical remediation roadmap, Red Trident is here to assist. We specialize in OT/ICS cybersecurity assessments that go beyond checklists to provide actionable insights tailored to your operational reality.
Contact us today to schedule a free consultation on how we can help you secure your industrial infrastructure.
