The network your plant runs on is not your office network
Operational technology and business IT end up sharing one flat network far more often than anyone intends. Here is what that actually costs, and what separating them involves.
Nobody decides to put the packing line on the same network as the payroll PC. It happens one cable at a time.
A controller needs a network drop, and the nearest switch is the one in the office cupboard. A camera goes in, and it gets an address from the same DHCP scope as the laptops. A vendor needs remote access to a machine for commissioning, so someone forwards a port and then forgets. Five years later the grader, the weighbridge, the door controllers and the accounts team are all in one broadcast domain, and the only reason nothing has gone wrong is that nothing has gone wrong yet.
Why operational kit cannot be treated like a laptop
The instinct is to manage this equipment the way you manage the rest of the estate. Patch it, join it to the domain, put an agent on it. Most of the time you cannot, and the reasons are not laziness.
- Availability outranks everything. A laptop can reboot at lunchtime. A line running at capacity in the middle of a season cannot, and the cost of stopping it is measurable in a way that most IT risk is not.
- The lifecycle is a decade or more. Plant bought in 2012 is still plant. It runs the operating system it shipped with, and no update is coming.
- The vendor contract may forbid changes. Touch the configuration and you can void support on a machine worth more than the entire IT budget.
- It fails differently. A compromised office PC is an incident. A controller behaving unpredictably is a safety question.
So the honest position is that a lot of operational equipment cannot be hardened in place. Which means the network has to do the work instead.
What actually goes wrong
Two patterns account for most of the damage we see discussed in this sector, and neither requires anyone to be targeted specifically.
The first is lateral movement. Ransomware arrives the ordinary way, through an email attachment or a stolen credential, lands on an office machine, and then looks around. On a flat network it finds file shares, backups, and the historian sitting alongside them. The production stop is not the attack. It is the blast radius.
The second is the forgotten device as a foothold. Cameras, access controllers, sensors and print servers are computers, they ship with default credentials, and nobody puts them on a patch schedule because nobody thinks of them as IT. A device that watches a gate is also a device sitting inside your network.
Separation, not an air gap
The phrase people reach for is air gap, and it is usually the wrong goal. A genuinely isolated network cannot be monitored, cannot be backed up centrally, and gets bridged within a month by someone with a USB stick and a deadline. What you want is segmentation you can actually live with.
In practice that means:
An inventory first. You cannot segment what you cannot list. This is the unglamorous part and it is where the work really is: every addressable device, what it talks to, what it needs to talk to, and who owns it. Most sites discover things nobody remembered installing.
Zones with deliberate crossings. Operational equipment in its own segments, grouped by function and by how much downtime each can tolerate. Traffic between zones goes through a controlled point rather than wherever the routing tables allow.
Remote access that is not a forwarded port. Vendors do need in. Give them a brokered path, tied to an identity, time limited, and logged, rather than a rule someone added in 2019 and never removed.
Monitoring that understands the difference. An office network is noisy and a control network should be boring. Boring is much easier to alert on: on a segmented control network, a device suddenly talking to something new is a signal rather than background.
The part that takes the longest
None of the above is technically difficult. What makes these projects long is that the people who understand the plant and the people who understand the network usually do not work for the same organisation, and often have not been in the same room.
Getting a maintenance engineer and a network engineer to walk a site together produces more security value in a day than a quarter of remote assessment. The engineer knows which machine cannot be touched during a shift and why. The network side knows what that machine has been quietly connecting to. Neither of them knew the other thing before lunch.
If your operational equipment and your office network are one network, that is worth knowing before something makes it obvious.