By Ann Marie van den Hurk, Mind The Gap Advisory
The FBI’s July warning about the water-sector attacks included a detail most coverage skipped past. Across several victims, investigators found similarities in network setups provided by third parties. Not one bad utility. One repeated architecture, installed site after site by outside providers.
That single observation should change how critical infrastructure leaders think about vendor risk.
The question underneath the finding
The FBI hasn’t identified a specific provider. It hasn’t concluded that one configuration caused the broader campaign. What it flagged is structural: similar third-party network setups across multiple customers may give attackers a way to repeat their success wherever that setup exists.
That reframes the accountability question. Who owns the risk when the vulnerability lives inside your environment, but the decision that created it may have originated somewhere else?
I call this the Third-Party Authority Gap. It’s the space between who controls a piece of your critical infrastructure and who’s actually accountable for what happens when it fails.
The uncomfortable math
Imagine a system integrator supporting 40 utilities on the same remote-access architecture. One discovers suspicious activity. At that moment, the provider may hold information relevant to the other 39, and none of them may know it yet.
Who decides they’re exposed? Who tells them, and how fast? Most organizations have never actually answered that.
Reuse is efficient. It’s also concentration risk.
Standardization makes operational sense. A provider supporting multiple utilities with similar equipment and network architecture reduces complexity and makes training consistent. Independent analysis from LevelBlue SpiderLabs found the same pattern in the July campaign: recurring configurations involving PLCs, cellular gateways, telemetry, and remote-access setups kept appearing across geographically separate utilities with no other connection to each other.
A design decision made once, in other words, doesn’t necessarily stay isolated to one environment.
Organizations often assess third-party risk vendor by vendor. The more useful question is architecture by architecture: if a configuration is repeated across multiple customers, does a vulnerability discovered in one environment create an immediate reason to review every other environment using the same design?
Notification is not the same thing as a decision
Most vendor contracts require notification when something goes wrong. That’s necessary, and it isn’t sufficient. A vendor telling you another customer on your same setup was compromised is information. Someone inside your organization still has to decide what it means: disconnect remote access, inspect every similar device, move to manual, notify leadership, alert regulators, or wait for confirmation your own environment is affected.
Those decisions carry consequences of their own. Disconnecting remote access affects operations. Moving to manual processes may require staffing you don’t have on shift. Without a predetermined threshold connecting the vendor’s warning to an assigned authority, the organization receives the alert and still has to invent the response in real time.
What this means for compliance frameworks like CMMC
For organizations working toward CMMC or similar requirements, this is already inside the scope of what you’re being asked to document. Decision rights with vendors, defined escalation triggers, and an accountable response structure aren’t extra credit. They’re the baseline the framework already expects.
The compliance and crisis readiness intersection
A vendor contract that defines notification requirements has not resolved decision authority. It has deferred it to whoever happens to be paying attention when the notification arrives. Assessors want to see who has final say. So does the incident.
The test worth running
The FBI’s finding shouldn’t be read as proof that one vendor caused the water-sector campaign. That hasn’t been established. The structural lesson matters regardless: critical infrastructure runs on shared equipment, shared integrators, and shared configurations repeated across organizations with no other connection to each other. A weakness discovered at one utility can be relevant to dozens more before any of them experience an incident themselves.
Ask your leadership team the harder version of the vendor-security question: if a peer organization using your same architecture were compromised tomorrow, would you find out before or after it reached you? And if you found out first, who’s actually authorized to act on it?
When risk crosses organizational boundaries, the question isn’t only whether your vendors are secure. It’s whether your authority model crosses those same boundaries.
If you want to test where that authority breaks down
CrisisOS5™ Cyber Crisis Tabletop Simulation
A structured simulation that stress-tests how Operations, Cybersecurity, Legal, Communications, procurement, and executive leadership behave when the incident starts outside your walls but the consequence lands inside them.
Ann Marie van den Hurk, MSc., APR is the founder of Mind The Gap Advisory and originator of the CrisisOS5™ Framework. She advises CISOs, General Counsel, Chief Risk Officers, and boards on decision authority and executive crisis readiness for the AI era. Based in Newport, Rhode Island — serving organizations across New England, nationally, and globally. mindthegapcyber.com