OT Cybersecurity for Local Utilities: Waterworks, Power Grids and Waste Plants with Zero Internal Resources

The paradox of local utilities: critical yet defenseless

Local utilities (operators of municipal waterworks, regional power distributors, operators of wastewater and waste treatment plants) manage infrastructure that is critical to the daily life of communities. A waterworks that stops functioning is not a production problem: it is a public health emergency. A waste treatment plant that goes offline affects public health within days.

And yet, the security resources of these entities are often inversely proportional to their criticality. A small water company serving a catchment of a few tens of thousands of inhabitants may have a single technician responsible for the entire operational management of the plant, SCADA included. No structured IT team, no OT security expertise, no dedicated cybersecurity budget.

NIS2, transposed in Italy through Legislative Decree 138/2024, explicitly includes drinking water and wastewater operators in the category of essential entities, and waste operators in the category of important entities. This means concrete obligations: adequate security measures, incident notification, management accountability. The legislator has recognized the criticality of the sector. The sector must now respond.

The Oldsmar case: a waterworks, a TeamViewer, and a near catastrophe

On 5 February 2021, an operator of the Oldsmar water system in Florida noticed something strange: his computer cursor was moving on its own. Someone was remotely accessing the waterworks control system. Within minutes, the attacker raised the level of sodium hydroxide (caustic soda) in the water from 100 parts per million to 11,100, that is 111 times the normal level, potentially lethal for consumers.

The operator intervened immediately, restoring the correct level. The attack failed thanks to human alertness and, probably, because sodium hydroxide at those concentrations would have triggered the water quality sensors before reaching households anyway. But the vulnerability was devastating in its simplicity: the SCADA system was accessible via TeamViewer, with an outdated version of the software, and access to it was probably not monitored.

Oldsmar is not an isolated case. In the following months, US authorities published advisories documenting similar attempts against waterworks in other states. In Italy, while no incidents of comparable profile have been publicly documented, security authorities have detected reconnaissance activity against the SCADA systems of water infrastructure.

The lesson of Oldsmar is simple and brutal: a SCADA system exposed to the internet with unauthenticated or weakly authenticated remote access is a critical vulnerability, regardless of the size of the operating entity. And this configuration is more common than people care to admit.

The typical architecture: dated SCADA, unmanaged connections, internet exposure

The technical reality of Italian local utilities is often this: SCADA systems installed 15 to 20 years ago, designed for closed networks, that over time have been connected to the internet to allow remote monitoring and reduce the cost of on-site interventions. The connection happened incrementally (a VPN access here, a TeamViewer account there, a SCADA web interface exposed for convenience) without any systematic assessment of the risks each addition introduced.

The result is an attack surface that extends across the internet, with systems that cannot be easily updated (because the vendor no longer supports the software, or because an update would require a plant shutdown that cannot be scheduled), accessible with weak or shared credentials, with no access logging that would allow anomalous activity to be detected.

Some recurring patterns:

Default credentials never changed. Many SCADA systems are installed with the vendor's default credentials ("admin/admin", "operator/operator") that are never changed. These credentials are publicly known and are systematically tested by attackers during reconnaissance.

VPN access without MFA. Remote access through a VPN without multi-factor authentication is vulnerable to credential stuffing: if the credentials are compromised (through phishing, database leaks, password reuse), the attacker gains direct access to the control system.

End-of-life operating systems. Legacy SCADA systems often run on unsupported versions of Windows, such as Windows XP and Windows 7, which no longer receive security patches and are vulnerable to known exploits. Updating these systems is complex (SCADA software compatibility, vendor certification) but the vulnerability is real.

Priorities with limited resources: what to do first

The resource constraint is real in local utilities and must be respected. There is no point in proposing OT security programs suited to large organizations to entities that have a part-time technician managing SCADA. Priorities must be calibrated to the context.

First priority: eliminate unnecessary internet exposure. Any SCADA access interface exposed directly to the internet (web interface, RDP access, unprotected TeamViewer) must be removed or placed behind a strong authentication layer. This is not an operation that requires specialist skills or a large budget; it requires the willingness to accept some operational inconvenience in exchange for a drastic reduction of the attack surface.

Second priority: strong authentication for remote access. Any remote access that remains after cleaning up internet exposure must be protected with MFA. Even simple solutions, such as a second factor via app or SMS, significantly reduce the risk of compromise through credential theft.

Third priority: asset inventory. Knowing what is on the OT network is the prerequisite for any other measure. An accurate inventory, even one built manually at first, identifies the most vulnerable systems and the undocumented connections. Passive network traffic monitoring makes it possible to build this inventory systematically and keep it up to date.

Fourth priority: minimal response procedures. Having a written procedure, even just a few pages long, that describes what to do in the event of a suspected incident is infinitely better than having none. Who to call, how to isolate a system without stopping the service, how to document the incident for notification to the competent authority.

Monitoring: visibility without internal expertise

One of the most common objections to OT monitoring solutions is that they require internal expertise to manage alerts and interpret data. For a local utility with one technician, this objection is concrete.

The answer is not to eliminate monitoring, but to choose an approach that is sustainable with the available resources. Passive OT traffic monitoring, configured correctly for the specific environment, generates a set of prioritized alerts that do not require specialist skills for initial triage: a new device that has appeared on the network, a remote access outside working hours, a communication toward an unexpected external IP address: these are signals that are understandable even without specialist training in OT cybersecurity.

The key is calibration: a monitoring system not calibrated for the specific environment will generate a number of alerts that overwhelms any organization. A calibrated system, one that knows the normal baseline of that SCADA, those RTUs, that telemetry system, generates meaningful alerts in a manageable number.

Many local utilities would benefit from a hybrid model: local monitoring with prioritized alerts, plus remote support from a specialized provider for managing the higher-severity alerts. This distributes the expertise load without requiring the entity to develop internally capabilities it does not have and probably cannot afford to develop.

NIS2 and management accountability

NIS2 introduces an element that many local utilities have not yet fully grasped: the personal accountability of management. The Italian transposition decree requires the administrative and management bodies of essential and important entities to approve cyber risk management measures and oversee their implementation. In the event of serious violations, individual managers may also be subject to sanctions.

For the director of a small water company, this means that OT cybersecurity is no longer a technical matter delegated to the SCADA technician: it is a governance responsibility that requires awareness, decisions, and documentation of the choices made.

It is not about becoming OT security experts. It is about being able to demonstrate that risks have been assessed, that measures proportionate to the available resources have been taken, that there is a plan, even a minimal one, to respond to incidents. Documenting the decisions made is just as important as the decisions themselves.

Italian local utilities are at a crossroads: start now to build an OT security posture proportionate to their resources, or wait for an incident, or an inspection by the competent authority, to force their hand under emergency conditions.

The MON5 angle

A single technician, a fifteen-year-old SCADA system, no dedicated budget: the starting point described in this article is exactly the one MON5 designs a modular path around. You begin with the assessment and the passive discovery of assets, which surface internet exposures and forgotten remote accesses without requiring internal expertise or plant shutdowns; monitoring capabilities are then activated in phases, when they are needed.

The hybrid model suggested above is also natively supported: the multi-tenant architecture allows an external provider to manage the alerts of multiple utilities from a single platform, leaving the local technician with only the essential triage. The first sustainable step is an OT assessment proportionate to the real resources.