OT Systems That Cannot Be Updated: Compensating Controls and Risk Reduction

The Reality of Italian Plants

Those who work in OT security in Italy know the scene well: manufacturing plants with decades of history, machinery acquired at different periods, control systems that have functioned without problems for fifteen or twenty years and that nobody has ever had an urgent reason to replace. As long as the machine produces, touching it seems like an unnecessary risk.

The result is that many Italian production lines host PLCs programmed in the pre-smartphone era, HMIs running versions of Windows that have been out of support for years, and SCADA servers with application software that the vendor stopped updating long ago. This is not negligence — it is the economic rationality of OT, where investment in new systems is justified only by a clear operational gain, not by cyber risk reduction alone.

These systems share one trait: they cannot be patched. The reasons vary.

Vendor no longer releasing updates: the system is out of support, the vendor has abandoned that product line or was acquired. There is no patch to apply.

Hardware that does not support updated versions: the PLC's memory or computing power is insufficient for updated firmware. Upgrading means replacing hardware, with costs and operational impacts that are often not approved.

Maintenance contracts prohibiting software modifications: some installations have contracts with the original vendor that include clauses voiding the warranty if software is modified without vendor authorization. Applying a patch independently might be technically possible but legally problematic.

Validation procedures making updates impractical: in sectors such as pharma or food, control systems may be subject to regulatory validation. A software update requires new validation, with timelines and costs that can exceed those of a complete replacement.

What Managing Risk Without Patching Means

The temptation, when facing an unpatchable system, is to declare it "accepted risk" and move on. In some cases, with rigorous analysis, this can be the correct conclusion. But "accepting risk" does not mean ignoring it — it means consciously documenting the decision, defining the conditions that keep it valid, and establishing what would change that conclusion.

Risk management on unpatchable systems operates on three axes:

Reducing exposure: limit as much as possible the attack surface reachable from the vulnerable system. If the system cannot be patched, at least you can reduce who can communicate with it and how.

Increasing visibility: if you cannot eliminate the vulnerability, you need to be able to detect quickly if someone is exploiting it. Early detection partially compensates for the absence of patches.

Reducing potential impact: segment so that a compromised system does not automatically become an entry point to the entire OT network.

Network Isolation: The Most Effective Compensating Control

Network segmentation is the compensating control with the best ratio of effectiveness to feasibility for legacy OT systems. The idea is simple: if a vulnerable system cannot be patched, at least limit who can reach the vulnerability.

In practice this means defining firewall or ACL rules on switches that allow only the traffic strictly necessary for the system to operate, blocking everything else. For a legacy PLC using Modbus TCP to communicate with a specific HMI, the rules should allow only that communication — no internet browsing, no access from unauthorized network segments, no unexpected inbound connections.

This approach does not require touching the vulnerable system — it acts on the network around it. It must be executed carefully, documenting before blocking traffic which communications are legitimate for the system, to avoid interrupting operational functionality. A preliminary analysis of real traffic through passive monitoring allows building precise rules rather than approximate rules that then require constant exceptions.

Communication Whitelisting

A concept related to segmentation but more granular is communication whitelisting: defining not only who can communicate with the legacy system, but what specific traffic is considered normal.

For OT protocols, this can mean allowing only certain Modbus function codes, only certain OPC UA operations, only the register reads that the normal process requires. An attacker using the same protocol for different purposes — reading configuration instead of just process data, writing to registers instead of only reading — produces traffic that falls outside the whitelist.

OT traffic monitoring makes it possible to detect these anomalies. Compared to pure segmentation, whitelisting requires deeper knowledge of the system's normal behavior but offers much finer visibility into what is happening.

Passive Monitoring as a Detection Layer

If I cannot eliminate the vulnerability and cannot stop production to investigate every anomaly, at least I can know when something unusual happens.

Passive OT traffic monitoring — positioning sensors that listen to traffic without interacting with devices — is particularly suited to legacy systems for two reasons. First: it does not require installing anything on the vulnerable system, which might react badly or which by contract cannot be modified. Second: industrial OT traffic on legacy systems tends to be highly repetitive and predictable, which enormously simplifies building a baseline and detecting deviations.

A legacy OT system that communicates every five seconds with an HMI to exchange process data produces a stable, recognizable traffic pattern. An unexpected management connection, an attempt to write to a register, a new session from an unknown IP — these anomalies stand out clearly against the baseline.

Detection does not resolve the vulnerability, but it radically changes the operational situation: from "we are vulnerable and we do not know it" to "we are vulnerable but we know it and we know when someone is trying to exploit it." This visibility allows responding instead of passively suffering.

Operational Procedures as Compensating Controls

An often underestimated aspect is that OT risk depends not only on technology — it also depends on procedures and people. Compensating controls are not only technical.

For unpatchable systems, some procedural measures have concrete impact:

Controlled physical access: a legacy system unreachable via the network is far less vulnerable. Where possible, limiting physical access to network and serial ports of critical systems reduces risk even without patches.

Procedures for vendor remote access: if a vendor needs to access the legacy system for maintenance, access must follow a defined process — a predetermined time window, supervision by an internal operator, immediate disconnection upon completion. No permanent access or shared credentials.

Periodic configuration verification: even without patching, verifying that the system configuration has not changed from baseline is a useful control. Unauthorized configuration changes — a possible indicator of compromise — should be detected as quickly as possible.

Rigorous change management: every modification to the network around a legacy system must be documented and evaluated for its impact on the security posture. Adding a new device that can reach the legacy system is a change to its exposure, even if it is not a change to the system itself.

Long-Term Return Plan

Compensating controls are not a permanent solution — they are temporary risk management while working toward a more structural solution. The unpatchable legacy system of today will need to be replaced or upgraded in the future: the question is when and at what priority.

A realistic return plan for legacy OT systems includes:

Classification by criticality and risk: not all legacy systems have the same risk profile. Those with high-EPSS vulnerabilities, poor segmentation, and a critical role in the production process have higher replacement priority.

Multi-year budget: replacing critical OT systems cannot be improvised. It requires planning, testing in a staging environment, vendor coordination, and extended maintenance windows. It must be built into the investment plan years in advance.

Evaluation of hardening alternatives: before concluding that a system is truly unpatchable, it is worth exploring all options. Sometimes an unpublicized vendor patch exists, sometimes the vendor can provide an updated version compatible with existing hardware, sometimes a partial update significantly reduces the attack surface even without bringing the system to the latest version.

The unpatchable legacy system is a reality that does not disappear overnight in Italian plants. Managing it with a structured approach — isolation, continuous visibility, rigorous procedures, return plan — is more effective and more intellectually honest than simple "accepted risk" with no further action.

The MON5 Angle

When patching is not an option, two things matter: knowing which legacy systems expose the greatest risk, and knowing if someone tries to exploit them. MON5's ANALYZE phase correlates CVEs for unpatchable systems with EPSS scores and real network exposure, distinguishing theoretical vulnerability from the kind that warrants an immediate compensating control.

The PROTECT phase provides the detection layer described above: out-of-band passive monitoring on native OT protocols, traffic baseline of repetitive legacy system patterns, and ML anomaly detection on deviations — nothing installed on the devices. To classify your legacy systems by real criticality, start with an OT assessment.