One Configuration. Multiple Victims.
The recent cyberattacks against U.S. water and wastewater utilities revealed something potentially more consequential than the compromise of individual systems.
Across several victims, the FBI observed similarities in network setups provided by third parties. The agency warned that those similarities may give malicious actors an opportunity to repeat their success when vulnerable network and hardware configurations exist across multiple customers.
That finding changes the governance conversation. A cybersecurity weakness does not necessarily belong to one organization anymore. The same architecture may be installed across multiple utilities. The same remote-access approach may be reused. The same configuration decision may exist at site after site. And if one of those decisions creates exposure, the resulting risk can extend well beyond the organization where the weakness is first discovered.
The FBI has not publicly identified a third-party provider responsible for the incidents, nor has it concluded that one common configuration caused the broader campaign. But its warning raises an important question for critical-infrastructure leaders: who owns the risk when the vulnerability exists inside your environment but the decision that created it may have originated somewhere else?
That is the governance problem hiding underneath third-party cyber risk.
Outsourcing technology does not outsource accountability
Water utilities routinely rely on system integrators, equipment vendors, telecommunications providers and other specialists to install and maintain operational technology. That dependence is not inherently a problem. Critical infrastructure is complex, and specialized expertise is often necessary.
The governance issue appears when organizations assume that because a third party designed, configured or maintains part of the environment, the third party also owns the operational risk created by that environment. It does not work that way.
The utility still owns the service. The utility still answers to customers. The utility still carries the operational consequences when systems fail. And the utility still has to decide what happens when a vulnerability involving an external provider is discovered.
That means third-party cyber risk is not simply a procurement or vendor-management issue. It is a decision-authority issue.
Reuse creates efficiency. It can also create concentration risk.
Standardization makes operational sense. A third-party provider that supports multiple utilities may use similar equipment, network architectures or deployment approaches across customers. That can reduce complexity, make systems easier to maintain, and make training more consistent.
But repetition can also create a common point of exposure. The FBI's July 30 warning specifically noted that similarities in third-party-provided network setups across several victims could give attackers an opportunity to multiply their successes where vulnerable network and hardware setups are repeated across customers.
Independent analysis of the July campaign has drawn the same lesson: recurring configurations involving PLCs, cellular gateways, telemetry and remote-access architectures can allow similar weaknesses to appear across geographically separate utilities. That means a design decision made once may not remain isolated to one environment.
Organizations often assess third-party risk vendor by vendor. But the more important question may be architecture by architecture. If a configuration is repeated across multiple customers, leaders need to understand whether a vulnerability discovered in one environment creates an immediate reason to review every other environment using the same design.
Do you know which parts of your critical infrastructure use standardized configurations that may also exist across your provider's other customers?
The first victim may become the warning for everyone else
Imagine a system integrator supports 40 utilities using similar remote-access architecture. One utility discovers suspicious activity. At that moment, the issue is no longer confined to the first customer. The provider may now possess information relevant to every other organization using the same architecture.
That creates an escalation problem. Who determines whether the other customers are potentially exposed? Who contacts them? How quickly? What information can be shared while an investigation is still underway? What happens if the provider sees a pattern before individual customers do? And who has authority to require immediate changes across environments?
The FBI's finding does not establish that this exact scenario occurred during the current campaign. But the possibility is precisely why replicated architecture changes the risk model.
Third-party incident response cannot begin only when your organization confirms compromise. There should be defined thresholds for action when a provider, peer organization, government agency or other trusted party identifies a vulnerability affecting technology or architecture you also use. Otherwise every customer may independently rediscover the same problem.
What external signal is sufficient to trigger action inside your organization before you have evidence that your own environment has been compromised?
Responsibility and control are not the same thing
Third-party risk creates an uncomfortable governance reality. The organization may be accountable for a system it does not fully control. A vendor may manage the configuration. A telecommunications provider may control connectivity. A system integrator may maintain the PLC architecture. A manufacturer may control patches and product support. Yet the utility owns the operational consequence if water service is interrupted.
This creates what many organizations discover only during an incident: responsibility can remain internal even when technical control sits somewhere else.
That distinction matters under pressure. If a vulnerable configuration needs to be changed immediately, can the utility require the vendor to change it? Can internal staff make the change themselves? Does the contract permit emergency intervention? Who accepts the operational risk of changing a live OT environment? What happens if the vendor disagrees with the utility about urgency? Who has final authority?
Those are not purely technical questions. They are governance questions.
Third-party governance should define more than service levels and notification requirements. It should define decision rights during disruption. Who can order isolation? Who can approve configuration changes? Who can shut down remote access? Who decides when operations take priority over normal vendor processes? And who acts if the parties disagree?
If a third party controls part of your operational environment but you own the consequence of failure, who has final decision authority during an incident?
Vendor notification is not the same thing as decision activation
Many organizations have contractual requirements requiring vendors to notify them of cybersecurity incidents. That is important. But notification alone does not produce resilience. Someone inside the organization still has to decide what that information means.
Consider the difference. A vendor tells you that another customer using a similar configuration has been compromised. That is information. Now the organization must decide: do we disconnect remote access, inspect every similar device, move to manual operations, notify leadership, involve regulators, alert other partners, or wait for confirmation that our own environment is affected?
Those decisions may need to happen quickly, and they may involve consequences of their own. Disconnecting remote access can affect operations. Changing a PLC configuration can introduce risk. Moving to manual processes may require additional staffing. Taking a system offline may disrupt service.
Cyber intelligence creates value only when the organization knows what decisions it activates. A third-party alert should connect to predetermined escalation thresholds and assigned authority. Otherwise the organization receives the warning but still has to invent its response.
When a critical vendor tells you that a configuration you use may be vulnerable, what happens in the next 20 minutes?
Shared exposure can become a sector-level resilience problem
The current water-sector campaign demonstrates why this matters beyond an individual utility. Since July 27, water and wastewater organizations in at least seven states reported incidents to the FBI. Attackers remotely accessed internet-facing PLCs, changed IP addresses and passwords, and caused some organizations to lose monitoring or control functionality. Reported operational effects included pressure loss and flooding. In Minnesota alone, more than 30 community water systems were targeted during coordinated activity in late July.
The FBI's observation about similar third-party network setups introduces an additional dimension. A weakness repeated across customers can potentially create concentrated operational exposure across otherwise independent organizations. That should matter to utilities, system integrators, equipment manufacturers, insurers, regulators, state and federal agencies, and organizations responsible for regional resilience, because resilience at one facility may depend partly on decisions made by organizations outside that facility.
Critical infrastructure increasingly operates as an ecosystem. Governance models built entirely around the boundaries of one organization may not be sufficient when technology, vendors and configurations are shared across many operators. Decision authority therefore needs to work across organizational boundaries, not only within them.
If a shared vulnerability were discovered tomorrow at a peer organization using your same vendor architecture, would you find out before or after it reached you?
Third-party cyber risk is ultimately a decision problem
The FBI's warning points to five governance capabilities critical-infrastructure organizations should test.
1. Know where architecture is inherited
Organizations should understand which OT systems, remote-access methods, network configurations and connectivity decisions were designed or supplied by third parties. The issue is not simply maintaining a vendor inventory. It is understanding where external design decisions exist inside critical operations.
2. Identify replicated exposure
When a provider reports a vulnerability or compromise affecting another customer, organizations should be able to determine quickly whether they use the same technology, architecture or configuration. That should not require rebuilding the environment map during an incident.
3. Establish external escalation triggers
A confirmed compromise inside your organization should not be the only condition capable of activating response. Warnings from vendors, government agencies or peer organizations may justify action before local compromise is confirmed. Those thresholds should be predetermined.
4. Define decision rights with critical vendors
Contracts and operating agreements should establish who has authority to isolate systems, alter configurations, suspend remote access or implement emergency changes. Organizations should know what happens when operational urgency conflicts with normal vendor change-management procedures.
5. Exercise cross-organizational response
Incident exercises should include critical third parties. Test what happens when a provider identifies a potentially shared vulnerability. Who calls whom? Who assesses exposure? Who decides? Who acts? And how long does it take?
One organization's configuration can become another organization's warning
The FBI's finding should not be interpreted as evidence that one vendor caused the recent water-sector attacks. That has not been established.
The more important lesson is structural. Critical infrastructure does not operate as thousands of completely independent technological environments. Organizations use common equipment, common vendors, common integrators, common remote-access methods, and sometimes similar configurations. That interconnectedness creates enormous operational efficiency. It can also create concentration risk.
A weakness discovered at one organization may therefore be relevant to many others before those organizations experience an incident themselves. The governance challenge is whether they can recognize that signal and act on it fast enough, because the organization may not have created the vulnerability, may not control every technology involved, and may not even be the first organization attacked. But it still owns the decision about what happens next.
So the question for critical-infrastructure leaders is not simply "are our vendors secure." It is "when risk crosses organizational boundaries, does our authority model cross them too."
Third-party cybersecurity programs often focus on assessment, contractual requirements and notification. Crisis resilience requires another layer.
Organizations need to know how they will make decisions when an external partner identifies a threat that may affect their operations, particularly when the evidence is incomplete and waiting for certainty may increase exposure. CrisisOS5™ examines how Operations, Cybersecurity, Legal, Communications, procurement, third parties and executive leadership work together when organizational boundaries become part of the incident.
- Reveal which parts of your environment were designed or configured by a third party, and where
- Identify what external signal, short of your own confirmed compromise, would trigger action
- Clarify who has authority to require emergency changes when a vendor controls part of the environment
- Test how your organization would respond if a peer using the same architecture were compromised tomorrow
Sources
- Federal Bureau of Investigation and Environmental Protection Agency, "Malicious Cyber Actors Targeting Water and Wastewater Sector Internet-Facing Programmable Logic Controllers, Causing Operational Disruptions," July 30, 2026. View source
- LevelBlue SpiderLabs, "Review of the July 2026 Cyberattacks Against U.S. Water and Wastewater Systems," August 2026. View source
- Reuters, "Minnesota IT officials disclose 'coordinated cyberattack' at more than 30 local water systems," July 28, 2026. View source
Source note: This case study is based on the FBI and EPA's July 30, 2026 public service announcement on attacks against water and wastewater operational technology, LevelBlue SpiderLabs' independent technical analysis of the campaign, and Reuters reporting on the Minnesota water system incidents.