Summary
CISA observed malicious cyber activity targeting more than 100 internet-exposed systems in the U.S. Water and Wastewater Systems Sector during July 2026, frequently involving programmable logic controllers connected directly to cellular modems.
The immediate cybersecurity lesson is clear: unnecessary internet exposure of operational technology creates significant risk. But the larger governance question begins after an organization knows that exposure exists. Who owns the risk? Was remediation funded? Were operational constraints evaluated? Were compensating controls implemented? Who authorized continued operation, and when will that decision be reconsidered?
This Cyber Brief introduces a critical governance principle: Known Exposure → Accountable Decision. When critical systems cannot be immediately remediated, organizations need explicit risk ownership, documented exceptions, compensating controls, expiration dates, monitoring, and evidence demonstrating why continued exposure was accepted. The absence of a formal decision does not mean the organization avoided accepting the risk.
More than 100.
That is the number that should change the conversation.
In July 2026, the Cybersecurity and Infrastructure Security Agency observed malicious cyber activity targeting more than 100 internet-exposed systems in the U.S. Water and Wastewater Systems Sector.
The common point of exposure was particularly troubling.
Programmable logic controllers—PLCs—were frequently connected directly to cellular modems and reachable from the internet.
These are not ordinary business computers.
PLCs are industrial computers used to control physical processes. In water and wastewater environments, they can help operate pumps, valves, treatment equipment and other machinery responsible for moving and processing water.
Attackers targeting these systems are therefore not merely reaching information.
They are reaching operations.
But there is another reason the number matters.
When one exposed industrial controller is attacked, we can investigate an incident.
When more than 100 internet-exposed systems across a critical-infrastructure sector are targeted within a month, we need to ask a different question:
Why did a known class of critical exposure remain operational at scale?
That is where this stops being merely a cybersecurity story.
It becomes a governance story.
The Vulnerability Is Not Just the PLC
The immediate technical lesson is relatively straightforward.
Critical operational technology should not be unnecessarily exposed to the public internet.
CISA’s response has emphasized reducing internet exposure, including removing unnecessary public access and securing remote connectivity when internet access is operationally required.
That is sound cybersecurity practice.
But it does not answer the governance question.
Because a PLC does not connect itself to a cellular modem.
Someone designed that architecture.
Someone installed it.
Someone operates it.
Someone owns the system.
Someone is responsible for understanding its risk.
Someone decides whether remediation is necessary.
Someone decides whether remediation receives funding.
And if the exposure remains after the risk becomes known, someone—explicitly or implicitly—is accepting the risk of continued operation.
That creates a governance chain:
Exposure Identified → Risk Assessed → Owner Assigned → Remediation Decision → Funding → Implementation → Verification → Residual Risk
If that chain breaks, the exposed device remains.
The vulnerability may appear technical.
The reason it persists may not be.
When a Technical Condition Becomes a Risk Decision
This distinction matters far beyond the water sector.
Organizations operate with vulnerabilities every day.
Not every vulnerability can be remediated immediately.
Some systems cannot be patched without disrupting operations.
Some equipment is obsolete but still essential.
Some replacements require capital expenditures.
Some remote-access configurations exist because technicians need to maintain geographically dispersed equipment.
Some legacy systems cannot support modern security controls.
Those realities are particularly common in operational technology.
Governance does not require pretending those constraints do not exist.
It requires making them visible.
Once management knows that a critical system remains exposed, continued exposure becomes a decision.
The decision might be:
Remediate immediately.
Isolate the system.
Introduce compensating controls.
Restrict remote access.
Replace the equipment.
Accept the risk temporarily.
Or, in some cases, accept the risk for an extended period because the cost or operational consequences of remediation are judged greater than the perceived cyber risk.
Any of those decisions may be defensible depending upon the circumstances.
What is difficult to defend is this:
Nobody made the decision.
The system simply remained exposed.
Risk Acceptance Can Happen Without Anyone Accepting the Risk
This is one of the most persistent weaknesses in enterprise cybersecurity governance.
Organizations frequently have formal risk-acceptance procedures.
A significant vulnerability is identified.
A risk owner reviews it.
Management evaluates remediation options.
Residual risk is documented.
An authorized executive approves an exception.
The exception has an expiration date.
Controls are monitored.
The decision is periodically reconsidered.
That is what governance is supposed to look like.
But operational reality is often less orderly.
A vulnerability appears in a report.
The infrastructure team opens a ticket.
The ticket competes with dozens of priorities.
Remediation requires downtime.
Operations resists the outage.
Funding is deferred until the next budget cycle.
The equipment vendor recommends replacement.
Replacement becomes part of a future modernization project.
Months pass.
The system remains exposed.
Nobody formally says:
We accept this risk.
Yet the organization continues operating.
Functionally, the risk has been accepted.
The difference is that nobody may be accountable for the decision.
That is implicit risk acceptance.
And critical infrastructure cannot afford to confuse the absence of a decision with the absence of risk.
Internet Exposure Is an Architecture Decision
There is another important lesson in the water-sector attacks.
Internet exposure is not merely a configuration setting.
It is an architecture decision.
A PLC connected directly to a cellular modem represents a particular design for remote connectivity.
That architecture may have been created years ago for perfectly understandable reasons.
Perhaps a vendor needed remote access.
Perhaps the utility had geographically distributed infrastructure.
Perhaps cellular connectivity was cheaper than building a dedicated network.
Perhaps the device predated current threat assumptions.
But architecture accumulates consequences over time.
A design that was operationally convenient ten years ago may become unacceptable as the threat environment changes.
That means cybersecurity governance must periodically revisit architectural assumptions.
The relevant question is not simply:
Was this architecture acceptable when we deployed it?
It is:
Is this architecture still acceptable under today’s threat conditions?
That distinction is fundamental to governing legacy technology.
Known Exposure Changes the Accountability Question
Unknown vulnerabilities are difficult to govern.
Known vulnerabilities are different.
Once an organization knows that a critical system is internet-exposed—and once authoritative guidance identifies that exposure as a meaningful security risk—the accountability structure changes.
Leadership should be able to answer:
Who owns the exposed asset?
Who owns the associated cyber risk?
When was the exposure identified?
What remediation options were evaluated?
What operational constraints prevent remediation?
What compensating controls are in place?
Who authorized continued operation?
When will the decision be reconsidered?
How is the residual risk being monitored?
And, for sufficiently consequential exposure:
Does the appropriate governing authority know?
These questions do not require directors to manage firewalls, cellular modems or PLC configurations.
They require management to demonstrate that known risk has an owner and a decision path.
Small Utilities Create a Difficult Governance Reality
The water sector presents an especially difficult version of this problem.
Many U.S. water and wastewater systems are relatively small organizations.
They may have limited cybersecurity personnel.
They may depend heavily upon vendors.
Their operational technology may be old.
Replacement cycles can be measured in decades.
Budgets are constrained.
Security modernization competes with infrastructure maintenance, regulatory requirements and the basic responsibility to provide reliable water service.
That context matters.
It would be easy to look at an internet-exposed PLC and conclude that someone simply failed to implement obvious cybersecurity practices.
Reality is often more complicated.
The question is not whether every small utility can build the cybersecurity program of a large financial institution.
It cannot.
The governance question is whether limited resources are causing critical cyber risks to remain invisible, unowned or indefinitely deferred.
Resource constraints do not eliminate governance.
They make governance more important.
When everything cannot be fixed, leadership must know what matters most.
Critical Infrastructure Requires Risk Prioritization
This is where cybersecurity governance becomes especially important.
An organization with limited resources cannot remediate every weakness simultaneously.
It therefore needs a defensible prioritization process.
For operational technology, that process should consider more than conventional vulnerability severity.
A useful decision chain might include:
Asset Criticality → Internet Exposure → Operational Consequence → Exploitability → Existing Controls → Remediation Feasibility → Residual Risk
Consider two vulnerabilities.
One exists on an internal administrative workstation.
The other exists on an internet-accessible controller capable of affecting a physical process.
Even if their conventional technical severity scores were similar, their governance significance may be very different.
Cyber risk prioritization must account for consequence.
In critical infrastructure, consequence can include:
Loss of operational control.
Service interruption.
Public safety impacts.
Environmental effects.
Equipment damage.
Manual operating requirements.
Loss of public confidence.
That is why OT cybersecurity cannot be governed solely through vulnerability counts.
Leadership needs to understand what the vulnerable system actually does.
The Board-Level Question Is Not “How Many Vulnerabilities Do We Have?”
Boards frequently receive cybersecurity metrics.
Number of vulnerabilities.
Number of critical findings.
Patch compliance.
Mean time to remediation.
Security incidents.
Phishing results.
Those metrics can be useful.
But they can also obscure the risks that matter most.
A board does not necessarily need to know how many PLCs exist across an enterprise.
It should care whether management can identify critical systems whose compromise could materially affect operations, safety or essential services.
A more useful question is:
Do we have any known critical cyber exposures that management has chosen not to remediate?
Then:
Who owns the risk?
Why does the exposure remain?
What compensating controls exist?
Who approved the exception?
When does the exception expire?
What would cause us to reconsider the decision?
Those questions move the discussion from vulnerability management to risk governance.
Exceptions Need Expiration Dates
One of the simplest governance improvements organizations can make is to stop treating security exceptions as permanent decisions.
Suppose an exposed operational system cannot be immediately isolated because doing so would interfere with remote maintenance.
Management approves continued operation while a secure remote-access architecture is implemented.
That may be reasonable.
But the exception should create obligations.
Exception → Risk Owner → Compensating Controls → Expiration Date → Review → Remediation or Reauthorization
Without an expiration date, temporary risk acceptance can quietly become permanent architecture.
Without a named owner, nobody is responsible for revisiting the decision.
Without compensating controls, the organization is not managing residual risk.
Without verification, leadership does not know whether remediation actually occurred.
Good governance does not eliminate exceptions.
It prevents exceptions from disappearing into the operating environment.
Evidence Changes the Conversation
There is also an evidentiary dimension.
Imagine that a water utility experiences a serious cyber incident involving an internet-exposed controller.
Investigators subsequently discover that the exposure had been known for a year.
The governance questions become immediate.
When was it identified?
Who knew?
What was recommended?
Was remediation requested?
Was funding available?
Was remediation rejected?
Who rejected it?
Was an exception approved?
Were compensating controls implemented?
Was the risk escalated?
Was leadership informed?
Those questions create an evidence chain:
Known Exposure → Risk Assessment → Decision → Control → Monitoring → Outcome
If the organization cannot reconstruct that chain, it may be difficult to demonstrate that the risk was actually governed.
This is why evidence matters before the incident.
Documentation should not be created afterward to explain what management believes happened.
The governance process should produce evidence while decisions are being made.
The Governance Test for Known Exposure
Organizations responsible for critical systems should conduct a relatively simple exercise.
Ask for a list of known internet-exposed operational technology.
Not merely vulnerabilities.
Exposures.
Then select the highest-consequence systems and trace each one through the governance process.
For every exposure, determine:
Who owns the asset?
Who owns the risk?
Why is internet access necessary?
Has the architecture been reviewed?
What threat scenarios were considered?
What remediation options exist?
What compensating controls are operating?
Was continued exposure formally approved?
When does that approval expire?
Has remediation been funded?
Who verifies closure?
Then ask one final question:
If this system were compromised tomorrow, could we explain today why it was still exposed?
That question has remarkable clarifying power.
The Governance Takeaway
More than 100 internet-exposed systems in the U.S. water and wastewater sector were targeted in a single month.
That scale deserves attention.
But the deeper lesson is not that PLCs are vulnerable.
We already know that operational technology exposed directly to the internet can create significant risk.
The more important question is what happens after an organization knows.
A vulnerability can begin as a technical condition.
Continued exposure becomes a management decision.
And continued exposure to consequential risk, particularly after authoritative warnings and demonstrated attacks, eventually becomes a governance issue.
The governing principle is straightforward:
Known Exposure → Accountable Decision
If remediation is possible, remediate.
If remediation requires time, establish compensating controls.
If the risk must temporarily remain, identify the owner.
Document the exception.
Set an expiration date.
Monitor the exposure.
Preserve the decision evidence.
Escalate consequential residual risk to the appropriate authority.
Because after the risk is known, “we hadn’t fixed it yet” is not a governance explanation.
The organization should be able to explain why.
More than 100 targeted water systems should therefore prompt a question far beyond the water sector:
What critical cyber exposure does your organization already know about—and who has actually decided that it is acceptable to remain?
