A water operator notices a remote session on an engineering workstation. Nobody on shift recognizes the account. A vendor sometimes connects after hours, but the maintenance calendar is blank.
The temptation is to pull a cable, power down the workstation, or start changing passwords. Any of those actions might be appropriate later. In the first few minutes, though, a rushed IT-style response can remove visibility or disrupt a process that operators need to keep water service safe.
CISA reported in July 2026 that threat actors were targeting programmable logic controllers at water and wastewater systems, including entities of all sizes.[1] The alert also warned that cellular modems installed by operators, vendors, or integrators may be missing from normal records and external scans.[1] An unknown session deserves attention, but attention is not the same as panic.
This procedure is a tabletop starting point, not a command to manipulate a live control system. Site operators and the person with engineering authority decide what can be isolated, stopped, or changed. Follow the utility’s emergency response plan, incident response plan, permits, safety procedures, vendor instructions, and reporting duties.
Minutes 0-5: verify the process before touching the connection
The person who sees the session should note the time, screen, displayed account, remote-access method, and affected asset. If policy allows, capture a screenshot without closing windows or selecting unfamiliar controls. Call the control-room or shift lead through a known number.
Start with operating conditions:
- Is treatment within its approved operating range?
- Are alarms, pumps, chemical feed, levels, pressure, and other locally defined indicators behaving as expected?
- Is an operator already responding to a process problem?
- Would losing this workstation or connection interfere with visibility or control?
This order matters. NIST’s OT security guidance treats performance, reliability, and safety as distinct requirements of operational technology.[4] CISA likewise says OT incident plans need safety and containment considerations that differ from ordinary IT priorities.[3]
Do not ask the help desk to reboot the workstation or disable a network port before an authorized operator explains the operational effect. Do not use the suspicious session to send a message to whoever may be connected. Keep the observation channel open while the team establishes who has authority.
Minutes 5-10: check whether the session is expected
The shift lead should contact the named IT or security responder and the OT or engineering owner. In a small utility, one person may fill two roles, but both questions still need answers: “Is this access authorized?” and “What would containment do to the process?”
Check records that can confirm the session without relying on the session itself:
- approved maintenance windows and change tickets;
- the vendor contact list and on-call schedule;
- the remote-access gateway, VPN, or jump-host log;
- the asset inventory and current network diagram;
- recent work orders involving modems, routers, engineering laptops, or PLCs.
Call the vendor through a number already in the utility’s records. Ask for the technician’s name, account, connection time, reason for access, and approved work order. A caller who knows a project name still has to match the utility’s authorization record.
If the session is legitimate but undocumented, end the investigation only after the owner records the access and confirms what changed. “It was probably the integrator” is not a closure note.
Minutes 10-20: choose containment with the operator
If nobody can validate the session, treat it as a suspected incident. The incident lead should state the containment goal in plain language, such as preventing new remote commands while retaining local monitoring and safe manual control.
Possible actions include disabling a remote-access account, ending a session at the gateway, blocking a source address, isolating an engineering workstation, or disconnecting an exposed device from the internet. The right choice depends on the utility’s design. Test or approve the action with the operator and system owner before applying it to production.
CISA recommends that essential OT remote access pass through a VPN or gateway rather than connect directly to a PLC. Its broader OT guidance calls for private connectivity where possible, phishing-resistant multifactor authentication, least-privilege access, documented connections, and disabled dormant accounts.[1][2]
Containment should preserve a safe way to operate. Before cutting a path, confirm whether staff can monitor the process locally, whether manual control is available, who is qualified to use it, and how long that mode can be sustained. CISA recommends practicing manual OT operation as part of incident readiness.[2]
Keep engineering authority separate from cyber coordination. IT can provide logs and disable enterprise accounts. Security can preserve evidence and coordinate reporting. Operations decides whether the process can tolerate a control or connectivity change. A vendor can explain product behavior, but the utility remains responsible for authorizing work on its system.
Minutes 20-30: preserve a useful record and set the next decision
Create a short incident log outside the affected system. Record observations, calls, decisions, commands issued, account or connection changes, process effects, and the name of each decision maker. Use synchronized times when possible. Do not copy passwords, sensitive network diagrams, or live access details into an ordinary email thread.
Preserve available evidence without running unfamiliar tools on control equipment. Useful items may include remote-access and authentication logs, firewall events, workstation alerts, change records, photographs of displayed information, and operator notes about process behavior. If collection could burden a controller, change timing, or interfere with a vendor warranty, stop and get engineering and forensic guidance.
The 30-minute mark needs a decision, not a declaration that the incident is over. The incident lead and operator should agree on:
- the current operating condition and safety concerns;
- which access paths are blocked, monitored, or still required;
- who will investigate the account, device, and source of the connection;
- whether credentials or trusted vendor channels need to change;
- when leaders, counsel, insurers, regulators, law enforcement, or government support contacts must be notified.
CISA asks water-sector organizations reporting an incident to provide details such as date, time, location, activity, affected people, equipment, and a designated contact when that information is available.[1] Prepare those facts, but follow the utility’s legal and regulatory decision process rather than assuming one public checklist covers every obligation.
Turn the procedure into a tabletop
Do not wait for a live session to discover that the vendor list is stale or that nobody knows what a cellular modem supports.
Put a screenshot of a fictional remote session in front of operations, IT, management, and the system integrator. Ask each person what they would check, who can approve containment, and how the utility would continue safe service if remote connectivity were removed. Then add one complication: the vendor denies connecting, but the process still looks normal.
The exercise should end with a few concrete corrections. Name the owner of each remote path. Add missing modems and gateways to the inventory. Define an approval window. Confirm where logs live. Write down the operational conditions that must be checked before isolation. Test the manual or degraded mode under site-approved procedures.
An unknown session is both a cyber question and an operations question. The first 30 minutes should keep those conversations together long enough to make a safe, informed decision.
For practical guidance on cyber risk and safer AI use, subscribe to Cyber & AI Insights.
If your utility wants an independent facilitator for an OT incident-response tabletop, schedule a conversation with Your Data Guardian.