
MIN · Metals & MiningImages generated
Method note · Range Lab
Flat networks: why one switch can see the whole plant
Ask an engineer to describe the plant network and the honest answer, on most sites, is a shrug and a sentence: “It’s all on the one switch.” That sentence is a complete description of a flat network, and it explains more about a site’s exposure than any talk of firewalls.
What flat means on a plant floor
A network is flat when every device on it can talk directly to every other device, with nothing in between to say no. In network terms it is one broadcast domain: a controller in the furnace cabinet, the HMI in the control room, the historian, the engineering workstation and the printer in the office can all see each other’s traffic and reach each other’s ports. There are no zones, so there are no conduits, so there is nothing to inspect, log or block.
Flat is not the same as unmanaged. Many flat networks run on good switches with VLANs configured, but the VLANs were set up for traffic management rather than security, and a router somewhere joins them all back together without a rule between them. A network that is segmented in the switch configuration and flat in practice is the most common kind, and the one hardest to see from a drawing.
The test is simple. Pick the oldest controller on the site and ask what could open a connection to it. On a flat network the answer is anything with a cable, including the laptop a contractor brought in this morning.

How a plant gets there
Nobody designs a flat network. It arrives in three ways, often all three on the same site.
The first is growth. A line is installed with its own small network, then a second line, then a packing hall, each separate because each was a separate project. Then somebody needs production counts from all of them on one screen, and the quickest way to get that is to join the networks together. The join is a switch, because a switch is cheap and works the first time, and it is never revisited.
The second is convenience. The engineering workstation needs to program controllers on three lines, so it is put where it can reach all three. The historian needs to collect from everything, so everything is given a path to it. Each decision is sensible on the day it is made. The sum of them is a network where the easiest path for the engineer is also the easiest path for anyone else.
The third is integrator defaults. A machine builder delivers a cell with a switch in the cabinet and a few spare ports, and the commissioning engineer, who has a deadline, plugs the cell into whatever uplink is nearest. The cabinet switch has no configuration beyond what shipped. In metals and mining the pattern is older and starker: the network was built before anyone expected an office to connect to it, and when the office arrived, through a maintenance system or a contractor’s link, it arrived onto a network that had never needed a boundary.
Nobody designs a flat network. It arrives one reasonable decision at a time.
Why one laptop becomes the whole plant
On a flat network, there is no difference between being on the network and being able to reach the controllers. A contractor’s laptop that has been on many other sites, an engineering workstation that also reads email, a vendor’s remote-access box: whichever of these is compromised first, the attacker’s position is the same. They can see every device and try every port.
Industrial protocols make this worse than it would be in an office. Modbus and the programming protocols that controllers listen on have no authentication of their own, because they were designed for a wire only trusted equipment could touch. On a flat network, the wire is touched by everything. Being on the network is being in control, and the plant’s oldest, least patchable controller sets the level of risk for all of the rest.
This is also why the firewall at the office boundary is not the answer people hope it is. It protects the plant from the office, which matters, but the laptop, the workstation and the vendor box are already inside. The Level 3.5 note covers the boundary; this note is about what happens once anything is past it.

Segmentation is a project, not a weekend
The instinct, once a plant sees its network this way, is to fix it in one change over a long weekend. That rarely goes well. Devices that were never documented stop talking to things they depended on, the production team loses confidence in the work, and the project ends with half the rules disabled “for now”. Segmentation is a staged project, and the stages have an order.
The first stage is to know what is there. Not what the drawing says, and not what the switch configuration says, but what is actually on the network and what it actually talks to. A passive capture at the right switch ports gives this without sending a packet to a controller, the only responsible way to look at a controller of the age found on a mill. The output is an asset inventory and a map of conversations, and both are needed before a single rule is written.
The second stage is to draw the zones on paper. Group the equipment by what shares a purpose and a level of trust: a line and its HMIs, the historian and its servers, the engineering workstations, the vendor links. Then draw the conduits between them, using the conversation map rather than assumptions. This is the work ISA/IEC 62443-3-2 describes. Most of the surprises happen here, and it is far better to be surprised on paper.
ISA/IEC 62443-3-2 · zones, conduits and risk assessment
The third stage is to separate the cheapest boundary first. On most sites there is one boundary that is both the most valuable and the easiest to cut: the vendor remote-access paths, or the office-to-plant join, or the engineering workstations. It is usually possible to put a firewall or a brokered jump host at that one point, with rules written from the captured traffic, and prove to the production team that nothing broke. That proof is what buys the rest of the project.
The fourth stage is the rest, around maintenance windows. Each remaining boundary gets its own small change, planned for a window when the affected line is down anyway, with the rules derived from what was observed and a named person on site to roll back. In manufacturing this often means one line at a time over several months. In a smelter it means waiting for a furnace reline, because a furnace is not restarted on a Tuesday afternoon.
Sample
| Stage | What changes | When | Production risk |
|---|---|---|---|
| 1 | Passive capture; asset list and conversation map | Any time; nothing touched | None |
| 2 | Zones and conduits drawn on paper | Any time; nothing touched | None |
| 3 | Vendor remote-access paths brokered through one point | Next planned stop | Low; vendors notified |
| 4 | Office-to-plant join moved behind a firewall | Next shutdown | Moderate; rules from capture |
| 5 | Lines separated into zones, one per window | Over the year | Low per line; one at a time |
What this means for how Range works
This is why our method starts with listening and not with architecture. We do not sell firewalls, and we do not configure them; we put the plant in a position to specify them. A flat network is not a failure of the people who run the site, and it is not fixed by a product. It is fixed by knowing, in writing, what is on the network and what talks to what, and then cutting the boundaries in an order the plant can live with.
Segmentation done this way is slower than the weekend version and it works. The plant ends up with zones that match the equipment that is actually there, conduits that are named and logged, and a production team that saw each change go in and saw nothing break.
Sources · ISA/IEC 62443-3-2 (zones and conduits); NIST SP 800-82 Rev. 3, section 5 (network architecture); Rockwell/Cisco Converged Plantwide Ethernet (CPwE) design guide, enet-td009.
Related


