Water utilities are reached through the integrators, panel builders, instrument techs, and chemical suppliers who touch the plant. Here is how to inventory that network, write intelligence requirements against it, and push the findings into contracts.
Most water utilities can name the vendor on the front of the SCADA cabinet. Far fewer can name the systems integrator who wrote the logic inside it, the panel shop that built it, or the chemical supplier whose ordering portal touches the plant network. That gap is where supply chain risk lives, and it is one of the easier gaps for a small intelligence program to close.
Why the water sector supply chain is different
Water and wastewater utilities buy differently than most critical infrastructure. Capital projects are funded in bursts, often through grants or rate cases, which means a plant may run one generation of hardware for fifteen years and then replace half of it in a single season. Between those cycles, the people who actually understand the control logic are usually outside contractors.
The practical result is a long tail of third parties with real access:
- Systems integrators who hold the master project files and remote support accounts
- Panel builders and electrical contractors who preconfigure switches and HMIs before delivery
- Instrument vendors whose technicians connect laptops directly to analyzers and dosing controllers
- Chemical suppliers with telemetry links for tank level monitoring and automated reordering
- Billing, metering, and customer portal providers that sit adjacent to the operational network
- Engineering firms that hold as built drawings, network diagrams, and control narratives
Any one of those relationships can turn into an access path. Several of them carry design documents that would save an adversary weeks of reconnaissance.
Build the vendor inventory before the threat model
You cannot write useful intelligence requirements against a supply chain you have not enumerated. Start with a single table that a two person team can maintain in an afternoon:
| Field | Why it matters |
|---|---|
| Vendor name and role | Distinguishes an integrator from a parts supplier |
| Systems touched | Ties the vendor to specific PLCs, HMIs, historians, or business apps |
| Access method | Site visit, VPN, vendor cloud, cellular modem, or none |
| Data held offsite | Drawings, logic, credentials, telemetry |
| Contract owner | The person who can actually make a phone call |
| Last security review | Establishes whether anyone has ever asked |
Rank the list by blast radius, not by contract value. The instrument technician with a laptop that touches chlorine analyzers matters more than the largest line item in your budget.
Intelligence requirements that fit the supply chain
Once the inventory exists, the requirements write themselves. Keep them narrow enough that an analyst can answer them in an hour.
PIR 1. Has any named integrator, panel builder, or engineering firm in our vendor inventory been publicly reported as breached in the past ninety days?
Collection: ransomware leak site listings, state breach notification portals, regional news, vendor status pages, sector information sharing feeds.
Decision it drives: rotate any credentials that vendor holds, review remote access logs for their accounts, and request written confirmation about whether our project files were in scope.
PIR 2. Are any products in our installed base subject to a new advisory that a vendor has not yet notified us about?
Collection: CISA ICS advisories, vendor security bulletins, national vulnerability feeds filtered against the asset inventory.
Decision it drives: open a tracked mitigation item and decide whether compensating controls are required before the next maintenance window.
PIR 3. Are credentials, drawings, or project files belonging to our utility or our integrators appearing in leak data?
Collection: credential exposure monitoring, paste and leak site coverage, sector sharing partners.
Decision it drives: forced password resets, review of any shared or generic accounts, and notification to the contract owner.
PIR 4. Has a chemical supplier or logistics partner suffered a disruption that would affect treatment continuity?
Collection: supplier notifications, regional utility peers, trade press, transport and fuel disruption reporting.
Decision it drives: adjust inventory targets and confirm alternate sourcing before levels become critical.
PIR 5. Are adversaries publicly discussing or targeting the specific integrator community that serves our region?
Collection: honeypot telemetry showing reconnaissance tied to vendor default configurations, actor reporting, regional sector alerts.
Decision it drives: hardening of default vendor accounts and banners across the fleet.
What honeypot telemetry adds here
Vendor default configurations are visible from the outside. Default device banners, factory account names, standard port layouts, and unmodified web interfaces all leak the identity of the integrator who built the panel. That is useful to an attacker and useful to you.
Sensors that emulate the same protocol stacks your plant runs will show you which vendor fingerprints attract scanning and which credential pairs get tried. When a decoy running a common integrator default is probed with that integrator factory credentials, you have concrete evidence to bring to a vendor conversation. It moves the discussion from a policy questionnaire to observed behavior.
Turn intelligence into contract language
The findings only matter if they change how the utility buys. A short list of requirements, added at procurement time, covers most of the risk:
- Named notification contact and a defined window for reporting incidents that could affect our systems
- Prohibition on shared or default credentials, with unique accounts per technician
- Remote access only through utility controlled infrastructure, with sessions logged and time bound
- Written inventory of what utility data the vendor stores and where
- Right to review the vendor security posture on a defined cadence
- Requirement that as built documentation be delivered and stored under utility control
None of these are exotic. They are simply items that rarely appear in a water sector contract unless someone puts them there.
A realistic first month
For a small team, the sequence looks like this. Week one, build the vendor inventory. Week two, rank by access and data held. Week three, stand up collection against the top five vendors and set the five requirements above. Week four, take the first findings to the contract owners and add two clauses to the next procurement.
That is a working supply chain intelligence capability, and it fits inside the same program a two person shop already runs for plant and remote access intelligence.
The point
Water utilities do not get attacked in isolation. They get attacked through the network of people who built, maintain, and supply the plant. Treating that network as a named, tracked, and monitored part of the threat model is one of the highest return moves available to a small intelligence program.