OT/IT Network Segmentation for Utilities: A Practical Starting Architecture

Information technology handles email, billing, customer systems, and enterprise applications. Operational technology handles the physical process: SCADA masters, remote terminal units, protection relays, distribution management systems, and the field devices that open and close switches. Utilities historically ran these as separate networks, but over the last fifteen years the two have converged — remote vendor support, centralized historian data, and the savings of shared infrastructure. The result at many utilities is a flat network where a compromised laptop in billing has a viable path to a control-system historian, and from there to the OT LAN.

That path is exactly what ransomware operators look for. Incidents across the energy and water sectors have followed the same pattern: initial access through a phished IT account, lateral movement across an unsegmented network, and either data theft or a forced OT shutdown once the intrusion is found — even when the ransomware never touches a control system. The operational impact often comes from the utility's own scramble to isolate OT manually once it realizes the boundary doesn't exist.

Regulatory pressure reinforces this but doesn't fully cover it. Bulk electric utilities under NERC CIP carry mandated segmentation and monitoring requirements for high- and medium-impact assets. Municipal utilities, water and wastewater systems, and smaller electric cooperatives often fall outside that mandate entirely — which is precisely why deliberate, voluntary segmentation matters most for them. Nobody will require it on a deadline; the exposure exists either way.

Control-system availability requirements are stricter than almost anything on the IT side — a firewall rule that blocks a legitimate DNP3 poll can trip an alarm or leave an operator blind to a breaker state. Segmentation work in OT can't follow the IT playbook of deploying an enforcement device and iterating on the rule set in production. The sequence has to be passive first, enforced second.

Start with a network tap or span port feeding a passive monitoring tool that builds an asset inventory and a protocol baseline — what's talking to what, over which protocol, on what schedule. Most utilities are surprised by what shows up: legacy engineering workstations running unsupported operating systems, vendor remote-access tools nobody remembers installing, historian jobs polling far more RTUs than documented. You cannot write an accurate allow-list for traffic you haven't observed.

Then move enforcement in during a planned outage window, allow-listing only the protocols and endpoints the baseline confirmed — DNP3, Modbus TCP, IEC 61850 GOOSE/MMS, or vendor historian traffic, each scoped to specific source and destination pairs rather than broad subnet rules. Keep redundant paths for protection functions intact throughout; segmentation must never introduce a single point of failure into a function that trips a breaker for safety.

The minimum-viable architecture is a foundation, not an endpoint. Once the Level 3.5 boundary is live and monitored, later cycles typically expand segmentation to individual substations or generation sites, each with its own enforced zone rather than one flat OT network behind the first DMZ. Centralized log aggregation across IT and OT tooling — without merging the identity systems — usually comes next, giving a security team one place to correlate an IT phishing alert with an OT anomaly instead of two disconnected consoles.

Identity convergence — a single directory governing access to both domains with role-based, least-privilege scoping — is realistically a year two or three initiative; rushing it is how utilities end up granting an IT service account standing access to a control network to hit a deadline. Sequencing matters more than speed: each phase should leave the utility measurably safer than the one before it, not just further along a roadmap.