Separating OT and IT in manufacturing
A production site usually has two networks pretending to be one. The office side gets patched every month; the machine side runs software that was current when the line was commissioned and cannot be touched without the manufacturer.
Machine control systems frequently cannot be patched, because the manufacturer only supports a specific software version and touching it voids the support agreement. That is a fact to design around, not a problem to fix.
The answer is separation: put the machine network on its own segment, allow only the specific traffic that has to cross, and never let a production system reach the internet directly or share a segment with office laptops.
Start with an inventory of what is actually connected. On most sites we find machines nobody knew were reachable from the office network, and that discovery alone justifies the exercise.
Two worlds with opposite rules
| Office IT | Machine control | |
|---|---|---|
| Patching | Monthly, automatic where possible | Only with the manufacturer, often never |
| Lifespan | Three to five years | Fifteen to twenty-five years |
| Priority | Confidentiality of data | Availability and safety of the process |
| Downtime | Annoying | Expensive by the minute, sometimes unsafe |
| Who owns it | IT | Production or maintenance, rarely IT |
The last row causes most of the friction. The machine network usually belongs to the people who run the line, and it was connected to the office network at some point so a report could be pulled. Nobody documented that.
Start by finding out what is connected
Every OT project we have done started with a surprise. A packaging line with a control PC running an operating system that stopped being supported a decade ago, reachable from any desk in the building. A maintenance laptop plugged permanently into the machine network and also on Wi-Fi. A remote support connection a supplier opened in 2019 and never closed.
An inventory is a day of work and it is the only honest starting point. Anything else is designing for a network you are guessing about.
Segmentation, in the order that works
- Separate the machine network first. Its own segment, its own addressing, its own firewall interface.
- Deny by default, then allow what is needed. Usually a handful of specific flows: a reporting server, a licence check, a supplier connection.
- Remove direct internet access. If a machine needs an update, it goes through a controlled path, not a browser.
- Control supplier access. Remote support enabled on request and closed afterwards, rather than a permanent tunnel nobody monitors.
- Then monitor. Once traffic is separated, unexpected traffic becomes visible, which it never is on a flat network.
Design and management of that sits under managed network, with the security policy under cybersecurity.
What to do about systems that cannot be patched
Compensating controls, which is the polite term for keeping it away from anything that could hurt it. If a control PC cannot be updated, then it should not be reachable from the office network, should not browse the internet, should have no removable media enabled, and should have an image you can restore in an hour.
That last point matters more than people expect. When an unpatched machine does eventually get hit, the recovery path is a restore rather than a clean-up, and if the image does not exist the line stops until the manufacturer can rebuild it. That is a conversation measured in days.
Back up the machine side too
Machine control systems are frequently outside the backup regime because they are not seen as IT. The configuration of a line, the recipes, the calibration data: all of it is unique, none of it is on a shared drive, and the manufacturer usually does not hold a copy.
We treat it the same way as any other system: a copy, an immutable copy, and a restore that has actually been tested. The reasoning is in immutable backup.
Manufacturing is in scope more often than people think
Manufacturing appears in the NIS2 sector list, and so do food and chemicals. Even where an organisation is below the size threshold, supplying an in-scope customer brings the obligations in through the contract.
Segmentation and an inventory are two of the things an auditor asks for first, so the work has value beyond the security benefit. What the evidence looks like is set out in NIS2 in practice.
Questions we get about this
What production and maintenance managers ask.
What do we do about machines that cannot be patched?
Design around it. Keep the machine off the office network and off the internet, disable removable media, control supplier access, and hold a restorable image. You are not going to make an unsupported control system safe; you are going to make it unreachable and recoverable.
Where do we start with OT segmentation?
With an inventory of what is actually connected. On most sites that produces at least one surprise, usually a control system reachable from any desk or a supplier tunnel that was never closed. Design after the inventory, not before.
Do machine systems need backing up?
Yes, and they are frequently missed because they are not seen as IT. Line configuration, recipes and calibration data are unique and the manufacturer usually holds no copy. Without a restorable image, a failure means waiting for a rebuild.
Does NIS2 apply to manufacturing?
Manufacturing is on the sector list, as are food and chemicals. Size thresholds apply, but supplying an in-scope customer brings the obligations in through the contract regardless. Segmentation and an inventory are among the first things an auditor asks about.
Where this lands in our work
Where this work sits.
Want this looked at for your own sites?
Half an hour on a call is usually enough to tell you whether we are the right party for it, and we will say so if we are not.