Securing IT/OT convergence without stopping production

Why IT and OT follow different rules

IT and OT pursue opposing priorities. In classic IT, the order of importance is confidentiality, integrity, availability. In production, this ranking is reversed: availability comes first, because downtime immediately costs money and can create safety risks for people and equipment. A control system cannot simply be restarted for patching, and a maintenance window is often only a few hours per year.

Adding to this are differing lifecycles. While IT systems are renewed every three to five years, plant equipment runs for two decades or more. Many production protocols date from a time when network security was not a design goal: they support neither authentication nor encryption. Merging the IT and OT worlds without accounting for these differences connects a robust manufacturing network to the attack surface of the internet.

The risk of naive convergence

Convergence does not mean merging all networks into one. This very misunderstanding leads to flat networks in which a machine compromised in the office environment can reach all the way through to the control level unimpeded. Secure convergence means the opposite: controlled, deliberately designed coupling of two worlds that remain separate. Data flows to where it is needed, but only through defined, monitored transitions and only in the intended direction.

Four principles for implementation during ongoing operations

1. Visibility before any intervention (passive)

The starting point is a complete picture of the current state: which devices communicate, via which protocols, with whom. The method matters. In OT networks, active scanning, as is common in IT, is dangerous. Older controllers can respond to unexpected requests with malfunctions or crashes. The inventory is therefore carried out passively, by monitoring data traffic without actively intervening in the communication. This creates the foundation for all further steps without endangering production.

2. A target architecture as a frame of reference

Before the first segment is built, the target structure is defined. The Purdue reference model has proven effective as an organising framework, structuring manufacturing into clearly delineated levels, from the sensor and actuator level up to enterprise IT. Between the production level and the enterprise level lies an industrial DMZ (often referred to as level 3.5): a buffer zone in which data is exchanged without creating a direct connection from the office environment to the control system. Complemented by the zone and conduit concept of IEC 62443, this results in an architecture against which every individual restructuring step can be aligned.

3. Data flow instead of network access

For most convergence use cases (key metrics, status data, maintenance information), IT needs to read data from OT but must not gain access to the control system. This directional separation is central. A data historian in the industrial DMZ collects the values, and enterprise IT accesses them exclusively there. Where particularly high requirements apply, unidirectional gateways or data diodes physically enforce data flow in one direction only. The control system thus remains unreachable, even though its data is available.

4. Restructure segment by segment, with a fallback option

The actual separation is not carried out in one major step, but segment by segment. Work begins at the transitions with the highest risk and the least impact on manufacturing, each step is planned into a regular maintenance window, and a defined fallback path is kept ready for every restructuring. Existing redundancies in the plant can be used to make changes to one path while the other continues to support operations. This reduces the risk of unplanned downtime to a manageable level.

A proven migration approach

1. Record. Passive inventory of all devices, communication relationships and existing transitions between IT and OT.
2. Design. Define and document the target architecture with zones, an industrial DMZ and defined data flows.
3. Pilot. Restructure a non-critical area first, validate the approach and test the fallback processes.
4. Roll out. Transfer the architecture to the remaining areas segment by segment, each within maintenance windows and with a fallback option.
5. Monitor. After restructuring, continuously monitor the transitions passively to detect deviations and new communication paths early.

Convergence is also an organisational question

Technical separation alone is not enough if IT and OT managers work past one another. Secure convergence succeeds where both sides share a common target architecture and responsibilities for the transitions are clearly defined: who may change which rule and who decides in the event of a fault. The architecture provides the framework, while coordinated operational responsibility keeps it stable over time. Implemented correctly, convergence not only increases data availability for the company but also enhances the robustness and traceability of the production network.