Water Utility OT Security: How to Evaluate Segmentation Approaches, Vendors, and a Proof of Value

If you are a water or wastewater utility with a shortlist in front of you, this page is the evaluation layer: the part of the problem that starts after you have accepted that segmentation is worth funding and have to decide what to buy.

This page is about method, not a roster. If you are still assembling a shortlist of named vendors, start with our survey of the leading vendors for securing OT and industrial control systems, which covers the market by company. This page picks up afterwards, when you have the names and have to decide between them for a water or wastewater environment.

It gives you three things. A comparison of seven approaches you are likely to be shown, each described by what it does mechanically, where it holds up in a treatment or distribution environment, where it does not, and what it costs to license and to stand up. Fourteen questions written so a procurement officer can send them to every vendor unchanged and compare the answers side by side. And a proof of value protocol with dated stages, acceptance criteria you set rather than the vendor, and a plain account of what the work costs your own staff, which is the line item that routinely goes unbudgeted.

A disclosure you should read before the table. Elisity publishes this page, and Elisity sells identity-based agentless microsegmentation, which is one of the seven approaches compared below. That row carries its own limitations in the same language as every other row: the discovery period required before enforcement, the classification error it most commonly makes, the sites where it observes rather than enforces, and the infrastructure it depends on. The licensing and prerequisites column is filled in for every approach, ours included. If any row reads softer than the others, that’s a defect in this page, and the criteria are still yours to use.

None of the fourteen questions presupposes an architecture. An agent-based product, a firewall, an admission control system, and an identity-based product can each answer all fourteen. What separates them is the answers, given against your asset list and your site list rather than a datasheet.

How Should a Water Utility Evaluate Zero Trust and OT Segmentation Platforms?

Evaluate against your own operating constraints. For a water system the decisive questions are what hardware and firmware enforcement runs on, what addressing changes are required, what share of your assets it can police and by what method, whether policy can be simulated first, what the licensing costs, and what evidence it produces for an EPA assessment.

What Are the Main Approaches to Segmenting a Water Utility Network?

We compared seven options: the five segmentation approaches most water and wastewater utilities will actually be shown, and two adjacent controls that are often confused with segmentation. None of them is universally correct. Each solves a different part of the problem, and most mature programs end up running two or three together. The comparison is organized by what each approach does mechanically, where it holds up in a treatment or distribution environment, where it does not, and what it costs to license and to stand up.

The pattern most water utilities converge on is a firewall boundary between business and process networks, passive OT monitoring for visibility, and one internal enforcement mechanism (VLAN and access control lists at small scale, identity-based policy once the estate spans multiple plants and remote sites with a capable managed hop). Agent-based tools cover the server subset where they can be installed. Unidirectional gateways are reserved for the flows that justify their cost. How those layers are sequenced, and which one gets funded first, is the subject of our longer guide to OT network segmentation.

Fourteen Questions to Ask Any OT Segmentation Vendor

These are written so a utility can hand them to a procurement officer unchanged, and so the answers can be compared across vendors side by side. None of them presupposes an architecture: an agent-based product, a firewall, an admission control system, and an identity-based product can all answer every one of them, and the answers are what tell them apart. Ask for answers against your own asset list and your own site list. Ask any vendor to walk your remote site list and mark which sites they enforce at and which they only observe.

1. What does the product enforce on, and what is the compatibility list for that enforcement point (hardware models and firmware, OS versions, appliance models)? Check that list against your own inventory. What share of your estate does it cover, and what is the plan for everything outside it?
2. What addressing changes does deployment require, and why is each one required? Re-addressing, VLAN redesign, or a routing change may well be justified. The point is to price it and schedule it before you sign, not to discover it during a cutover.
3. What percentage of your asset inventory can it enforce policy on, and by what method? Ask for the number measured against your device list, and ask which method applies to each class of asset: installed agent, existing network infrastructure, inline appliance, or admission control.
4. Can policy be simulated against real observed traffic and reviewed before anything is enforced?
5. How does it classify a device it has never seen before, and what policy applies to that device in the meantime?
6. How does it handle remote pump stations, lift stations, and tank sites on cellular or radio backhaul? Ask specifically which of those sites it enforces at, and which it can only observe.
7. What does a policy decision depend on: installed agent telemetry, passive traffic observation, industrial protocol decoding, directory and asset records, or a combination? What happens to policy quality when that data is incomplete or stale?
8. How is policy authored and maintained across many sites: locally at each site, centrally and distributed, or a mix? What is the ongoing effort to keep it consistent as devices, sites, and staff change?
9. What is the failure mode? If the management plane is unreachable, does enforcement continue, fail open, or fail closed?
10. What evidence does it produce for an AWIA Risk and Resilience Assessment, a state sanitary survey, and a cyber insurance application?
11. What is the rollback path for a policy that blocks something it should not have, and how fast is it?
12. What is the licensing model, and what does it cost at your scale? Ask for the unit of licensing (per device, per host, per site, per sensor, per appliance, per user), whether it is subscription or perpetual, a three-year total priced against your own asset count, and what sits outside the license: hardware, professional services, support tier, training, and the cost of adding a site.
13. What has to already be in place for it to work? Ask for the prerequisite list in writing: specific hardware or firmware, an installed agent, SPAN or tap access, an appliance or sensor per site, a directory, certificate infrastructure, internet reachability, or a cloud service.
14. Where has it been deployed in comparable regulated OT environments, and what did enforcement cover at those sites? Ask for the vendor’s own written classification of your sites as enforce-capable or visibility-only.

How Do You Run a Segmentation Proof of Value in a Water Environment?

A proof of value in a treatment or distribution environment has to run against production conditions. That’s the whole test. Whether the approach survives contact with real process traffic, real maintenance windows, and real operator behavior is what you are trying to find out. Each stage below has an acceptance criterion, and you decide whether it has been met. The water-specific case for doing this work at all, rather than how to test it, is covered in our post on safeguarding water systems.

1. Discovery, weeks 1 to 2. Acceptance: the discovered device count and classification is reconciled against the existing asset register, and every discrepancy is run down to an explanation.
2. Traffic baselining, from week 2 to the end of the declared baseline period. Acceptance: enough observation to cover at least one full operational cycle, including a scheduled maintenance window, a chemical delivery, and any seasonal or storm-driven mode the plant runs. The length required varies by architecture and by plant, so require each vendor to state its own baseline period in writing before the proof of value starts, justify that period against the operational cycle above, and hold it to the number it gave you. Every stage below is dated from the end of that period, so a vendor that declares a shorter baseline finishes sooner and a vendor that declares a longer one does not get to move the finish line later.
3. Policy authoring and simulation, baseline end plus 2 weeks. Acceptance: the simulated deny list is reviewed line by line with operations, and contains nothing a treatment or distribution process depends on.
4. Enforcement at one plant, baseline end plus 2 to 4 weeks. Acceptance: no process interruption, no operator workaround, and no rule exception granted outside the change control process.
5. Expansion to remote sites, baseline end plus 4 weeks onward. Acceptance: every remote site is classified as enforce-capable or visibility-only against the utility’s own site list, and the count of sites actually under enforcement meets a coverage threshold you set in writing before the proof of value starts. Derive that threshold from your own site list rather than from a headline percentage: it should leave no more sites unenforced than you can compensate for with other controls, and you should be able to name those controls site by site. Require the vendor to commit to the number, and require any shortfall to be explained site by site.

What this costs you in staff time. A proof of value is not a vendor-only exercise, and the utility-side effort is the part that routinely goes unbudgeted. Three roles have to be available: network engineering, OT or SCADA operations, and whoever owns identity and directory data. Two variables set the total, and neither is the product. The first is the size of the estate. The second is how accurate your asset register and site list already are before anyone starts. A utility with a current register and a settled site list sits at the low end of everything below. A utility reconciling its inventory for the first time sits above the high end, and that reconciliation is worth doing whichever architecture you end up buying.

• Discovery. Network engineering carries this stage, on the order of several days of concentrated work to stand up collection and then reconcile the discovered device list against the asset register. Identity and directory input is needed once, to connect the attribute sources. OT operations are needed only to adjudicate the devices nobody can identify, which is a short task with a long tail.
• Traffic baselining. Low and intermittent for all three roles. The elapsed time is long; the effort is not. Budget periodic check-ins rather than dedicated hours, plus the time it takes to confirm the observation window actually captured a maintenance window and any seasonal or storm-driven mode.
• Policy authoring and simulation. The heaviest stage on the utility side, and the one most often underestimated. Reviewing a simulated deny list line by line is not a task the security owner can complete alone. It needs the operators who know why the analyzer at the north plant talks to a server nobody documented. Plan on several working sessions with OT operations in the room rather than a document sent out for comment.
• Enforcement at one plant. Concentrated around the cutover and the days immediately after. Network engineering on call, OT operations watching the process, and a named person who can authorize a rollback without convening a meeting.
• Expansion to remote sites. Returns to intermittent, and is dominated by site-by-site classification rather than by policy work. This is where an incomplete site list becomes expensive, because every unclassified site is a question that has to be answered before it can be enforced or formally accepted as visibility-only.

Two implications if you are running a small team. The effort is front-loaded and then spiky rather than evenly spread, so a two-person department can run a proof of value of this shape, though not while absorbing an unrelated project in the same window. And the largest single variable is the accuracy of your own records before you begin. If the register and the site list are not accurate, expect reconciliation to dominate the early stages no matter which architecture is being tested. Ask each vendor which of these stages it staffs on your behalf and which it expects your team to carry, and get that split in writing alongside the baseline period.

If a vendor cannot describe what happens at stage 3 in concrete terms, that is the answer to question 4 in the list above.

What to Do Before You Contact Anyone

Three pieces of preparation change the quality of every vendor conversation that follows, and none of them requires a purchase.

Write your site list first, plant by plant and remote site by remote site, and record what network equipment sits at each one. That list is what turns questions 6 and 13 from a discussion into a test. A vendor that will not mark your sites as enforce-capable or visibility-only in writing has told you something.

Reconcile your asset register before the discovery stage rather than during it. Closing the gap between the register and reality is worth doing whichever architecture you buy, and it is the single largest variable in what a proof of value costs your team.

Then decide your own numbers in advance. Set the coverage threshold you will accept across your site list, and name the compensating control for every site that falls outside it. Put both in writing before the proof of value starts, so the threshold is yours rather than the one that emerges from the results.

With those three in hand, send the fourteen questions to every vendor on your shortlist in the same order, and include us. Elisity sells one of the approaches compared above, and the fastest way to find out whether it fits your estate is to make it answer questions 1, 3, 6, and 12 against your own asset list and site list. If it doesn’t fit, the questions will surface that faster than a demo will, and you will still have the answers you need from everyone else.

If you would rather walk your site list with an engineer than sit through a slide, [ask for that conversation](https://www.elisity.com/request-a-demo). If you would rather run the checklist yourself first, that’s the better order anyway.

Frequently Asked Questions About Evaluating OT Security Vendors

What should a water utility look for when evaluating OT segmentation vendors?

Look for answers given against your own asset list and your own site list, not a datasheet. Ask every vendor the same questions in the same order, and require each to state the hardware and firmware it enforces on, the coverage percentage it can reach and by what method, its licensing model and three-year cost, and its infrastructure prerequisites.

Then compare the answers rather than the demos. The fourteen-question checklist and the approach comparison earlier in this article are built for exactly that: the comparison table states the licensing model and prerequisites for every approach, including the one we sell. A vendor that answers a coverage question with a percentage but will not name the hardware behind it has not answered it.

Which OT segmentation approach is best for a water utility?

No single approach is best, and a vendor that answers otherwise is describing its own product rather than your estate. Most mature water programs run two or three together: a firewall boundary between business and process networks, passive OT monitoring for visibility, and one internal enforcement mechanism chosen by how many sites you run and how many of your assets can take an agent.

What evidence should an OT security vendor produce for EPA and AWIA compliance?

Ask for named artifacts rather than a compliance claim. The useful outputs are a reconciled asset inventory, a record of what each device is permitted to reach, proof that policy was simulated before enforcement, and a change history naming who altered each rule. Those feed an AWIA Risk and Resilience Assessment, a state sanitary survey, and a cyber insurance application. No product makes a utility compliant by itself.

How long does an OT segmentation proof of value take at a water utility?

Plan on discovery across weeks one and two, then a baseline period the vendor states in writing, then policy authoring and simulation about two weeks after that baseline ends, enforcement at one plant two to four weeks later, and remote site expansion from week four onward. Baselining is the variable stage, because it has to cover a full operational cycle including a maintenance window.

How much utility staff time does an OT segmentation proof of value require?

Three roles have to be available: network engineering, OT or SCADA operations, and whoever owns identity and directory data. The effort is front-loaded and spiky rather than evenly spread. Policy review is the heaviest stage, because a simulated deny list needs the operators who know why a given analyzer talks to a given server. A two-person department can run one, though not while absorbing an unrelated project.

What should a water utility ask about OT segmentation licensing and total cost?

Ask for the unit of licensing first, whether that is per device, per host, per site, per sensor, per appliance, or per user, then a three-year total priced against your own asset count. Ask separately what sits outside the license: hardware, professional services, support tier, training, and the cost of adding a site. The prerequisites you have to own already are part of the price.