Remote Access at Water Utilities: Who Can Touch the Plant Tonight?

Yesterday we wrote about building a threat intelligence practice around treatment and distribution. That post was about scope: knowing what you operate, what it controls, and which adversary behavior actually matters to a water system.

This post narrows to the single pathway that shows up in nearly every water sector incident worth studying. Remote access.

Not because remote access is new, and not because operators are careless. It shows up because water and wastewater systems are geographically distributed, thinly staffed, and heavily dependent on integrators. Someone has to reach a lift station at 2 a.m. The question is whether that someone is accounted for.

The intelligence question is an inventory question first

Most water utilities can answer "do we have remote access" instantly. Very few can answer the version that matters:

1. Which specific paths exist into the OT environment right now?
2. Who holds credentials on each path, including vendors and former staff?
3. Which paths land directly on a PLC, HMI, or engineering workstation rather than a broker?
4. Which paths are logged in a place an analyst actually reads?
5. Which paths would survive a password reset campaign because they use a shared or embedded credential?

Write those five answers down. That document becomes the collection target. Every advisory, every honeypot hit, every credential dump gets evaluated against it.

Paths that keep getting missed

Cellular modems on lift stations and booster pumps. Installed by a contractor, billed to operations, invisible to IT. Many ship with a management portal exposed to the carrier network.

Vendor maintenance tunnels. A SCADA integrator keeps a persistent tunnel so support can respond quickly. It works. It also means the utility inherits that vendor's credential hygiene, endpoint posture, and breach history.

Historian and reporting bridges. A read only data path is still a path. If the bridge host is domain joined on the enterprise side and dual homed to the OT VLAN, it is a route, regardless of what the data flow diagram claims.

Operator convenience access. RDP through a jump host that was meant to be temporary during a plant upgrade three years ago. Ask about it directly. People will tell you.

Legacy dial up and serial radio. Still present at a surprising number of small systems, and almost never in any monitoring scope.

Turning this into intelligence requirements

The generic requirement "monitor for threats to remote access" produces nothing. Requirements tied to your inventory produce work.

• Are credentials associated with our SCADA integrator or its parent company appearing in infostealer logs or breach dumps?
• Have new vulnerabilities been published for the specific VPN appliance, cellular gateway, or remote support product models we operate, including firmware versions?
• Are opportunistic scanners probing the protocols and ports our field sites expose, and is the volume changing?
• Has any advisory described initial access at a water or wastewater system through a pathway that matches one of ours?
• Are our public IP ranges appearing in access broker listings?

Each requirement names a thing you own. That is what makes it collectable and what makes the answer actionable.

What honeypot telemetry adds here

Scanner traffic against exposed HMI and PLC protocols is not exciting on its own. What it does provide is a baseline. When a decoy that mimics a common water sector gateway starts receiving credential attempts using vendor default accounts, that is a shift in intent, not just noise. It tells you which vendor products are currently being targeted, and it tells you before an advisory catches up.

Pair that with the inventory above and you get a prioritized list rather than a feed.

Practical first moves

Small utilities do not need a program rebuild to make progress this quarter.

1. Walk the fence line. Physically confirm what is installed at each remote site. Photograph the cabinet. Note every antenna, modem, and cable that leaves it.
2. Ask vendors in writing which access they hold, through what product, using which accounts, and how they would notify you of a compromise.
3. Kill the shared account. Named accounts only, on every path, even if it is inconvenient for a two person shop.
4. Log to somewhere neutral. Authentication events from the VPN and jump host should land off the OT network and be reviewed weekly at minimum.
5. Rehearse the disconnect. Decide in advance who has authority to sever vendor access, and confirm the plant can run in manual while it is severed. That decision is far easier made on a Tuesday morning than during an incident.

The measure of success

You are not aiming for zero remote access. Water systems cannot operate that way, and pretending otherwise pushes access into the shadows where nobody monitors it.

The goal is that every path is named, owned, logged, and revocable within an hour. When an advisory drops naming a product you run, the response is a lookup rather than an investigation.

That is the difference between having threat intelligence and using it.