OT vs IT Networks: Why the Two Teams Clash

A routine scan, a dead chiller

An IT security team runs a standard vulnerability scan across the corporate network one afternoon. Somewhere on a connected segment sits a twelve-year-old chiller controller, and the scan's probing traffic is more than its little network stack can handle. It locks up. The building loses cooling on a hot afternoon, and the facilities team spends two hours working out why, because by every rule the IT team follows, nothing wrong happened. They scanned the network, which is exactly what you're supposed to do.

This is what happens when an OT network gets treated like an IT one. The two look similar, both are made of switches and cables and IP addresses, but they are built on opposite priorities, and the gap between them is where buildings break and teams start to resent each other.

The priorities are inverted

The cleanest way to understand the difference is the order of three words. IT security lives by the CIA triad: Confidentiality, Integrity, Availability, roughly in that order. Protecting data comes first, and a short outage to apply a patch is an acceptable price.

OT flips it. In an operational environment the order is Availability, Integrity, Confidentiality. Keeping the system running comes first, because the system is a physical process, and when it stops the consequences aren't a data breach but a building with no cooling, or worse. As one summary of the divide puts it, Patch Tuesday doesn't exist when downtime costs a fortune per hour. That single inversion explains almost every fight that follows.

Why OT networks are built the way they are

An OT network carries control traffic, and control has rules an office network never worries about.

It has to be deterministic. A command to a valve or a reading from a sensor has to arrive on time, every time. Jitter and latency that nobody would notice on email can throw off a control loop.

It's full of fragile, long-lived devices. Controllers, sensors and older HMIs run for fifteen or twenty years. Many can't run a security agent, can't take a regular patch, and were designed in an era that assumed the network was trusted. You cannot simply reboot one to apply an update without stopping whatever it controls.

It speaks old, open protocols. BACnet and Modbus, the languages of building automation, were built for reliability on a closed network, not for authentication on a hostile one. They often trust any device that can reach them.

To manage this, OT borrowed a mental map called the Purdue Model, which segments a plant into levels from the physical process at the bottom up through control, supervision and site operations, with a DMZ separating all of it from the enterprise IT at the top. The point is to keep the office network and the control network apart, so a problem in one doesn't cascade into the other. It's not a perfect model, but it encodes the instinct correctly: control systems get their own protected space.

Why the two teams clash

Put an IT team and an OT team in charge of the same converged network and the friction is structural, not personal.

Patching. IT patches on a schedule, often weekly, sometimes automatically. OT can't, because patching a live controller usually means rebooting the thing running the building, so updates wait for planned downtime that might be months away. IT sees an unpatched, vulnerable estate. OT sees a system that's working and shouldn't be touched. Both are right.

Scanning and monitoring. The active scans and agents IT relies on to see a network can crash exactly the fragile OT devices they're meant to protect. A tool that's routine on the office network is a live grenade on the control one.

Change cadence. IT improves continuously. OT freezes what works. An IT team pushing frequent changes to a network that controls chillers is, from the OT side, introducing risk for no operational reason.

Ownership, and who wants the headache. Whose network is the BMS even on? In practice the OT side tends to run informally, with its own conventions built up over years and little of it documented to the standard IT expects. Faced with that, an IT department often doesn't want to adopt the mess or the liability that comes with it, so the path of least resistance is separation: wall the control network off from corporate IT and decline to take responsibility for it. The clash here isn't always IT charging in to impose security. Just as often it's IT keeping its distance on purpose, because the OT network is loose and unfamiliar and owning it sounds like nothing but risk.

That arrangement suits everyone right up until a building platform needs to send OT data to the cloud. Now the data has to get out, and IT's instinct, keep it off my network, collides head-on with a need it would rather not own. Meanwhile the dangerous outcome on the OT side is the workaround: when controls feel disruptive they get quietly bypassed, and security gaps open right at the boundary. The stakes are no longer hypothetical for buildings either, the 2024 Johnson Controls ransomware incident disrupted building automation systems, a reminder that the BMS network is now a target, not a backwater.

How to do it without a war

The teams that get this right stop trying to win and start dividing the work along the grain of each world.

- Segment hard. Keep the control network in its own protected zone with a DMZ between it and IT, so the platform reaches data through a controlled boundary rather than sitting flat on the same network as the office printers.
- Don't impose IT patching on OT assets. Where a controller can't be patched, protect it with compensating controls, virtual patching and tight segmentation, rather than forcing a reboot it can't take.
- Read before you write, and connect once. A monitoring platform should take data out through a single, controlled, secure path rather than opening each device to the internet. The fewer things that can touch a controller, the better.
- Let each team own its strength. IT brings security discipline and network rigour. OT brings the knowledge of what must never be interrupted and why. Neither can safely impose its defaults on the other's domain.

This is exactly why a building platform has to be deployed with OT instincts, not IT ones. CobiNeural sits as an overlay that reads existing BMS, PLC and SCADA rather than replacing or destabilising them, keeps deterministic control at the edge where it belongs, and takes data to the cloud over a single controlled connection that can stay off corporate IT entirely, which is the separation the IT team wanted in the first place. The goal is the value of IT, analytics, access, scale, without violating the one rule OT can't bend on, which is that the building keeps running. It's the network-layer version of the same problem we wrote about in building software between OT and IT.

An OT network isn't a worse-managed IT network. It's a different thing with a different first principle, and the buildings that go online safely are the ones whose IT and OT people understood that about each other before they shared a cable. If you're trying to connect a building without putting its control systems at risk, talk to our building automation team.