Only 4% of ICS Flaws Need Urgent Patching: Rethinking PLC Security

Industrial operators are drowning in a flood of ICS vulnerabilities—yet the data suggests most of that flood is noise. A BankInfoSecurity webinar promoted on 2 October 2026, titled When a Valid Login Becomes a Security Threat, puts a hard number on the problem: only about 4% of ICS vulnerabilities across SCADA systems, programmable logic controllers (PLCs) and related industrial devices actually require immediate remediation. The rest, the session argues, are better handled through risk-based prioritization than through knee-jerk patching. For teams running lean, that distinction is not academic—it is the difference between defending a plant and merely ticking boxes.

Why Only 4% of ICS Vulnerabilities Demand Emergency Action

Not every CVE is a crisis. In IT, a vulnerability score often maps directly to a patch ticket. In OT, that logic collapses.

Patching a PLC frequently means stopping a production line, invalidating a vendor certification or forcing a maintenance window that may not exist for months. Risk-based vulnerability management—a framework now championed by bodies such as the SANS Institute and major OT security vendors—treats exploitability, asset criticality and network exposure as the deciding factors, not raw severity scores alone.

The result is a smaller, sharper list. Vulnerabilities that are actively exploited, allow remote code execution, abuse native ICS protocols or compromise remote access pathways into the OT environment rise to the top. Everything else waits in a queue.

The Risk Factors That Elevate a Vulnerability to "Fix Now"

Factor	Why It Matters in ICS/OT
Active exploitation in the wild	A confirmed attack campaign removes guesswork from prioritization.
Remote code execution	Allows an adversary to weaponize a PLC or engineering workstation.
Abuse of native ICS protocols	Blends into legitimate traffic and evades conventional detection.
Compromised remote access	Turns a single valid login into a full network foothold.
Asset criticality and safety impact	Determines whether downtime or a control failure is tolerable.

The Real Cost of Chasing Every CVE in PLC and SCADA Networks

Industrial environments rarely have an excess of cybersecurity staff. Diverting that scarce capacity toward low-risk ICS vulnerabilities produces a double penalty: wasted labour and a false sense of security.

Analysts at Claroty have warned for years that conventional CVSS-driven prioritization pushes already overburdened OT personnel to spend resources on flaws that are unlikely ever to be exploited. Meanwhile, attackers consistently target the pathways that basic hygiene would have closed.

The pressure is not theoretical. Industry surveys show that the overwhelming majority of organizations reported exposure to OT cyber incidents in the past year, and supply-chain software, aging infrastructure and patching difficulty remain the top structural risks.

Why Patching Fails as a Strategy in Industrial Environments

• Uptime dominates: availability and safety outrank confidentiality in OT decision-making.
• Long lifecycles: many PLCs and SCADA components remain in service for decades, far beyond vendor support windows.
• Rare maintenance windows: remediation is planned months ahead, not scheduled overnight.
• Fragile vendor ecosystems: some patches require re-qualification of the entire control loop.

Risk-Based Prioritization: The Controls That Matter First

A companion piece tied to the webinar—What Should OT Security Teams Prioritize First? Start With These 5 Controls—reinforces the resource-constrained reality of industrial plants. The message is consistent: compensating controls frequently deliver more resilience per engineering hour than patch-and-pray cycles.

The Five Priority Controls Outlined for OT Security Teams

#	Control	Operational Benefit
1	OT asset visibility and inventory	You cannot prioritize what you cannot see, including rogue or legacy devices.
2	Network segmentation and zones	Contains lateral movement and limits blast radius across control networks.
3	Secure remote access	Eliminates the standing pathways attackers most often exploit.
4	Identity and access control	Constrains privileged engineering actions and enforces least privilege.
5	Monitoring and incident response	Detects misuse of valid credentials before it becomes a control failure.

These align closely with guidance from SANS, Dragos and CISA, all of which stress that engineering-informed context—asset role, network location and physical consequence—should drive the remediation queue.

The Quiet Threat: When a Valid Login Becomes a Breach

The webinar's title points to a shift in attacker tradecraft that risk-based teams must internalize. Adversaries increasingly avoid malware signatures altogether, logging in with credentials that look legitimate and operating within expected protocol behaviour.

Recent vendor research into HMIs found that a significant share of industrial assets are still insecurely connected to the internet, and roughly a third of those carried at least one publicly exploited vulnerability. Credential hygiene, session monitoring and privileged-access controls are therefore not administrative overhead—they are frontline defence.

Frequently Asked Questions

Does the 4% figure mean most PLC vulnerabilities can be ignored?

No. It means they should be triaged rather than treated as emergencies. Low-priority ICS vulnerabilities still require documentation, compensating controls and periodic reassessment—especially if an exploit emerges or the asset's exposure changes.

Should operators patch PLCs immediately when a CVE is published?

Only when the vulnerability is actively exploited, grants remote code execution, abuses native ICS protocols or creates a path through remote access. Otherwise, schedule remediation within a planned maintenance window and deploy compensating controls in the interim.

What if a legacy PLC has no available patch?

This is where segmentation, protocol-aware monitoring and strict access control carry the load. Compensating controls are the standard response for end-of-support industrial devices that cannot be updated.

How should an OT team begin a risk-based program?

Start with a complete asset inventory that captures make, model, firmware version and network location. Map communication flows, correlate assets to known CVEs, then rank findings by exploit likelihood and physical consequence rather than severity score alone.

What This Means for Operators and Asset Owners

The strategic takeaway is a shift from volume to precision. A 4% emergency rate is not a reason for complacency—it is an argument for discipline. Teams that build engineering-informed triage capacity will protect more of their attack surface with the same headcount.

For procurement and maintenance planners, that discipline extends to the hardware itself. Selecting controllers with stronger native security features, documented firmware roadmaps and dependable long-term support reduces the future remediation burden before a device ever reaches the plant floor.

The question every OT leader should be asking is no longer "how many vulnerabilities do we have?" It is "are we fixing the right four percent?"