Nearly every industrial organisation will tell you its control network is segmented. Almost all of them can produce the VLAN list to prove it. Forescout's research arm went and measured what is actually inside those segments, and of every segment that contained at least one OT device, 13 percent contained OT devices and nothing else.
The analysis, published on 22 September 2026, covered 47,700 network segments holding more than 2.5 million devices across 209 organisations (Forescout, SecurityWeek, Industrial Cyber). Each device was classified into one of four categories, IT, OT, IoT and Internet of Medical Things, and into one of 327 more specific device functions. Segments with medical devices did worse than OT: only 6 percent held IoMT devices alone.
The topline looks fine, which is the problem
Counted across all 47,700 segments, 62 percent held a single device category, 29 percent held two and 9 percent held three or more. Read on its own that is a reasonable-looking distribution, and it is the number a segmentation programme would report upward.
The OT and IoMT figures sit underneath it, and they point the other way. Nearly half of the segments containing OT or IoMT devices also mixed in IT and IoT assets (Infosecurity Magazine, SC Media). The aggregate is carried by the large population of ordinary IT segments that were never the point of the exercise. The segments the architecture was drawn to protect are the ones least likely to be clean.
This is a vendor telemetry study rather than a survey, and that cuts both ways. It is not self-reported, so nobody was grading their own homework. It also reflects networks where a visibility platform is already deployed, which is not a random sample of industry. If anything that biases the finding optimistic: these are organisations that invested in seeing their own estate.
Blast radius, measured
The average segment in the dataset held 54 devices across four different device functions. That is the working definition of blast radius: compromise one device and 53 others sit inside the same trust boundary, reachable without crossing anything that inspects traffic.
The distribution matters as much as the average. Seventeen percent were effectively micro-segments holding a single device, 72 percent held between two and 50, and 11 percent held more than 51.
Two details compound it. The average device belonged to 1.5 segments rather than one, so the reachable set from a given foothold is wider than any single segment's membership. And by industry, business and professional services averaged 179 devices per segment, healthcare 116 and oil and gas 72 (SecureWorld). A healthcare network with 116 devices in the average segment is not one flat network, but it is a long way from the zone model its own documentation almost certainly describes.
The IP camera is the load-bearing example
Cameras appeared in 2,266 segments, roughly 5 percent of the total. Fifty-one of those segments, about 2 percent, held only cameras. The rest most commonly shared space with workstations (60 percent), printers (47 percent) and servers (37 percent).
That is the whole lateral movement problem in one device class. An IP camera is a full networked computer with a web stack, firmware that is patched on the vendor's schedule rather than yours, credentials that are frequently shared across a fleet, and a procurement path that often runs through facilities rather than IT. Put it on a segment with workstations and servers and it becomes a permanent, unmonitored beachhead inside a boundary that other controls assume is trustworthy.
Forescout also noted that half of the device functions appearing most often in mixed segments feature on its riskiest connected devices of 2026 list. The devices that are hardest to defend are disproportionately the ones sharing segments with everything else. That is not a coincidence so much as a consequence: devices nobody owns end up wherever there was a spare port.
A VLAN is not a zone
The gap between "we have segments" and "we are segmented" has a precise definition in the standard most industrial teams are already measured against. In the ISA/IEC 62443 series, a zone is a grouping of physical or logical assets that share common security requirements, with clearly defined borders, and a conduit is the logical grouping of communication channels between zones. Segmentation is meant to be an outcome of the risk assessment in IEC 62443-3-2, which partitions the system under consideration into zones and conduits and sets a target security level for each (ISA).
Read that definition against a segment holding PLCs, an engineering workstation, a printer and two cameras. Those assets do not share common security requirements. They have different patch cadences, different owners, different exposure and wildly different consequences when compromised. The segment is a VLAN with a name. It is not a zone, and no amount of documentation makes it one.
The useful diagnostic question is not how many segments you have. It is whether you can state, for each segment, the security requirement its members share.
Segmentation is a state, not a project
A zone architecture is correct on the day it is commissioned and starts drifting immediately afterwards. A contractor needs a laptop on the process network for a commissioning window and it stays. A camera fleet is expanded and the installer uses the port that works. An acquisition arrives with its own addressing and gets bridged rather than re-architected.
None of those decisions is unreasonable in isolation, and none of them updates the diagram. Which is why the measurable thing is not the design but the current population of each segment, refreshed continuously. Forescout's own recommendations land in the same place: continuous asset visibility, identifying where the device categories converge, separating critical operational assets from enterprise IT, and monitoring for segmentation drift.
What to do with this
- Inventory by segment, not by site. Produce the list of device categories and functions present in each segment. If you cannot generate that from live data, the segmentation claim is untested rather than true.
- Rank your segments by blast radius. Devices per segment multiplied by the consequence of the most critical device in it. Fix the top of that list rather than the whole estate.
- Find the convergence zones first. Segments holding three or more categories are where the study found the riskiest device functions clustering. They are also usually the cheapest to split, because the mixing was accidental.
- Give cameras, badge readers and building systems their own zones. They are the clearest case in the data and the easiest to argue: nothing on a process or clinical network needs to reach a camera's web interface.
- State the shared security requirement for each zone. One line per zone, in the language of 62443. Zones that cannot be described that way are the ones to redraw.
- Instrument drift as an alert, not an audit finding. A new device category appearing in an existing segment should generate a ticket the week it happens, not a finding at the next assessment.
- Watch east-west traffic. With 54 devices in the average segment, most attacker movement never crosses a firewall. Detection that only sees the boundary will not see the incident.
Where MBCTG fits
This study is really an argument about measurement rather than architecture. The design is usually defensible; what is missing is current, continuous evidence of what each segment actually contains. That evidence is the first output of passive asset visibility, and it is the foundation of our OT security services: enumerate what is present, see how the categories are mixed, and monitor the traffic between them without adding load or risk to the control network.
Detecting movement inside a segment is the harder half, because there is no boundary device to log it. That is a monitoring and analyst problem, which is what our 24/7 SOC is for: a behavioural baseline per segment, and someone who knows which protocol conversations are normal on a plant floor at three in the morning. Where the work is mapping zones and conduits, evidencing them against IEC 62443 or NIST CSF 2.0 and keeping that documentation true as the estate changes, that is compliance and GRC.
If your network diagram shows clean zones and you have not verified the contents of those segments against live data this year, talk to an MBCTG expert. Counting what is in them is the cheap step.
