The mistake is treating OT like IT. A utility that applies its corporate security playbook to the control network will eventually push a patch or a scan that takes a pump offline. The controls are not wrong. They are being applied to a system with inverted priorities.

IT and OT are not the same problem

IT systems manage information. The classic priority order is confidentiality, then integrity, then availability. Losing an hour of email is survivable; leaking customer data is not.

OT, or operational technology, controls physical things. Pumps, valves, breakers, chlorination. The priority order inverts completely: availability and safety first, everything else after. A control system that stops responding is not an inconvenience, it is a potential public health event.

IT networkOT / SCADA network
First priorityConfidentialityAvailability and safety
Typical asset life3–5 years10–25 years
PatchingMonthly, often automatedVendor-certified, scheduled around outages
Downtime toleranceHoursOften minutes, sometimes none
Active scanningRoutineCan crash legacy controllers
OwnershipIT departmentOperations and engineering
Good to know: the ownership row is the one that causes the most trouble. In most utilities the OT network belongs to operations, not IT, and the two groups have different vendors, different budgets and often different views of who is responsible for security. Fixing that relationship usually matters more than any product.

How utilities protect SCADA networks

Five foundations, in the order they usually deliver the most risk reduction per dollar.

  1. Segmentation. A defined, enforced boundary between the corporate network and the control network, with a small number of documented and monitored crossings. Not a flat network with a firewall bolted to one edge.
  2. Remote access control. Vendor and engineer access through a controlled path with multi-factor authentication, session recording and time-bounded approval. Standing vendor VPN accounts are the most common serious finding.
  3. Passive monitoring. Visibility into control traffic using techniques that observe rather than probe, because active scanning can knock over legacy controllers.
  4. Asset inventory. You cannot protect a controller nobody has written down. This is unglamorous and it is where every real programme starts.
  5. Tested recovery. Configuration backups for controllers and HMIs, and a restoration procedure somebody has actually rehearsed.

Why patching works differently

Control systems frequently run vendor-certified software where an unapproved patch voids support or risks an unplanned trip. OT patching is scheduled around maintenance windows, tested against vendor guidance, and where patching is genuinely not viable, replaced with compensating controls: tighter segmentation, stricter access, closer monitoring. That is a legitimate engineering answer, not a shortcut.

Key takeaways
  • OT inverts IT's priorities: availability and safety come first.
  • Segmentation and controlled remote access buy more risk reduction than any tool purchase.
  • Never run active scans against legacy control networks without vendor guidance.
  • Start with an asset inventory and a diagram of every IT-to-OT path, including vendor access.

Where to start if you have never assessed the OT side

Begin with two documents rather than a purchase. First, an asset inventory of everything on the control network. Second, a network diagram showing every path between IT and OT, including the ones nobody talks about: the engineer's laptop that touches both, the vendor's remote support tunnel, the historian that reaches into the corporate reporting environment.

Nearly every utility we assess finds at least one connection nobody had documented. That discovery, on its own, is usually worth the exercise.

The question is rarely whether the control network is connected to the corporate network. It is whether anyone can draw the connections from memory.

Municipal utilities have a particular problem

Small municipal water and electric utilities carry the same operational risk as large ones with a fraction of the staff. Often a single person covers both IT and OT, procurement runs through a council with a public budget cycle, and the SCADA vendor is the only party who fully understands the system.

That is a solvable position, but it does not solve itself, and it rarely survives that person retiring. Our work with utilities and municipalities is built around exactly this constraint.

Frequently asked questions

What is the difference between IT and OT?

IT systems manage information and prioritise confidentiality, integrity and availability in that order. OT controls physical processes and reverses those priorities: availability and safety come first. That inversion is why IT security practices frequently cannot be applied unchanged to an OT network.

How do utilities protect SCADA networks?

Network segmentation between IT and OT, strictly controlled remote access with multi-factor authentication, passive monitoring that does not interfere with control traffic, a documented asset inventory, and a tested recovery plan for control systems. Patching runs on a slower, more deliberate cycle than on the IT side.

Can you patch SCADA systems the same way as IT systems?

No. Control systems often run vendor-certified software where an unapproved patch voids support or risks an unplanned outage. OT patching is scheduled around maintenance windows and tested against vendor guidance, with compensating controls used where patching is not viable.

Where should a small utility start with OT security?

An asset inventory and a network diagram showing every path between IT and OT, including vendor remote access. Most utilities discover connections nobody documented. Segmentation and remote access control usually deliver more risk reduction per dollar than any tool purchase.

Keep exploring

Ready for a clear path forward?

Start with a Navigate Clarity Conversation. A free 30 minute review of where you stand and what to do first.

Start with a Clarity Conversation