A ransomware incident does not need to reach a production machine to stop production. If it compromises the office network that hosts your ERP system, engineering files, remote access or shared credentials, the effect can quickly spread to the shop floor. Knowing how to isolate machinery networks is therefore not simply an IT exercise. It is a practical way to protect output, delivery dates and the equipment your business depends on.
For many manufacturers, the challenge is that machinery was installed years ago with limited security in mind. It may use an older operating system, rely on a vendor-managed connection, or communicate with a PC that also has access to business systems. Removing that connectivity overnight is rarely realistic. The right approach is to separate what must be separated, allow only the traffic production genuinely needs, and make changes in a controlled manner.
Why machinery networks need their own boundaries
Office IT and operational technology have different priorities. A finance laptop can usually be patched, restarted or replaced with limited disruption. A machine controller may run a fixed configuration that cannot be changed without supplier approval, testing or a planned shutdown. In some cases, it may be attached to equipment that has been operating reliably for decades.
When both environments share the same flat network, a problem in one can affect the other. Malware can move laterally through shared file shares and credentials. An infected office device may scan or overwhelm industrial equipment. A poorly managed remote-support tool can give an attacker a route into a machine network. Equally, an insecure legacy PC on the shop floor can become a route back into the wider business.
Network isolation reduces that exposure. It also makes faults easier to contain and investigate. If a machine, wireless device or supplier connection behaves unexpectedly, you can limit its reach without taking down every system in the building.
Isolation does not mean making machinery inaccessible. It means deciding precisely who and what should be able to communicate with it. Your ERP or MRP platform may need production status data. A quality system may need access to a specific database. A specialist engineer may need supervised remote support. These requirements can be supported without allowing unrestricted access across the business.
How to isolate machinery networks without stopping production
The safest projects start with visibility, not a firewall rule. Before changing anything, build a clear picture of the equipment, systems and connections involved. This should include PLCs, HMIs, industrial PCs, machine controllers, printers, scanners, Wi-Fi devices, servers, engineering workstations and vendor remote-access tools.
Do not assume the existing network diagram is accurate. In manufacturing environments, equipment is often added during urgent installations, upgrades or repairs. A laptop used for programming may have a direct connection to a machine. A shared PC may run both production software and email. A network switch in a cabinet may serve devices nobody has documented.
Map the traffic that production actually needs
For each machine or production cell, identify what it communicates with, why it communicates, and when. Record the relevant IP addresses, ports, protocols and dependencies. The question is not just, “Can this machine reach the server?” It is, “Which service does it need, and what happens if that connection is interrupted?”
Speak to production, engineering, quality and any machine suppliers while doing this work. The people who use the equipment every day often know which connections are essential, even if they cannot name the underlying protocol. Their input helps prevent a technically neat design that causes an avoidable outage.
It is also worth identifying traffic that is convenient rather than necessary. A shop-floor PC may have open internet access simply because it was connected like any other workstation. That creates risk without necessarily supporting production. Restricting this access is often one of the most valuable early improvements.
Separate office, production and guest traffic
A practical design normally divides the environment into separate network segments, commonly using VLANs and firewall controls. At a minimum, office systems, machinery and guest or personal devices should not share the same unrestricted network.
Larger or more complex sites may need further separation. For example, you might use distinct segments for individual production lines, legacy machinery, engineering workstations, CCTV, warehouse scanners and servers. The right level of separation depends on the consequences of an incident and the way equipment needs to communicate. Splitting every device into its own segment can become difficult to manage; keeping everything together leaves too much exposure.
The key principle is to default to blocking traffic between segments, then permit only the connections that have a defined operational purpose. A production network may be allowed to send data to a manufacturing server, but it should not have unrestricted access to all office devices. An office user may be able to view production reports, but not directly browse a machine controller.
Put a firewall between critical zones
VLANs provide separation, but a properly configured firewall enforces the rules between those areas. It should control traffic between office IT, the machinery network and any more sensitive zones. Rules should be as specific as possible: source, destination, service and purpose.
Avoid broad rules such as allowing an entire office subnet to access the entire shop-floor range. They are quick to create but hard to defend, audit and maintain. Specific rules take more planning, yet they make it far easier to understand how a system is connected and to remove access when it is no longer needed.
Every rule should have an owner and a documented reason. This matters when staff change roles, machinery is replaced or a supplier relationship ends. Forgotten firewall exceptions are a common source of unnecessary risk.
Use a jump machine for engineering and supplier access
Remote access is often necessary, particularly when a machine supplier needs to diagnose a fault quickly. Direct remote connections from the internet to a machine or HMI are not an acceptable long-term arrangement. They are difficult to monitor and can expose critical equipment to compromise.
A jump machine offers a safer alternative. This is a dedicated, tightly controlled workstation used to access the machinery network. Authorised engineers connect to the jump machine using multi-factor authentication, then access only the systems they need. Sessions can be logged, restricted to approved hours and reviewed where appropriate.
The jump machine should not be treated as an ordinary desktop. It needs careful patching, limited software, strong access controls and no casual web browsing or email use. For some environments, supplier access should be enabled only when requested and disabled again once the work is complete.
Deal realistically with legacy equipment
Older equipment is not automatically unsafe, but it does require compensating controls. If a machine runs an unsupported operating system or cannot accept modern endpoint protection, isolation becomes even more important. The aim is to reduce its exposure rather than force a risky upgrade that could affect production.
Place high-risk legacy devices in their own segment where possible. Remove direct internet access, restrict communication to known systems, control USB use and ensure reliable backups exist for machine configurations, recipes and programming files. Keep spare hardware or a recovery plan for critical industrial PCs where replacement would otherwise cause prolonged downtime.
Supplier guidance still matters. Some machinery warranties or CE-compliant operating arrangements may limit what can be changed. A manufacturing-aware IT partner will work with the machine supplier and your engineering team, rather than applying generic office IT controls that jeopardise equipment reliability.
Test, document and monitor the new design
Network isolation should be introduced in phases, ideally during planned maintenance windows. Start with a lower-risk production area, test normal operation and confirm that data flows, printing, reporting and remote support still work as expected. Have a rollback plan before each change.
Once the design is in place, documentation is not optional. Maintain network diagrams, asset records, firewall-rule explanations, supplier-access procedures and recovery instructions. This makes future support faster and provides valuable evidence for Cyber Essentials, ISO-aligned controls and customer security reviews.
Monitoring completes the picture. Unusual traffic between zones, repeated failed logins, unexpected remote sessions and new devices on the machinery network should be investigated early. The purpose is not to generate more alerts for your team. It is to identify the small warning signs before they become a production-stopping incident.
Common mistakes to avoid
The most damaging mistake is treating isolation as a one-off project. Machinery changes, suppliers update systems and temporary workarounds can become permanent connections. Network rules need regular review, particularly after a new machine installation, ERP change or engineering upgrade.
Another is assuming Wi-Fi is separate because it uses a different name. If the wireless network can reach the same internal systems without controls, it may still provide a route into production. Industrial Wi-Fi, handheld scanners and visiting devices need the same deliberate segmentation as wired equipment.
Finally, do not confuse isolation with inconvenience. Staff will find workarounds if legitimate tasks become impossible. A good design protects machinery while giving authorised people a clear, reliable route to do their jobs.
The strongest machinery-network design is one your production and engineering teams can operate with confidence: access is controlled, recovery is planned, and a fault in one part of the business does not have to become a factory-wide interruption.
