A new SpyCloud report published Sept. 20 points to a less visible weakness in U.S. water security: not just internet-exposed controllers at treatment plants, but stolen identities on staff laptops, remote-access tools, shared mailboxes, and vendor systems that sit around them. In a sample of 10,000 water-sector organizations drawn from an EPA-registered universe of 66,845 drinking-water and wastewater systems and related vendors, SpyCloud found 1,787 with active infostealer exposure and 258 with credentials tied to operational-technology or remote-access systems. It also identified 263 organizations appearing in active phishing or business-email-compromise targeting.
The most consequential detail was not the raw count. It was concentration. SpyCloud says one infected device at an unnamed advanced-metering technology provider contained saved logins associated with roughly 167 utility metering tenants.
That does not amount to a confirmed breach of 167 utilities, much less a water outage. No public source ties these exposed records to a plant intrusion or service disruption. But it does sharpen the question utility leaders, vendors, and municipal IT teams should be asking now: when a credential appears in infostealer data, is changing the password enough, or could a live path still exist through a vendor account, a remote-management tool, or an authenticated session that survives the reset?
The practical boundary is wider than the plant
Water-sector cyber coverage often centers on internet-facing HMIs, default PLC passwords, and other obvious OT weaknesses. Those risks are real, and federal agencies continue to warn about them. But SpyCloud’s findings matter because they widen the defensive perimeter. The security boundary is not just the treatment plant or the SCADA network. It includes the laptops used by municipal staff, the remote-access software used by contractors, the metering platforms run by suppliers, and the identities that connect all of them.
That is why the 167-tenant example stands out. A single utility may keep its own network segmented, yet still inherit exposure through a supplier endpoint or integration account that touches many customers. In practice, vendor access can create a many-to-many trust problem: one compromised laptop, browser profile, or support account may reveal credentials associated with dozens of utilities that otherwise have no direct connection to each other.
SpyCloud says it reviewed 523,572 infostealer-sourced records across 76,367 infected devices and collapsed duplicates before arriving at its sector counts. Even with that scale, the findings are still a sample, not a census of every U.S. water system, and the public record does not identify the vendor, the utilities, the age of the credentials, or whether the exposed accounts were still active. Still, for smaller utilities with limited security staffing, the lesson is immediate: your own password policies do not fully control your exposure if a supplier’s endpoint is part of your access model.
Why a password reset may miss the real problem
The main response gap here is technical, not rhetorical. Infostealer malware can collect saved passwords, browser data, and session material. SpyCloud also says it found session evidence consistent with adversary-in-the-middle phishing, where an attacker captures an authenticated session after the user completes multifactor authentication. In that scenario, MFA was not necessarily “broken”; the attacker may simply replay the valid session afterward.
That distinction matters because a password reset can fix only one part of the problem. If the exposed risk is a still-valid session, token, or cookie, the response may need to include session invalidation, token revocation, log review, and endpoint reimaging. If the exposed record belongs to a vendor’s remote-support workflow, the utility also needs to know whether the account still exists, whether it still reaches remote administration or OT-adjacent systems, and whether old integration credentials were ever decommissioned.
SpyCloud’s examples show why. The report identified credentials for tools and portals such as TeamViewer, LogMeIn, GoToMyPC, and SonicWall and Fortinet management interfaces on municipal staff devices. It also described a small water district with a shared `scada@` mailbox and an exposed remote-desktop credential. None of that proves a plant was entered. It does show how quickly the question changes from “Was a password stolen?” to “What could this identity actually do?”
This is also why utilities should avoid collapsing every water-sector incident into one narrative. SpyCloud says the July 2026 Minnesota water-system incidents appeared more like an exposed-PLC story than a stolen-credential story. The response priorities overlap, but they are not identical. Publicly exposed OT and identity exposure are parallel workstreams, not interchangeable diagnoses.
What utilities and vendors should verify first
For operators, the first task is scoping, not panic. Confirm which exposed records actually belong to the utility or one of its suppliers. Then map each account to privileges and access paths: VPN, firewall management, remote desktop, metering portals, shared mailboxes, SCADA support channels, or third-party administration tools. An exposed username tied to a dead portal is different from an active credential tied to vendor maintenance access.
From there, the practical checklist gets more specific. Revoke active sessions and tokens, not just passwords. Rotate credentials for any account with current or recent administrative reach. Review authentication logs and vendor activity logs for signs of remote administration, unusual token use, or suspicious access tied to the affected identities. If the source device is infected, reimage it rather than treating the exposure as a simple credential event.
The supplier conversation matters just as much. Utilities should ask vendors for a documented incident scope, a tenant-notification process, evidence that sessions were invalidated, and proof that old integration credentials are no longer usable. If a vendor cannot show which customer accounts were present on an infected endpoint, the utility has to assume uncertainty in its own risk model.
At the same time, none of this replaces the more familiar OT hygiene. Utilities still need to remove unnecessary public exposure from PLCs and HMIs, eliminate default passwords, and segment remote access from critical control environments. Federal warnings about unauthorized remote users adjusting real-time settings remain relevant. The point is not to pick identity security over OT security. It is to recognize that the route into operational risk may begin on a vendor laptop or a stolen browser session rather than at the controller itself.
That makes this more than a water-industry story. Any sector that depends on shared suppliers, remote administration, or privileged sessions can inherit the same concentration risk. The water sector is simply showing, in unusually concrete form, how one infected endpoint can expand the blast radius far beyond a single organization.
By
By
By
By
By
By
