They should isolate the affected system immediately using pretested containment policies, then keep the rest of the water operation running. The response should assume the attack may have started through a workstation, gateway, or remote access path. Containment is not just about blocking the bad device. It is about preventing one compromised connection from spreading into the broader OT environment.
What containment means once a PLC or gateway is already compromised
Once compromise is confirmed or strongly suspected, the first job is to stop the device from acting as a bridge, not to prove every detail of the intrusion before you move. In OT environments, that means treating the PLC or gateway as a potential propagation point, a command source, and a trust boundary failure all at once. The operational goal is to narrow the blast radius while preserving enough plant function to keep the process safe and stable.
That usually requires isolating the affected asset with pretested containment paths, then verifying which adjacent systems still need to communicate for safe operation. If the compromise sits on a gateway, the path may be more dangerous than the device itself because it can mediate multiple zones. If the compromise sits on a PLC, the concern is not only loss of control, but also unauthorised commands, altered logic, or hidden dependencies that keep the rest of the operation exposed.
- Cut the compromised device off from nonessential lateral paths first.
- Preserve only the communications needed for safe process continuity.
- Assume adjacent engineering, remote access, or workstation paths may also need review.
The containment choice should be made against the plant topology, not just against the infected host. A gateway that is still able to route, translate, or broker sessions can continue to spread risk even if the original attacker foothold appears limited.
How to keep the operation running without widening the blast radius
Teams should separate safety-critical continuity from convenience traffic. That means identifying which functions are essential for stable water treatment or distribution, then keeping only those paths alive through the cleanest route available. The question is not whether the compromised device is still online, but whether the remaining control structure can operate without trusting that device.
This is where preplanning matters. If containment depends on improvised network changes during an incident, operators often preserve too much connectivity out of fear of interrupting service. A better pattern is to have segmented fallback modes, known-good manual procedures, and clear operator authority for temporary isolation decisions. When those are in place, containment can be assertive without forcing a full shutdown.
- Use the cleanest alternate control path, not the most convenient one.
- Validate that operator overrides do not silently re-open the compromised route.
- Keep evidence of the original state before making disruptive changes.
For teams that need a deeper incident-response structure, FIRST incident response standards are useful for coordinating containment, escalation, and handoff discipline across teams. For a control-focused view of least-privilege containment and segmenting access paths, NIST Cybersecurity Framework 2.0 remains a practical baseline.
Risk and Threat Considerations
The main risk is that a compromised PLC or gateway is rarely just a single-device problem. It can become a pivot into adjacent controllers, engineering workstations, remote access infrastructure, or vendor pathways, especially when the device still holds trusted connectivity into the OT environment. In water operations, that creates both availability risk and control-integrity risk, because unsafe trust assumptions can persist even after the initial compromise is noticed.
Failure mechanism: The device continues to mediate trusted sessions, forward traffic, or accept management commands after compromise, allowing the attacker to spread laterally, alter logic, or maintain persistence through legitimate-looking control paths.
Impact: Operators can lose confidence in process state, lose control of related systems, or be forced into a broader shutdown if containment was delayed or incomplete.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | RS.MA — Response Management | Compromised OT devices need coordinated containment and recovery actions. |
| PR.AC — Identity Management, Authentication and Access Control | Containment depends on removing unsafe trust paths and limiting access. | |
| Recommendation — Coordinate isolation and service continuity actions through your response plan. Restrict access paths so the compromised device cannot retain trusted connectivity. | ||
| CIS Controls v8 | 13 — Network Monitoring and Defense | Segmentation and boundary control are central when a PLC or gateway is compromised. |
| 17 — Incident Response Management | Pretested containment policies are an incident response requirement in active compromise. | |
| Recommendation — Segment OT zones and block lateral movement across boundary devices. Use preapproved containment playbooks to isolate the asset without stopping the plant. | ||
| NIST Zero Trust (SP 800-207) | 5 — Policy Decision and Enforcement | Zero trust enforcement helps prevent a compromised device from continuing to influence access. |
| Recommendation — Enforce policy decisions so compromised paths cannot keep implicit trust. | ||
| MITRE ATT&CK | T1021 — Remote Services | Compromised gateways and workstations often enable lateral movement over trusted remote paths. |
| T1611 — Escape to Host | If compromise begins in a connected component, attackers may extend control into the host environment. | |
| Recommendation — Hunt and disable abused remote paths that can bridge into OT zones. Check whether the compromise can be used to escape into adjacent systems. | ||
Practitioner Guidance
What to prioritise: Isolate the compromised asset in a way that preserves safe operation first, then work outward from the suspected pivot point. If the device is a gateway, treat every dependent connection as suspect until you can prove it is not part of the propagation path.
What to verify: Confirm that the containment method actually blocks both inbound management access and outbound lateral movement. A common mistake is disabling one interface or account while leaving another trusted route open through the same box.
Practitioner takeaway: The right response is not “take the bad device offline at any cost,” but “remove the device’s trust without collapsing the process it supports.” That distinction is what keeps containment effective in OT.
Related resources from NHI Mgmt Group
- How do security teams know whether a patched appliance was already compromised?
- How should security teams respond when a public exploit has already compromised internet exposed on-prem software?
- What are the signs that a perimeter mail gateway may already be compromised?
- What should security teams do first when a GitLab server may already be compromised by ransomware or miner activity?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
