The most dangerous vulnerability is not always the newest one

A manufacturer can have thousands of known vulnerabilities and still be looking in the wrong direction. The highest technical severity score may sit on an isolated device with little operational importance, while a less dramatic weakness on an engineering workstation, remote-access gateway or production-critical controller creates the more credible path to disruption.

That is the problem with treating industrial cybersecurity as an exercise in eliminating vulnerabilities. In most plants, the job can never be completed. Equipment remains in service for decades, maintenance windows are scarce, some systems are no longer supported and taking a controller offline can carry a greater immediate production risk than leaving it running. The more useful question is not which vulnerability looks worst on paper, but which exposure could stop production, affect safety or give an attacker a practical route deeper into the plant.

The first problem is knowing what is there

Manufacturers cannot prioritize exposure if they do not have an accurate picture of the environment. That sounds elementary, but industrial networks accumulate equipment differently from enterprise IT. Controls are added during projects, suppliers install remote-access tools, machines arrive with embedded computers, and production teams make pragmatic changes to keep equipment running.

Andrea Carcano, co-founder and CEO of Nozomi Networks, points to a building materials manufacturer that believed one section of its plant contained around 3,000 connected assets. Automated discovery found more than 15,000. Nothing had suddenly joined the network. The manufacturer had simply gained visibility of equipment that was already present.

“Companies usually approach us because they have zero visibility or very limited visibility of what they have in the network,” Carcano says. “Installing this kind of technology is like turning on the lights in a dark room. Suddenly you start to see things you did not expect. Once the light is on, you then have a journey to fix what you discover, and depending on the findings that journey can take years.”

An inventory alone is not enough. Security teams need to understand device type, firmware, communication paths and what each asset does for production. An old controller on a non-critical auxiliary system and an identical controller running a bottleneck process may have the same vulnerability, but the operational consequence of compromise is completely different.

Carcano compares that progression with securing a building. Knowing the number of doors and windows is useful, but protection depends on understanding what kind of doors they are, how old they are and what they protect. In the factory, the equivalent is knowing the equipment, firmware, expected behavior and the vulnerabilities associated with it.

Severity is only one part of the decision

Traditional vulnerability management tends to begin with a technical score. Nick Haan, Field CTO at Claroty, argues that manufacturers need a broader view because static severity cannot describe whether an attacker can realistically reach the asset or what would happen if they did.

CVSS, the Common Vulnerability Scoring System, assigns a numerical severity score to a vulnerability based on its technical characteristics. It is useful for comparing weaknesses, but it does not by itself show how exposed a particular manufacturing asset is or what the operational consequence of compromise would be. “It is very important not to rely on CVSS scoring to decide what you patch because CVSS scoring is very static,” Haan says. “You need to ask whether there is an exploit available, whether that exploit is being used in the wild, whether the device is connected to a network that can be infected and whether it actually impacts your environment.”

The next step is to stop evaluating equipment in isolation. A PLC is part of a production line, and the line itself has dependencies, safety functions and business consequences. Haan argues that manufacturers should combine exploitability with asset purpose and look at the exposure of the complete production process rather than simply rank individual devices.

This changes the order of work. A technically critical vulnerability on a segmented asset with no practical attack path may justify monitoring and scheduled remediation. A lower-scoring weakness on a device reachable through uncontrolled remote access, connected to a critical line and capable of affecting production may need immediate attention. The priority becomes reducing exposure rather than chasing the largest number in a vulnerability report.

AI is shrinking the time available

Prioritization is becoming more urgent because the period between vulnerability discovery and practical exploitation is contracting. Rich Campagna, Senior Vice President of Product Management for Network Security at Palo Alto Networks, says newer AI models are increasingly capable of identifying previously unknown weaknesses and producing exploit code for them.

“The biggest thing that is changing is not only that we are finding more weaknesses in systems, but attackers can almost instantaneously have ways to exploit those weaknesses,” he says. “These models have become very good at finding vulnerabilities that no human or pre-existing tool has thought to look for, and they are also very good at generating exploit code.”

That creates a particularly awkward problem for manufacturing. Campagna says the industry previously had cases where exploit code appeared months after a vulnerability was disclosed, if it appeared at all. That window could give organizations time to assess exposure and schedule remediation. He now sees that interval collapsing toward minutes, while an OT asset may still require weeks or months before a safe maintenance window becomes available.

The answer cannot simply be to patch faster. A production system that cannot be stopped tomorrow will not suddenly become patchable because an attacker has become faster. Manufacturers need controls that reduce the attacker’s opportunity during the period between discovery and permanent remediation.

When patching is impossible, reduce the path to the asset

Haan describes environments where downtime is not merely inconvenient. In an aluminum smelter, for example, stopping the process can create severe physical consequences, while other plants may run equipment designed decades ago with no modern redundancy and only infrequent shutdown windows.

“Updating a PLC means downtime,” Haan says. “Some producers may only have a downtime once every two, three or four years and do the updates then. In between, they cannot do updates. That means you need other ways to protect those devices.”

Those alternatives include segmentation, tightly controlled communication between functional zones, secure remote access, continuous monitoring and virtual patching. The principle is to make a vulnerable asset harder to reach and easier to monitor even when the underlying weakness remains.

Where the weakness cannot be removed, the priority shifts to making exploitation harder and abnormal behavior easier to detect. “If a device has old firmware that cannot be patched, knowing the vulnerability still gives you another control,” Carcano says. “If somebody starts doing exactly what is required to exploit that vulnerability, you can identify it and react. You may not be able to remove the vulnerability from the device, but you can monitor for the behavior that would indicate somebody is trying to use it.”

Campagna describes virtual patching as another way to buy operationally useful time. A network security control positioned in front of the vulnerable system can identify and block an exploitation attempt before it reaches the asset, allowing the manufacturer to defer the physical patch until a maintenance window is available.

“You are not going to take a system down for an hour or two in the middle of a manufacturing cycle,” he says. “But you can apply a virtual patch in the network with no downtime to protect against that vulnerability until later, when you can actually patch the system.”

The plant should fix what can hurt it first

None of this removes the need for patching. Unsupported systems still create technical debt, aging equipment eventually needs replacing and known vulnerabilities should not be allowed to accumulate indefinitely. The change is in how manufacturers decide what happens first.

A practical OT risk register should combine asset identity, operational criticality, connectivity, known vulnerabilities, exploit availability, remote-access paths and the consequence of compromise. From there, teams can distinguish between vulnerabilities that need immediate intervention, those that require compensating controls and those that can be accepted temporarily because the operational exposure is limited.

That also makes cybersecurity a joint decision between security specialists and the people who understand production. The security team may know an exploit exists; engineering knows whether isolating the device will stop a line, disable a safety function or interrupt a process that cannot easily be restarted.

Industrial cybersecurity therefore becomes less about achieving a theoretically clean vulnerability count and more about continually narrowing the attack paths that matter. In a plant full of old equipment and imperfect choices, the most dangerous vulnerability is not necessarily the newest, the most publicized or the one with the highest score. It is the one an attacker can reach on an asset the factory cannot afford to lose.