Network segmentation for manufacturing: separating the office from the plant

Walk into most Indian factories and you will find one flat network. The ERP server, the office laptops, the CCTV recorder and a machine controller running an operating system that went out of support years ago all sit in the same broadcast domain, able to reach each other freely. That arrangement means a single compromised laptop can reach production.

Why it ends up this way

Nobody designed it. The office network was installed first. Then a machine needed a network point, so one was added. Then another. Machine vendors ask for connectivity and rarely specify isolation. There was never a moment where somebody decided to connect production to the internet, it just gradually became true.

What to separate

At minimum, three zones. Office IT: laptops, printers, general file access. Production: machine controllers, HMIs, anything the line depends on. Shared services: the ERP and file servers that both sides legitimately need.

Traffic between zones is then explicit rather than assumed. Office can reach shared services. Production can reach shared services for the specific ports it needs. Office cannot reach production directly, and production has no route to the internet unless a specific vendor requirement demands it, in which case that route is narrow and logged.

Handling controllers you cannot patch

The usual objection is that machine software only runs on an old operating system and the vendor will not certify anything newer. That is common and it is not a reason to leave it exposed.

Isolate instead of upgrading. Put the machine on its own segment with tightly controlled access, no general internet route, and monitoring around it. You have not fixed the vulnerability but you have removed almost every path to reaching it, which for a machine that cannot be changed is the achievable outcome.

Doing it without stopping production

This is the real constraint, and it is why segmentation projects stall. The sequence that works:

First, observe. Put monitoring in place and record what actually talks to what for a couple of weeks. Documentation and memory will both be wrong, and cutting traffic you did not know existed is how you stop a line.

Second, design from the observed traffic rather than from the diagram.

Third, implement in permissive mode. Create the segments and the rules but log rather than block, and watch what would have been denied.

Fourth, enforce during a planned window with a rollback ready and somebody from production present.

The physical layer

Segmentation is logical, but on a plant the physical layer usually needs attention at the same time. Cable runs damaged by traffic, switches in sealed cupboards running hot, equipment with no power protection in a plant with unstable supply. Those cause more outages than any configuration issue, and a segmentation project is the natural moment to fix them since you are already in the cabinet.

What good looks like afterwards

You can say which systems can reach production and why. A compromised office laptop cannot reach a controller. Legacy machines are isolated and monitored rather than exposed and ignored. The comms cabinet is labelled and documented. And you have a diagram that matches reality, which is worth more than it sounds the next time something breaks at two in the morning.