When the SCADA Network Goes Silent: How Water Utilities Can Maintain Operational Visibility During Communications Failures

Why communication loss is more than a network problem and how utilities can prepare to operate when remote sites stop reporting.

By Franklyn C. Adams
Timehri Networks

When a Remote Site Stops Reporting, What Does the Utility Actually Know?

A water utility operator is monitoring several remote pump stations from the central SCADA system. Tank levels are updating, pump statuses are changing, and pressure readings are arriving at expected intervals.

Then one station stops communicating.

The SCADA display continues showing the last reported tank level. The pump status remains unchanged. No new pressure readings arrive.

The operator can see that communication has been lost, but cannot immediately determine whether the pumps are running, whether the tank is filling, or whether the local controller is responding correctly.

This creates an important operational distinction.

Loss of communication does not necessarily mean loss of control. However, loss of communication can mean loss of visibility and that uncertainty must be managed.

For water and wastewater utilities, the consequences depend on how the remote facility was designed, what local automation remains available, and whether personnel have an established method for verifying conditions independently.

Recent federal warnings make this distinction especially relevant. In 2026, the FBI and EPA reported cyberattacks against internet facing programmable logic controllers (PLCs) that caused loss of monitoring and control functionality at water sector facilities.

Although communications failures can occur without malicious activity, utilities must be prepared to distinguish ordinary equipment or network failures from potentially unauthorized changes.

SCADA Communications Are an Operational Dependency

Modern water and wastewater utilities rely on communications networks to connect geographically dispersed facilities.

These connections may use licensed radio systems, cellular networks, fiber optic infrastructure, microwave links, leased circuits, or combinations of several technologies.

A typical remote facility contains a PLC or remote terminal unit (RTU) responsible for collecting field measurements and controlling equipment. The communications system transfers selected information between that controller and the central SCADA environment.

The central SCADA system may provide operators with:

Pump running and fault status.
Tank and reservoir levels.
Wet well levels and lift station conditions.
Flow and pressure measurements.
Valve positions and operating modes.
Alarm conditions and equipment availability.
Remote start, stop, and setpoint commands.

When communications are interrupted, some or all of these capabilities may become unavailable.

However, the effect on the physical process depends on the control architecture.

A pump station configured for autonomous local control may continue operating normally using local level instruments and PLC logic. Another station may depend on commands or setpoints supplied by the central SCADA system.

The first may retain process control but lose centralized visibility. The second may experience a more significant operational disruption.

Utilities should understand these dependencies before a failure occurs.

Figure 1 — What Happens When a Remote SCADA Site Loses Communication?

A Stale Reading Is Not a Current Reading

One of the more concerning conditions during a SCADA communications failure occurs when the human machine interface continues displaying previously received values.

Consider a storage tank whose last reported level was 72 percent.

If the communications link fails, the HMI may continue displaying that value unless the SCADA application is configured to identify stale data.

The actual tank level could be rising or falling while the operator sees an unchanged reading.

This is why utilities should evaluate more than whether a point has a numerical value.

They should determine whether the value is current, valid, and suitable for operational decision making.

A well designed SCADA application should distinguish among:

Valid data: The measurement has been updated within its expected reporting interval.
Stale data: The displayed value has not been refreshed within an acceptable period.
Bad quality data: The value is unavailable, invalid, or otherwise unsuitable for use.
Communication failure: The system has identified a loss of connectivity to the data source.

Where supported by the SCADA platform and communications protocol, timestamps, quality flags, heartbeat signals, and communication status monitoring can help operators distinguish these conditions.

Utilities should also verify that alarm and display configurations make stale or invalid information recognizable.

A frozen value should not be mistaken for a stable process.

Figure 2 — Current Data Versus Stale SCADA Data

Communications Loss Should Trigger an Operational Assessment

When a remote station stops reporting, the utility’s response should begin with understanding the operational consequences rather than immediately attempting to restart communications equipment.

The operator or designated support personnel should determine which facility is affected, when communications were last confirmed, and what functions depend on the unavailable connection.

Questions may include:

Does the remote PLC continue controlling equipment locally?
Are pumps, valves, and protective interlocks designed to operate independently of SCADA communications?
Are local alarms still functional?
Does the facility require remote commands to maintain normal operation?
Are alternative measurements available?
How long can the facility safely operate without centralized visibility?
Is there an approved method for independently verifying operating conditions?

The answers determine whether the event is primarily a monitoring problem or a developing operational emergency.

For example, a remote tank operating under validated local level control may tolerate a temporary communications outage.

A booster station relying on remotely coordinated pressure control may require more immediate intervention.

Similarly, a wastewater lift station with local automatic control may continue pumping, but loss of remote alarms could delay recognition of a pump failure or rising wet well level.

Communications loss procedures should be based on the function of the affected facility, not simply the duration of the network outage.

Maintaining Operations When Centralized Visibility Is Unavailable

Utilities should identify approved alternative methods for determining the condition of critical remote facilities.

These may include local HMI displays, independent instrumentation, alternate telemetry channels, field personnel, and established operational reporting procedures.

For example, when SCADA communications to a storage tank are unavailable, authorized personnel may be dispatched to verify tank level using an independent local indication.

At a pump station, personnel may confirm equipment status, local alarms, and relevant process measurements.

At a wastewater lift station, field personnel may verify wet well conditions and pump availability.

However, these activities require planning.

Field verification procedures should account for site access, personnel safety, communications with the control room, environmental conditions, and the possibility that local electronic indications may also be affected.

Utilities should not assume that manual operation is automatically safe or available.

Manual operation must be supported by documented procedures, appropriate training, functional equipment, and clearly defined operating limits.

Where remote facilities cannot safely operate without centralized communications, the utility should establish approved contingency actions, including alternative operating arrangements, service restrictions, or controlled shutdown where necessary.

Communications Redundancy Must Be Evaluated End to End

Installing a backup communications link may improve availability, but it does not necessarily eliminate the underlying operational dependency.

Consider a pump station with both fiber and cellular communications.

At first glance, the station appears redundant.

However, both links may terminate on the same router, use the same power supply, or depend on the same firewall or upstream network infrastructure.

A failure in that shared component could disable both communications paths.

Utilities should therefore evaluate redundancy across the entire communications architecture.

Table 1 — SCADA Communications Redundancy Assessment

Component	Questions to Consider
Primary communications	What happens when the primary circuit fails?
Secondary communications	Does it use an independent transport path?
Network equipment	Do both paths depend on the same router or switch?
Power	Is backup power available for communications equipment?
Firewall and routing	Are there shared failure points?
SCADA infrastructure	Can the central system receive data through either path?
Local control	Can the facility maintain approved operations if both paths fail?

A redundant network should also be tested.

Failover configurations that have never been exercised may not behave as expected during an actual outage.

Figure 3 — Communications Redundancy: Two Paths, One Hidden Dependency

Could the Communications Failure Be a Cybersecurity Incident?

Not every communications outage is a cybersecurity incident.

Failures may result from damaged fiber, radio interference, carrier outages, failed modems, power problems, configuration errors, or equipment faults.

However, utilities should avoid assuming that every outage is benign.

In July and August 2026, federal agencies warned that malicious actors were accessing exposed PLCs and modifying device configurations.

Reported activity included changes to PLC IP addresses and passwords that prevented operators from accessing equipment and disrupted monitoring or control functions.

This illustrates why communications troubleshooting and cybersecurity investigation sometimes need to proceed together.

Certain conditions should prompt additional scrutiny:

Several unrelated remote sites lose communications unexpectedly.
A PLC or communications device has an unexplained IP address change.
Known credentials no longer work.
Firewall or router configurations change without authorization.
A previously available controller becomes unreachable after an unexpected configuration event.
Logs show unusual external connections or unauthorized administrative activity.
PLC program or configuration integrity cannot be established.

These indicators do not independently prove malicious activity. They justify investigation.

Utilities should coordinate among SCADA engineers, network administrators, cybersecurity personnel, and operations staff before making changes that could affect an active process.

Where compromise is suspected, preserve relevant evidence while prioritizing the immediate protection of people, equipment, the environment, and essential services.

The FBI and EPA recommend reviewing connected equipment, including cellular modems, HMIs, and workstations, when investigating suspicious activity involving exposed PLCs.

Building a Communications Loss Response Procedure

A practical communications loss procedure should define responsibilities and decision points before an incident occurs.

At minimum, it should establish how personnel identify the affected facility, assess operational impact, verify process conditions, and determine the appropriate response.

The procedure should also identify the personnel authorized to approve operational changes.

For example, a network technician may be authorized to troubleshoot a communications circuit but not to change a PLC operating mode or isolate equipment supporting a running process.

Similarly, a cybersecurity analyst may identify suspicious traffic but require coordination with operations before blocking communications to a critical site.

Clear responsibilities reduce the possibility that well intentioned troubleshooting creates additional disruption.

Figure 4 — SCADA Communications Loss Response Workflow

Test the Failure Before It Happens

Communications loss procedures should be exercised under controlled conditions.

A utility may have backup communications, local PLC control, and manual operating procedures documented, but that does not establish whether they will function together during a real outage.

Exercises should answer practical questions.

Can operators identify stale data? Do communication alarms activate as intended? Does the remote PLC maintain its approved operating mode? Can field personnel independently verify process conditions? Are escalation procedures understood?

Testing should also evaluate restoration.

When communications return, utilities should verify that SCADA values are updating correctly, alarms are functioning, and any buffered data or pending commands are handled appropriately.

Utilities should also verify that commands issued during the outage cannot execute unexpectedly when communications are restored, particularly where store-and-forward mechanisms, queued commands, or automatic control synchronization are used.

Automatic restoration of communications should not be assumed to mean that every system has returned to its intended operating state.

Exercises involving live equipment should be approved by operations and engineering personnel, with defined safety controls and rollback procedures.

Five Actions Water Utilities Can Take Now

Identify critical communications dependencies. Document which facilities rely on central SCADA communications for monitoring, control, alarms, or operating coordination.
Verify stale data handling. Confirm that HMIs, alarms, and historian systems distinguish current measurements from unavailable or outdated information.
Review local operating capability. Determine which facilities can continue approved operations independently and which require additional safeguards.
Evaluate communications redundancy. Identify shared routers, power supplies, network paths, and other common failure points.
Exercise communications loss procedures. Test detection, escalation, independent verification, operational decision making, and controlled restoration.

Questions Utility Leadership Should Ask

A communications failure is not simply a matter of whether the network team can restore a connection.

Leadership should understand the operational exposure created when visibility is lost.

Consider these questions:

If our central SCADA system stopped receiving data from several remote facilities today, how would operators know whether those facilities were operating safely?

Which facilities could continue operating autonomously, and for how long?

Would operators recognize stale data before making a control decision?

Do we have independent methods to verify critical process conditions?

Have our backup communications paths been tested under realistic failure conditions?

Could our operations, engineering, and cybersecurity teams distinguish an ordinary communications outage from a potentially malicious configuration change?

If the answers are uncertain, the utility may have a communications resilience gap that deserves attention.

The Operational Perspective

Communications networks have become essential components of modern water and wastewater operations.

They allow utilities to coordinate geographically dispersed facilities, monitor process conditions, respond to alarms, and make informed operating decisions.

But the availability of a communications link should not be confused with the availability of the physical process.

A remote station may continue functioning while the control room loses visibility.

Conversely, a communications failure may interrupt a control dependency that is necessary for continued operation.

Utilities should understand both possibilities.

The objective is not simply to restore connectivity as quickly as possible.

It is to maintain safe and reliable operations while communications are unavailable, recognize when operating limits are approaching, and restore centralized monitoring without introducing additional risk.

A resilient SCADA environment is not one that never loses communication. It is one in which the utility understands what happens when communication is lost—and has prepared accordingly.

Sources & Further Reading

About Timehri Networks

Timehri Networks helps water and wastewater utilities and other critical infrastructure organizations strengthen OT/SCADA cybersecurity through practical architecture assessments, network segmentation reviews, secure remote access evaluations, monitoring strategies, and operational resilience planning.

Our approach recognizes that cybersecurity controls must support the reliability, safety, and continuity of the physical processes they protect.

Securing Operations. Strengthening Communities.