OT Network Segmentation: How to Separate the Plant Floor From IT

On your next plant site visit, ask whether they've got OT network segmentation between the machines and the business network. They'll say yes. Everybody says yes.

Now ask what enforces it.

The answer is almost always a VLAN.

A VLAN on its own isn't a segmentation control. Without a policy deciding what's allowed to cross between VLANs, it's a label.

That gap is the whole business case. Segmentation is the control that stops a compromise on the business network from becoming a compromise on the plant floor, and most manufacturing clients believe they've already got one. MSP Pentesting tests whether it holds. Channel-only, under your brand, with your logo on the report and the remediation work that follows staying with you.

Why plant networks are flat

This isn't negligence, and walking in with that attitude ends the conversation. Flat plant networks are the product of twenty years of reasonable decisions.

• Serial got converted, not redesigned. Devices that used to talk over RS-485 in a locked cabinet were dropped onto Ethernet with a media converter. Same trust assumptions, brand new reachability.
• The integrator built the cell and left. Machines arrive as turnkey packages with their own switches, their own addressing and a support agreement requiring access. Nobody was paid to consolidate the design afterward.
• Uptime beats everything. A firewall between IT and OT is one more thing that can fail and stop production. A plant manager who's lost a shift to one will veto the next on principle.
• Nobody owns the boundary. IT owns up to the plant door, operations owns the machines, and the space between belongs to whoever answered the phone that week.
• The business wanted the data. Somebody needed production numbers in a dashboard, so a path opened from the historian to the office and never closed.

The result is predictable. One address space, a domain controller and a PLC that can reach each other, and any incident on either side becoming an incident on both.

What OT network segmentation means when it's real

It means enforced separation with a policy you can read, test and prove. Four things have to be true before the word applies.

• One deliberate boundary. Traffic between IT and OT passes through a single enforcement point you control, not the four accidental ones you'll find later during testing.
• Default deny in both directions. An explicit allow list of source, destination, port and protocol. Everything else drops. Egress matters as much as ingress, because that's how malware calls home and how data walks out.
• A DMZ in the middle. No session originates in IT and terminates on a plant asset. Traffic lands in an industrial DMZ holding the historian replica, the patch distribution point, the jump host and the vendor access broker. IT talks to the DMZ. OT talks to the DMZ. They never talk to each other.
• Zones inside OT as well. One giant flat OT network is only half a fix. Line 1 doesn't need to reach line 3, and the building management system doesn't need to reach either.

This is where somebody cites the Purdue model. It's useful shorthand: process and control equipment at the lower levels, site operations above that, an industrial DMZ at level 3.5, business IT on top. Use it to explain layers to a plant manager.

Don't treat it as a target architecture. Real plants run wireless, cloud connected equipment and vendor tunnels the model never anticipated. IEC 62443 zones and conduits is the more useful language, because it starts from what needs to communicate rather than which level a device sits on.

Start from traffic, not from levels.

What good segmentation looks like in practice

Here's the before and after in terms a plant client will recognize.

Vendor access is where most engagements find their worst issue. Every major machine came with a support contract, and the contract usually came with a way in. Standing access, a shared login, and a modem that answers whether or not anyone expected a call.

Two things the diagram doesn't have room for. The historian is the first. In a flat plant it sits in OT and gets queried straight from the business network, which makes it a bridge with a database engine attached. Segmented, a replica lives in the DMZ and the original never takes a query from outside.

The second is the one nobody argues with. In a flat plant, the evidence that segmentation works is a network diagram. In a segmented one, it's a test result showing exactly what got blocked.

A diagram is an intention.

Test results are evidence.

Where segmentation quietly fails

Even in plants that did the work and bought the firewall, the same bypasses turn up.

• The dual homed workstation. One NIC on the office network, one on the plant network, quietly acting as a router nobody configured. Engineering laptops do this constantly.
• The cellular modem in the panel. A vendor installed an LTE router for remote support. It bypasses the firewall completely and it doesn't appear on any diagram anywhere.
• The temporary rule. Added during a commissioning weekend three years ago, still in the policy, still permitting far more than anyone remembers approving.
• The historian nobody replicated. Still collecting from OT and still answering queries from the office, because moving a copy into the DMZ got quoted once and never approved.
• Management planes on the wrong side. Switch admin interfaces, out of band server management and the UPS web page, all reachable from an office VLAN.
• Wireless that forgot its zone. A warehouse access point broadcasting an SSID that lands on the same VLAN as control traffic.

None of these show up on a network diagram. All of them show up in a test.

How an MSP validates OT segmentation

This is the part you can package and sell, and it isn't a penetration test. It's a verification exercise with a binary answer: does the boundary do what the policy says?

1. Get the intended policy in writing first. If nobody can state what's supposed to be allowed, you're not validating segmentation, you're discovering it. Both are billable. Quote them separately.
2. Map the real topology passively. Span port captures at the boundary and inside each cell, plus configuration exports from every switch and firewall you can reach. This alone surfaces paths nobody knew existed.
3. Review the ruleset by hand. Count the any to any rules. Find the rules pointing at hosts decommissioned years ago. Read the hit counters, which separate load bearing rules from archaeology. Check that the deny rule is actually last.
4. Test from IT toward OT. From a host on the business network, attempt connections to defined OT addresses and ports, then record what was permitted against what should have been. Nothing gets written to a controller. This proves reachability, not impact.
5. Test the return path. From a controlled host inside the OT zone, attempt outbound connections to the internet and back into IT. Egress gaps are more common than ingress gaps, and they're what turns a plant infection into a data loss event.
6. Hunt for dual homed hosts. Second NICs, forgotten wireless adapters, ARP and route tables showing systems on both sides. The bypass usually isn't in the firewall. It's here.
7. Retest after remediation. The same test set run before and after is the artifact an insurer or auditor actually wants to see.

Run every active step inside an agreed window, with the operations lead present and a stop signal defined.

That isn't ceremony.

It's the difference between a repeat client and a very short phone call.

The precedent for testing a boundary

If a client asks why segmentation needs testing rather than documenting, point at PCI DSS. Requirement 11.4.5 says that where segmentation isolates the cardholder data environment, those segmentation controls get penetration tested at least once every twelve months. Requirement 11.4.6 tightens that to six months for service providers.

OT has no equivalent mandate. The logic transfers anyway. A control claimed as a boundary should be tested as one, on a schedule, by someone who didn't build it.

For the OT side, IEC 62443 supplies the vocabulary and NIST SP 800-82 supplies the architecture guidance. Cite both and the client's auditor stops asking where your methodology came from.

What the deliverable should say

A segmentation validation report is short and specific, and it lives or dies on one table: every path tested, the expected result, the actual result. Nothing else carries as much weight.

Split remediation by whether it needs a production outage. A firewall rule change is a Tuesday afternoon. Re-addressing a cell to pull it out of the flat space is a shutdown project with a capital line attached. Mixing them into one list is how remediation stalls for a year. Our pentest report template shows the structure we use.

How to sell it without leading with fear

Don't open with attackers. Open with the shift.

Ransomware on the business network is an IT problem with a recovery plan. Ransomware that reaches the plant is a stopped line, and every plant manager can convert a stopped line into dollars per hour without reaching for a calculator. Ask for that number. It becomes your business case.

Then keep the first engagement small. Document the boundary, review the ruleset, run the test set, hand over the evidence. Defined scope, defined output, and no redesign to approve before you've proven anything is wrong.

The technical work goes to a pentest partner that works only through the channel, so your client sees your team and your report throughout. You keep the relationship and the remediation work behind it.

Frequently asked questions

Is a VLAN enough to segment OT from IT?

No. A VLAN separates broadcast domains, which is real, but on its own it isn't a security boundary. If a layer 3 switch moves traffic between those VLANs with no policy applied, the segments are connected in every way that matters to an attacker. Segmentation needs an enforcement point that denies by default and a policy somebody wrote on purpose.

Do we have to follow the Purdue model?

No. It's a reference architecture from an earlier era of plant design, and most real environments can't map onto it cleanly. Use it to explain layers to a non technical stakeholder, then design against IEC 62443 zones and conduits, which start from communication requirements rather than fixed levels.

How do we handle vendor remote access without breaking support contracts?

Terminate vendor sessions in the industrial DMZ through a jump host, require MFA, record the session, and keep the account disabled until a support request comes in. Vendors accept this regularly. What they object to is losing access altogether, not losing standing access.

Will validating segmentation disrupt production?

Connection attempts against a boundary are low impact by nature, and the risk drops further when the test set is reviewed with the plant and run in an agreed window. It's never exactly zero, which is why nothing active gets aimed at a controller and operations holds a stop signal throughout.

How long does a segmentation validation take?

For a single site with a documented boundary, it's a short engagement. For a plant running unmanaged switches from three different integrators with no current drawing, discovery becomes the bulk of the work. Scope discovery separately if you don't know which one you're walking into.

Where to start

Flat plant networks are the default rather than the exception, and the reasons are practical rather than careless. That doesn't change the exposure. One compromised office laptop shouldn't reach a controller, and in most manufacturing environments it still can.

OT network segmentation fixes that. Validation proves it held, and proof is what your client's insurer and auditor are asking for.

Start with one client and one boundary. Get a pentest quote and scope the test set properly.