Flat OT networks and what the firewall can't see

To audit a flat OT network before segmenting it, don’t start with the firewall rules: most of its traffic never crosses the firewall, so a clean rule review proves nothing. Start from what the network carries. Collect an asset list, the switch and VLAN layout and whatever traffic the firewall does log, find where office, server and control hosts share a zone or subnet, and note which hosts speak industrial protocols to the controllers. Then plan the first boundaries, IT from OT first and an industrial DMZ next, and audit the rules on those boundaries once traffic crosses them.

A flat network is one where office PCs, servers, HMIs and controllers share one zone, often one subnet. Every host can reach every other host, and the traffic between them never passes through a firewall. Many plants run this way: the network grew one switch at a time, and nothing failed, so nobody split it.

Flat network audit checklist

1. Count the zones and the share of sessions that stay inside one. A firewall with “inside” and “outside” only, or a log where nearly every session stays in one zone, means the firewall is rarely asked.
2. Find office, server and control hosts in one subnet or VLAN.
3. List hosts with no engineering role that speak industrial protocols to controllers.
4. Check the core switch for VLANs routed with no access lists. Those VLANs are still one network as far as access goes.
5. Find paths around the firewall: cellular modems, vendor remote-access boxes, dual-homed workstations.
6. Report the site as not judged, never as a pass, until traffic crosses boundaries the firewall checks.
7. Plan IT from OT as the first boundary. NIST SP 800-82r3 section 5.2.3.1 keeps Level 4 devices from reaching Level 2, 1 or 0 directly; IEC 62443-3-3 SR 5.1 asks for control system networks to be segmented from other networks.
8. Draw zones and conduits with the asset owner. IEC 62443-3-2.

Why a flat network looks clean in a firewall review

A firewall only decides on traffic that crosses it. On a flat network, an office PC opening Modbus to a PLC, or a laptop opening RDP to an HMI, stays inside one zone, so the firewall is never asked. Its rules can look tidy and its logs can show no violations at all.

That is the trap. Zero violations on a flat network means the firewall isn’t asked, not that the site is safe. A review that reports it as a pass gets the answer backwards.

Signs a network is flat, or close to it:

• Nearly all sessions stay inside one zone. The traffic log shows few sessions crossing zones, because there are few zones to cross.
• Only “inside” and “outside”. The firewall has one internal zone and the internet, so every internal host sits behind the same boundary.
• Office and control hosts in one subnet. Workstations, historians, HMIs and PLCs have addresses in the same range.
• Industrial protocols from office hosts. Modbus, EtherNet/IP or S7 sessions start from hosts that have no engineering role.

What the standards ask

NIST SP 800-82r3 recommends segmenting and isolating IT and OT devices, and section 5.2.3.1 sets the baseline for the firewall between them: allow connections only between adjacent levels or zones, and keep business devices from talking directly to supervisory and control devices. A flat network has no boundary on which to apply either. The NIST SP 800-82r3 guide has the section-by-section view.

IEC 62443-3-2 asks the asset owner to partition the system into zones and conduits, and IEC 62443-3-3 SR 5.1 (network segmentation) asks for control system networks to be segmented from other networks. On a flat network both start at step one. The IEC 62443 guide covers how zones and conduits fit together.

The Purdue model is a reference rather than a requirement, but it shows the gap plainly: a flat network puts Level 4 and Level 1 on the same wire.

Splitting a flat network without stopping production

The goal is to make the traffic that matters cross a firewall, then decide what may cross. Do it in stages, each in a planned window with a rollback ready.

1. Collect a traffic log first. Turn on logging where the firewall does see traffic, and collect a window long enough to cover shifts, batch runs and maintenance. It shows which hosts talk to which, on what protocol, and gives you the inventory to draw zones from.
2. Separate IT from OT first. Move office users and business servers into their own zone, on their own firewall interface or VLAN, so their traffic into OT has to cross the firewall. This is the boundary NIST SP 800-82r3 cares about most.
3. Add an industrial DMZ. Put the services both sides need (a historian replica, a jump host, a patch server) in the IDMZ, so sessions end there instead of running straight into OT. See the IDMZ guide.
4. Split OT into cells next. Group each production cell’s HMIs, controllers and I/O into its own zone. Traffic inside a cell (HMI to PLC, PLC to I/O) is the process itself and stays allowed.
5. Log before you block inside OT. New boundaries between cells start with allow-and-log rules. Tighten only once the log shows the flows the conduit really carries.

Re-addressing is the expensive part. Where hosts can’t move subnets yet, a VLAN per zone with routing through the firewall can create the boundary first. Either way the firewall can only judge what passes through it: traffic between two hosts on one switch never reaches it.

How SegAudit reports a flat network

SegAudit never reports a flat site as clean. When nearly all of a site’s sessions stay inside one zone, or the site has only one zone besides the internet, the overview says the site runs as one flat network and shows “Can’t judge yet” for its maturity instead of a clean result. The audit report and the executive brief say the same.

The example above is Mill Creek, a made-up single-firewall site in SegAudit’s test samples. 95% of its 200 sessions never leave zone “inside”, among them HMIs polling PLCs on Modbus, office PCs opening RDP to HMIs, and office PCs reaching a PLC on Modbus. None of that crosses the firewall, so none of it is a violation the firewall could report.

The few sessions that do cross zones are still judged: here, one medium finding for uninspected TLS leaving for the internet. In the maturity criteria, the site fails “Traffic crosses zones the firewall checks”, which SegAudit relates to IEC 62443-3-2 zones and conduits, and the compliance crosswalk marks IEC 62443-3-3 SR 5.1 as partial rather than supported.

Once the zones are split and the next traffic log shows sessions crossing them, the same review ranks every path that skips a level, with the rule that allowed it. To see what SegAudit catches in one of your own exports, run the free Quick check.

Common questions

Is a flat network always a problem?

A small, isolated cell with no connection to anything else can be flat inside. The problem is a flat network that also holds office hosts, remote access or an internet path, because then those can reach the controllers directly.

Do VLANs alone segment a network?

Only if traffic between the VLANs is routed through a firewall or another device that enforces rules. VLANs that are routed freely on a core switch are still one flat network as far as access goes. Check the core switch for routed VLAN interfaces with no access lists before counting a VLAN as a boundary.

Can we start without re-addressing?

Often, yes. Separating IT from OT is usually the first boundary, and it can be built with a VLAN and a firewall interface before any OT host changes address. Boundaries between cells inside OT can follow one at a time, starting with rules that only log, so nothing in production is cut.