Why should IT and OT networks be separated?

The Ethernet port is deceptively democratic. It looks the same on an office printer, an IP camera, a PLC, an inverter and an industrial gateway. That makes it easy to conclude that if every device communicates over Ethernet, they can all safely share the same network.

Technically, that may well work. From a security and operational point of view, however, it is one of the most expensive simplifications a company can make.

The real difference between the office network and the plant network is not the cable—it is the consequence. An infected office laptop can cause data loss and downtime. If a PLC, an inverter, building automation or an energy management system can be reached directly from that same network, a digital incident can also affect physical operations.

A flat network is convenient—until the first incident

In a “flat” network, devices essentially operate in one shared communication space. There is no meaningful separation between office endpoints, servers, cameras, building services and process equipment.

This typically has several consequences:

• an attacker can more easily spread from a compromised endpoint to other systems (lateral movement);
• it becomes harder to say which system should be communicating with what;
• a broadcast storm, a misconfiguration or network overload can also affect operational communications;
• maintenance and remote access can mix with normal traffic without any control;
• during an incident, it is almost impossible to quickly isolate only the affected part.

The problem is not that every attacker is specifically out to overwrite the Modbus registers of a variable-frequency drive. Far more often, a general IT incident reaches systems that should never have been in the same trust domain in the first place.

VLANs matter, but on their own they are not a security strategy

The first sensible step is usually to separate the network logically. Separate VLANs may, for example, be created for:

• office users;
• servers;
• IP cameras;
• building automation;
• energy management devices;
• production or process OT systems;
• management and maintenance access.

But a VLAN is only a boundary. It becomes protection when traffic between zones is handled by a firewall or another controlled gateway that genuinely allows only the communication that is needed.

The goal is not “letting the OT VLAN reach the server”. The right question is:

Which specific device may communicate with which specific target system, over which protocol, in which direction and for what business reason?

For example, a field gateway may send MQTT data to the central processing system, but that does not mean the central network needs direct access to every Modbus device behind it. A reporting application may read historical data without necessarily being authorised to issue control commands.

Zones and controlled connections

One of the fundamental concepts of the IEC 62443 series of standards is partitioning systems into zones and conduits, i.e. the controlled communication connections between those zones. A zone is not simply a VLAN: it is a group of devices and systems that share similar security requirements and a similar risk profile.

In a typical architecture, the following can be handled separately:

1. the corporate IT environment;
2. an intermediate, controlled area between IT and OT (the industrial DMZ);
3. the operational supervision and data processing layer;
4. local controllers and gateways;
5. field devices, meters and actuators.

This is not about drawing more boxes for the sake of a diagram. The aim is to limit the spread of faults and attacks, to make access paths transparent, and to ensure that a failure in one subsystem does not bring down the entire operation.

The quality of the system is decided at the IT–OT boundary

In industrial IoT projects, the gateway often appears as a simple protocol converter: RS-485 or Modbus on one side, Ethernet, MQTT or an API on the other.

In reality, this device is one of the most important meeting points between IT and OT. This is where you can decide:

• whether measurement data should flow outbound only;
• whether control in the reverse direction is needed;
• which commands can be permitted;
• how authentication and encryption should work;
• what should happen if the network goes down;
• which events must be logged;
• how the device can be updated securely.

In the OrigSmart approach, the gateway is therefore not an isolated box but part of the overall data and process architecture. From the field interface through the platform to the business process, we design together where data originates, where decisions are made and from where a safe intervention can be issued.

Availability does not mean unrestricted access

In an OT environment, it is a legitimate expectation that the process keeps running safely even if the network or a central system fails. That does not mean, however, that everything needs to reach everything else.

Quite the opposite: a good architecture reduces unnecessary dependencies. Local control stays local, the required data moves on through a controlled channel, central outages are handled by buffering and deferred synchronisation, and remote access is controlled and logged.

Segmentation is therefore not an obstacle to reliable operation but a precondition for it.

Sources

• NIST SP 800-82 Rev. 3 – Guide to Operational Technology Security
• ISA/IEC 62443 Series of Standards
• Phoenix Contact – Our mission: a secure OT network (in Hungarian)
• OrigSmart – Web-based business operating system