When digital connectivity touches the physical process
Modern water and wastewater plants are monitored through PLCs, process control systems, sensors and operator interfaces. Remote access can shorten downtime, bring specialists in faster and simplify diagnosis across distributed plants. The same connection can become a risk, however, if control components are directly accessible from the internet or access is not adequately separated, limited and logged.
On 1 October 2026, the US National Institute of Standards and Technology, NIST, discussed recent attacks on water and wastewater systems. According to its technical article, attackers targeted internet-facing programmable logic controllers. Among other things, they attempted to change settings, restrict monitoring and control capabilities and disrupt operations.
The example comes from the United States. It is not evidence of a specific attack on a European or ROTREAT plant. Nevertheless, the technical lesson is transferable: a connection to operational technology must not be judged solely on whether it works. It must be designed so that only authorised access is possible, its effects remain limited and operation can be safely continued or restored after an incident.
OT is not just another office computer
In conventional information technology, confidentiality and data integrity are often primary concerns. In operational technology, or OT, software controls real processes. An incorrect setpoint change can affect pumps, valves, dosing or cleaning sequences. Availability and process safety therefore carry particular weight.
Water plants also have long life cycles. Controllers and field devices often remain in service far longer than office hardware. Not every device supports modern security functions. Updates must be coordinated with process availability, manufacturer approvals and possible effects on control.
This does not mean abandoning digitalisation. It calls for a different planning approach. Remote access is treated as a distinct operating scenario with defined risks, roles and technical layers of protection.
Step one: Know which components are present
NIST stresses that operators can protect only what they know. A sound asset inventory therefore includes more than PLCs and operator panels. It also covers engineering workstations, routers, mobile communications devices, remote terminal units, network-connected instruments, virtual systems, cloud services and external maintenance access points.
For every asset, at least its function, location, responsible party, network connection, software or firmware version and necessary communication relationships should be documented. Equally important is whether a device can be reached from a network managed by someone else.
The inventory is not a one-off handover document. Changes to control systems, networks or remote maintenance must be recorded traceably. Otherwise, every temporary connection creates a blind spot.
Direct internet access to a PLC is not a maintenance strategy
NIST SP 1800-45 describes several reference architectures for secure remote access in water and wastewater systems. A shared principle is not to route access directly to a control device. The connection first terminates in a protected network zone. A separate, controlled session into OT is then established from there.
Depending on size and risk profile, such an architecture may include firewalls, a demilitarised zone, a remote access server or a specially protected jump server. The product name is not what matters. What matters is that only necessary networks, ports and protocols are permitted and that operational technology does not appear as a publicly accessible endpoint.
A cloud solution can also be part of a secure concept. In that case, contracts, responsibilities, end-to-end encryption, access control, logging, vulnerability management and procedures for a service outage must be clarified. Outsourcing a function does not automatically outsource the operator's responsibility.
Identity and permissions must match the maintenance task
A shared maintenance account used by several people makes traceability harder. Individual accounts with a second authentication factor are preferable. Roles and permissions should be limited to the specific task.
An external service technician does not automatically need permanent access to every part of the plant. Time-limited authorisations, the principle of least privilege and a distinction between observation, parameter adjustment and programming are useful. Particularly critical changes may require additional local or organisational approval.
When personnel change, a project ends or a maintenance contract expires, permissions must be reliably withdrawn. This seemingly administrative task is part of technical security.
Logging makes remote maintenance verifiable
A secure access system should record who logged in and when, which system was accessed and which security-relevant events occurred. Depending on the architecture, session information or file transfers may also be recorded.
Logs are useful only if they are protected, can be analysed and are assigned to a responsible party. A large volume of unreviewed log data is no substitute for monitoring. Operators should specify which events trigger an alert, who assesses it and how to respond to suspected incidents.
File transfers into OT deserve particular attention. Programs, updates and configuration files should come from an authorised source, be checked before import and be version-controlled. After a change, there must be a defined way back to the last working configuration.
Fallback operation and recovery belong in the plan
No system can guarantee complete security. Response and restart must therefore be part of the architecture. Operators should know which processes continue locally if the remote connection fails, what manual operation is possible and how long the plant can be operated safely without external support.
A sound concept includes backed-up configurations for PLCs, operator interfaces and relevant network components. Recovery should not only be documented but also tested under controlled conditions. A backup becomes valuable only when it is available, unchanged and can actually be restored.
Alarm channels must also be able to work without the affected connection. If monitoring, maintenance access and notification depend entirely on the same external service, a single outage can affect several layers of protection at once.
NIS2 makes cybersecurity a management responsibility
The European NIS2 Directive includes drinking water and wastewater among sectors of high criticality. Whether a particular organisation is subject to specific national obligations depends on jurisdiction, size, activity and other criteria and must be assessed separately.
In its May 2026 NIS360 report, the EU Agency for Cybersecurity, ENISA, placed drinking water and wastewater in a risk zone because their assessed cyber maturity lagged behind the sectors' criticality. Among other issues, ENISA identifies resource shortages, inconsistent implementation and gaps in the use of existing guidance.
This assessment does not replace legal advice. It does, however, make clear that remote maintenance should not be left solely to the IT department or the supplier. Management, operations, process engineering, automation and IT must jointly define responsibilities and accepted risks.
Security must be visible in tendering and acceptance testing
Many later weaknesses do not originate during operation. They are built into the project through unclear requirements. A tender for an automated water plant should therefore also describe the OT interfaces:
- Which remote access connections are actually required?
- Who provides infrastructure and identity management?
- Which roles, approvals and time limits apply?
- Where are logs stored and who analyses them?
- How are software, configurations and changes documented?
- Which local operating functions remain available if the connection or service fails?
- Which documentation and recovery tests form part of acceptance?
Alongside process engineering and electrical functions, factory acceptance testing can also check selected digital operating scenarios. These include permitted remote access, rejected access, logging and operation with the external connection disconnected. The specific depth of testing depends on the plant and its risk assessment.
The ROTREAT connection
ROTREAT builds modular wastewater treatment plants with automation, instrumentation and control, and factory acceptance testing. During project planning, operating requirements for remote monitoring and service must be clarified early so that control cabinets, network components, operation and interfaces can be implemented consistently.
ROTREAT is not a provider of comprehensive cybersecurity consulting and does not replace operator obligations or specialist OT security planning. Plant construction can, however, support the necessary foundations: documented components, clearly defined interfaces, traceable access requirements and an acceptance concept that takes safe plant operation into account.
Next steps
Are you planning an automated water treatment plant or one with remote maintenance access? Define the necessary access, operating roles and outage scenarios together with those responsible for your IT and OT security. ROTREAT can incorporate these requirements into interface and acceptance planning for the process plant.