OT and IT convergence: two professions with opposite instincts sharing one set of networks

Two professions trained on different failures

A security engineer is measured on exposure, currency and recovery. A controls engineer is measured on availability and on the process behaving as designed. Both positions are correct inside their own domain and produce opposite behaviour at the boundary between them. The controls instinct is that nothing changes without a tested reason; the security instinct is that nothing should stay unchanged for long. Recognising this as a legitimate difference rather than obstruction is the precondition for joint working, because the alternative is each side quietly bypassing the other, which yields undocumented networks and unpatched machines at the same time.

Change control that collides

Corporate change management runs on maintenance windows and automated deployment. Plant change management runs on shutdowns, risk assessment and a return-to-service test. A switch configuration pushed overnight can drop a control network; an agent update can delay a time-sensitive protocol enough to fault a drive. The remedy is procedural rather than technical: identify which equipment falls inside the production change process, exclude it from automatic deployment, and give it a scheduled route through shutdown planning. That route must be real, because equipment excluded from patching with no alternative plan simply never gets updated at all.

The machine computer that belongs to nobody

Every site has assets belonging to no one. The computer inside a packaging line came with the machine, never appeared on the corporate inventory, was never joined to any domain, and runs software the builder supports. It is invisible to information technology and considered part of the machine by production. Such assets carry disproportionate risk and disproportionate downtime. Building one inventory covering everything with a processor and a network port, each entry carrying a named owner and its support arrangement, is unglamorous work that settles more arguments than any technology choice the two departments will make together.

Data flowing up is far easier than control flowing down

Sending machine data upward for reporting is comparatively simple and low consequence: a read-only feed, one direction, nothing physical happens if it stops. Sending instructions downward is a different proposition, because a system now influences what equipment does, and the failure modes include producing the wrong thing perfectly safely. Requirements tighten accordingly: validated interfaces, defined behaviour when the link drops, an operator able to override, and a settled authority over the machine when two systems disagree. Approve the two directions as separate pieces of work, since agreeing the easy one rarely means the harder one is understood.

What actually makes the arrangement work

A shared inventory, a joint change board with authority over both estates, and agreed vocabulary. The last matters more than it sounds: critical, urgent and outage mean different things on each side, and incident severity definitions written for information systems give absurd results applied to a furnace. Sites that manage this usually create a role standing between the two, an engineer fluent in both networks and process, and give that person a seat at the change board. Make on-call arrangements joint as well, so nobody discovers at three in the morning that the other side has no obligation to answer.

Frequently asked questions

Should corporate IT manage the plant networks?

Ownership can sit on either side provided the constraints are respected, and a shared model usually works best: the corporate team supplies standards, tooling and expertise, while the plant keeps authority over anything able to stop production. A straight handover in either direction fails. Given entirely to corporate, plant realities get overridden; left entirely with engineering, the network ends up undocumented and unmonitored. Write the division of authority down, including who may make a change while production is running.

What should the two sides fix first?

One asset inventory covering everything with a processor and a connection, each entry carrying an owner and its support position. It is dull work and it settles most later disputes, because both sides then argue from a shared list rather than from their own. The exercise also reliably surfaces the remote connections, undocumented switches and machines nobody claims, which tend to be both the largest security gaps and a recurring source of unexplained stoppages.

Why does standard corporate patching cause trouble on the floor?

Because it assumes a reboot is cheap and a brief outage is tolerable. On plant equipment a reboot may require the process to be stopped, may need a controlled restart sequence, and in some cases disturbs a supported or validated configuration. Automatic deployment also arrives with no knowledge of what is running. The workable arrangement excludes plant equipment from automatic deployment and routes it through shutdown planning, so updates still happen at a moment production has agreed to.