Map every connection to an OT boundary you can actually defend
A boundary is only useful if it can be enforced under pressure. In a water sector network, that usually means mapping each remote access route, vendor link and support path to a named OT zone with a clear owner, fixed trust rules and a known failure mode. If a connection cannot be traced to a boundary, it is usually just permission with a cable attached.
Trace remote access into the control plane, not just the IT side
Remote access often looks tidy from the corporate network and messy once it reaches OT. The useful question is not who can log in, but where that session lands, what systems it can touch and how it is cut off when the work ends. A jump host, dedicated bastion or controlled support gateway gives more shape than a direct path into engineering workstations or control servers.
The access path should end at the control plane that actually matters, not somewhere vague on the IT side of the house. That means separate authentication, separate session records and separate approval for high-risk actions such as firmware work, PLC changes or live support during an incident. If vendor access shares the same route as internal admin access, incident handling becomes a guessing game with passwords.
Keep legacy protocols inside tightly scoped trust zones
Legacy industrial control systems rarely speak in modern security patterns. Older protocols often lack strong authentication, so the practical control is not to trust them less in theory, but to confine them more tightly in network segmentation. Put them in small zones with explicit peers, narrow firewall rules and no casual east-west movement.
That works only if the trust zone is boringly specific. A protocol that has to reach one historian or one controller should not also see maintenance laptops, file shares and spare engineering gear. The tighter the scope, the less likely a scan, misroute or compromised account can roam across the plant. Old kit keeps working, but it stops being allowed to wander.
Centralise access decisions without flattening the plant
Central access control helps when it decides who gets in and what path they take. It fails when it turns every OT system into one flat policy blob with the same rules for operators, vendors and maintenance staff. Water sector networks need central visibility, but the plant still needs segmented paths and local boundaries.
Use segmented paths for operators, vendors and maintenance windows
Operators need predictable access to run the plant. Vendors need limited access for support. Maintenance needs short-lived access that opens for a task and closes when the work is done. Those three cases should not share the same route or the same standing permission set.
A maintenance window should look like a temporary exception, not a permanent convenience. Session recording, time limits and explicit approval matter because remote support tends to outlive the job that justified it. If access is open-ended, the only thing that gets reviewed later is the incident log.
Tighten firewall policy around fixed services and known flows
Firewall policy in OT works best when it follows fixed services and known flows. Water sector control networks usually have fewer legitimate paths than the diagrams suggest, which makes broad allow rules look lazy rather than flexible. A good rule set tends to be dull: source, destination, protocol, port and purpose.
The consequence of loose rules is not abstract. One broad exception can expose engineering workstations to historian traffic, vendor support tools or lateral movement from a compromised asset. Keep the policy narrow enough that a change request is visible, then resist the usual pressure to turn a temporary exception into a long-term feature. Most plants already have enough surprises without inventing new ones in the firewall.
Prove the design holds during incidents and routine change
A secure connectivity design only matters if it survives account changes, link failures and support under stress. OT incidents are rarely polite, and routine change often breaks the quiet assumptions hidden in access paths. The test is not whether the diagram looks sensible on paper, but whether the boundary still behaves when someone rotates credentials at 2am.
Test failover, account rotation and remote support under pressure
Failover paths need the same scrutiny as the main route. If the backup link opens a wider trust zone, inherits stale credentials or bypasses logging, it may keep the plant online while quietly tearing the boundary apart. Account rotation should also be tested, because expired vendor credentials during a fault are a common way to discover how much of the support process was improvised.
Remote support deserves pressure testing too. Simulate a live issue, rotate the access account, switch the path, then check that the right person still gets in without opening extra exposure elsewhere. If the process only works when nothing has changed, it is not really a process.
Validate the boundary with monitoring, review and replayable evidence
Monitoring only helps when it shows what crossed the boundary, when and why. In OT, that usually means keeping session records, access logs and firewall events together so the path can be reconstructed after the fact. A tidy audit trail matters more than a pile of alerts nobody wants to read.
Review should be boring and repeatable. Track which remote sessions were opened, which zones were touched and which exceptions were granted for maintenance or incident work. Replayable evidence matters because the hard part is rarely proving that access existed. The hard part is proving it stayed inside the boundary you said you had.
