OT Network Segmentation Without Production Downtime: A Brownfield Playbook

Nederlands: Lees dit artikel in het Nederlands.

OT network segmentation does not have to begin with a disruptive “big bang” cutover. In an operating plant, the safer route is to build an evidence-based model of required communications, design zones around operational function and consequence, and introduce enforcement in controlled stages. The objective is not a perfect diagram. It is a network in which every permitted path has an operational reason, an owner and a tested fallback.

This matters in brownfield environments because availability and safety constraints are real. Legacy controllers may use undocumented services, vendor tools may depend on unexpected ports, and seemingly minor changes can affect time-sensitive traffic. A segmentation project succeeds when cybersecurity, engineering, maintenance and production treat it as an operational change—not merely a firewall exercise.

Why segmentation projects disrupt production

The technology is rarely the hardest part. Most failures begin with incomplete knowledge. Teams know the intended architecture, but not every communication path that has accumulated through years of expansions, temporary fixes and supplier access. A ruleset built only from documentation can therefore block a dependency nobody knew existed.

NIST’s Guide to Operational Technology Security recommends grouping components into levels, tiers or zones before applying isolation controls. It also stresses that zone design must consider day-to-day operations, safety and response capabilities. Required communications should be derived from mapped data flows and translated into enforceable policy.

That creates three practical rules for a brownfield project:

• Do not enforce what you have not observed and validated.
• Do not treat every asset in a subnet as having the same function or consequence.
• Do not implement a boundary without a tested rollback and an operational owner.

A six-stage brownfield segmentation playbook

1. Define the operational scope and failure conditions

Start with the process, not the switch cabinet. Identify the production cells, utilities, safety functions, quality systems and external services in scope. Agree what must remain available during the project and what constitutes an unacceptable impact. Include maintenance windows, seasonal constraints and supplier dependencies.

Record the people who can authorize a change, validate process behaviour and call a rollback. If those roles are unclear, the technical work is not ready to start.

2. Build a verified communication baseline

Combine architecture drawings, switch and firewall configurations, asset inventories, interviews and passive network observation. Passive collection is valuable because it can reveal actual flows without sending active probes into fragile equipment. Observation must cover representative operating states: startup, shutdown, recipe changes, batch transitions, maintenance and backup activity can all produce traffic that is absent during a quiet shift.

For each material flow, capture source, destination, protocol, direction, frequency, operational purpose and owner. The UK NCSC’s guidance on maintaining a definitive view of OT connectivity proposes five useful questions, including what an asset must communicate with, which protocols are required, what controls exist and whether compromise could bypass them.

3. Design zones around function and consequence

A zone should group assets that have compatible operational functions, trust requirements and cyber consequences. Typical boundaries may separate enterprise IT, an industrial DMZ, site operations, individual production areas, building management, laboratory systems and safety-related systems. The Purdue model can help communication, but it should not replace a site-specific risk assessment.

Keep the first design achievable. Excessive micro-segmentation can create an operational burden that the organization cannot maintain. Use finer-grained controls where the consequence, exposure or mixed trust level justifies them. NCSC identifies segmentation as a key way to contain compromise and describes micro-segmentation as useful where precise device-, service- or protocol-level restrictions are required.

4. Create an explicit conduit register

Every communication between zones should become a documented conduit. Define what may cross the boundary, in which direction, under whose ownership and with what logging. Replace broad rules such as “OT subnet to server subnet” with the narrowest workable combination of systems and services.

Pay particular attention to engineering workstations, historians, update services, domain services, backup platforms and vendor access. Where IT and OT exchange data, use an industrial DMZ so services can be brokered without creating direct enterprise-to-controller paths. Centralizing external access and intermediary services also makes monitoring and revocation more consistent.

5. Introduce enforcement in stages

Begin by deploying the boundary in a monitoring or permissive state where the chosen technology supports it. Compare observed traffic with the approved conduit register and investigate deviations. Next, block obviously invalid pathways, then move lower-risk zones to an allow-list policy before progressing toward more critical areas.

Each change should have a defined window, pre-change checks, a named decision-maker, observable success criteria and a rollback path. Validate the process, not just network reachability: confirm operator views, control actions, alarms, time synchronization, historian updates, backups and vendor workflows.

6. Operate segmentation as a living control

A firewall rule is not finished when it is installed. Assign an owner and review date. Link changes to management of change, project commissioning and supplier onboarding. Monitor denied traffic and policy exceptions, but distinguish a genuine security signal from an undocumented operational dependency.

Measure progress with operationally meaningful indicators: percentage of inter-zone flows with an owner, number of temporary rules past expiry, critical zones with tested rollback procedures, and time required to revoke supplier access. These measures show whether segmentation remains governable after the project team leaves.

Choosing the right enforcement technology

Different boundaries need different controls. VLANs and access-control lists can provide basic separation. Stateful firewalls add connection awareness. OT-aware inspection may help validate industrial protocols, while unidirectional gateways can be appropriate for narrowly defined one-way flows with high consequences. Host controls can add protection where endpoints support them safely.

Selection should follow the architecture and operational requirements. Avoid forcing a preferred product into every zone. The NCSC guidance on limiting the impact of compromise describes static controls as a minimum between zones and explains how stateful inspection, protocol-aware controls and monitoring can add layers where justified.

What good looks like

A mature result is understandable to more than the firewall administrator. Engineering can explain why systems communicate. Operations knows how a change is validated. Security can see and investigate boundary activity. Management knows which residual risks remain. Suppliers have constrained, auditable routes rather than permanent broad access.

If your current diagrams, rules and observed traffic do not tell the same story, start with discovery and validation. OT-Guard can support this through an OT Security Quickscan, independent OT security consulting and implementation through the OT-Guard Security Suite.

Frequently asked questions

Can we segment OT without replacing legacy equipment?

Often, yes. Network boundaries can compensate for limited device security, provided the required flows are understood and the enforcement technology is compatible with latency, availability and protocol requirements. Segmentation does not remove the need for lifecycle planning for obsolete assets.

Should every production cell become its own zone?

Not automatically. Zone granularity should reflect function, trust, consequence and the organization’s ability to operate the controls. Start with defensible boundaries and increase granularity where risk justifies the added complexity.

How long should traffic be observed before blocking?

There is no universal number of days. The observation period must include representative operating modes and infrequent but essential activities. A calendar week may be insufficient for monthly backups, maintenance or batch-specific workflows.

Planning a segmentation change? Talk to OT-Guard about validating the architecture, conduits and implementation sequence before production traffic is restricted.