Boundary design for water sector OT networks
Secure connectivity principles only work when the boundary is drawn around risk, not around tidy org charts. In water sector operational technology, that boundary sits where safety, reliability, and cyber exposure meet. Push it wider than it needs to be and you inherit extra paths, extra trust, and extra failure modes.
Anchor the OT boundary around safety, not convenience
The OT to IT boundary should be narrow, explicit, and boring in the right places. If a path crosses from enterprise systems into industrial control systems, it needs a clear reason to exist and a clear owner for what happens if it fails. A vague shared connection between layers is where later incident reports start looking familiar.
Access control belongs at the points that actually carry risk, not just at the top of a diagram. That means the handoff into OT, the jump point for maintenance, and any service that can reach control assets directly. A single broad allowance at the edge does little when the useful control point sits three layers further in.
Water sector environments also carry a hard constraint that gets ignored in cleaner designs: safety and continuity come before elegance. A boundary that blocks legitimate plant operation is not secure, it is just broken. The usable design is the one that limits exposure without forcing operators into workarounds that undo the whole thing.
Use network segmentation to limit exposure without breaking operations
Network segmentation needs to separate traffic by function, not by wishful thinking. Control traffic, management traffic, and remote support paths should not share the same open route simply because it is easier to document. Once those paths are mixed, a compromise in one lane becomes a problem in all of them.
Control traffic should be treated as the most constrained path, with the fewest moving parts and the least number of transits. Management traffic can be narrower than full access, but it still needs controls that stop it becoming a back door into control systems. Remote support is the noisiest route of the three, which is exactly why it should be the most tightly fenced.
Legacy protocols need special handling because they often cannot be made chatty in a safe way. They should sit inside contained exceptions, not become the default pattern for new connectivity. If they must remain in use, isolate them, restrict who can reach them, and keep the exception visible so it does not quietly turn into architecture.
Make secure remote access and incident readiness part of the same design
Secure remote access should be designed with the incident path in mind from the start. Centralising connectivity can help when it reduces the number of places that need policy, logging, and control. It becomes a liability when it turns into a single oversized choke point with weak operational ownership.
Logging only helps if the path is usable when something is already going wrong. Test the dump path, not the policy wording. If the route for support, inspection, or containment fails under incident conditions, the nice paper design will not matter much.
For water sector OT, the boundary design has to survive ordinary maintenance and bad days. That means each allowed path should have a reason, a limit, and a fallback when it misbehaves. The cleanest network is the one that still works when the plant is under pressure.
