Operational technology: computers whose output is physics

Operational technology is the hardware and software that monitors and controls physical equipment and processes. The shortest useful definition is the one I keep coming back to: OT is computers whose output is physics.

An IT system’s job ends when the right information reaches the right person. An OT system’s job ends when a valve moves, a motor holds speed, a reaction stays inside its envelope. That single difference in what “output” means generates two different engineering cultures, two different risk models, and — for most of the last forty years — two networks that barely spoke to each other.

I administered both at once for four years: the office network and the process-control network of a petrochemical plant. This page is the orientation I give anyone crossing between those worlds, in either direction.

What counts as OT

The term covers more territory than the factory-floor stereotype suggests:

• Process control: PLCs, RTUs, and DCS platforms executing control loops; the SCADA and HMI layer where operators supervise them. This is the core, and SCADA security is its own discipline within the field.
• Safety systems: safety instrumented systems and emergency shutdown logic — deliberately separate from control, because they are the layer that acts when control fails.
• Industrial networks: plant Ethernet, fieldbuses, serial runs, radio and cellular links, carrying protocols largely designed without authentication.
• Everything adjacent: building automation, power distribution monitoring, tank gauging, laboratory instruments, physical access systems. Anything where software touches actuators or reads the physical world at operational timescales.

A useful test: if it fails, does something physical happen or fail to happen? If yes, it is OT, whatever the badge on the chassis says — and it deserves OT handling.

The divide is real, and both sides are right

The OT/IT split gets narrated as a technology gap. It is mostly a difference in what each side has been burned by.

IT culture formed around information risk. Data breaches, not explosions. So it optimizes for confidentiality, moves fast on patches, and treats a reboot as a routine tool. OT culture formed around process risk. Its formative disasters involved pressure vessels, not databases. So it optimizes for stability, treats any change as guilty until proven safe, and regards an unplanned reboot as an incident in itself.

Neither instinct is wrong. Each is correct locally.

I felt the difference in my own hands. On the office network I would patch a server at lunch and think nothing of it. On the control side, the same action required a plan, a review, a window, and a rollback path — and the first few times that felt like bureaucracy. Then I understood what the process engineers already knew: the office network’s worst case was an afternoon of complaints, and the control network’s worst case was not. The caution was not culture for its own sake. It was an accurate price signal.

The technical differences follow from the cultural ones. Asset lifecycles of 15 to 30 years, because equipment is qualified against the process and re-validation is expensive. Patch cycles measured in maintenance windows, not Tuesdays. Protocols — Modbus, DNP3, a long tail of vendor variants — that trust the wire completely, which makes the network the security boundary. Devices that can wedge under an ordinary port scan. The practical consequences for defenders are laid out in ICS security fundamentals; the short version is that every IT reflex must be re-qualified before it touches a control network.

For decades the two cultures coexisted by not touching. The reference architecture that formalized the separation — layered zones from field devices up to enterprise systems — still shapes how plants are drawn today, and the Purdue model in modern OT examines what remains of it now that the clean layers have holes in them.

The convergence pressures

The isolation is ending. Not because anyone decided the old model was wrong, but because three pressures each carry real business value, and value finds a path.

Data. The process historian used to be the only bridge: process data went up, nothing came down. Now planning systems, quality analytics, and corporate dashboards want continuous plant data, and cloud platforms want to store and model it. Every one of those flows is a connection that did not exist in the reference drawings.

Remote access. Vendors support turbines and analyzers from other continents. Integrators commission systems without site visits. Engineers on call at 2 AM want to check an alarm without driving in. Each convenience is defensible; the accumulation, undesigned, is how plants end up with a dozen ungoverned tunnels. The pattern that makes this survivable is brokered access, detailed in OT remote access architecture.

AI and analytics. Predictive maintenance, process optimization, anomaly detection — the models are genuinely useful, and they are hungry. They want high-resolution data out of the plant, and increasingly their operators want recommendations, or actions, flowing back in. AI is software; software requires engineering, governance, and operational controls. In OT the return path deserves the most scrutiny it will ever get, because a model’s bad day becomes an actuator’s bad day.

The mature response to all three is the same: stop pretending the boundary can be preserved intact, and start engineering it deliberately — enumerated flows, brokered access, one-way transfer where the value only moves one direction. That is a strategy problem before it is a firewall problem, and OT/IT convergence strategy treats it at that altitude.

The discipline map

OT as a field decomposes into a handful of subdisciplines. Here is how they relate, which is also how this site’s cluster is organized:

Subdiscipline	The question it answers	Where it’s covered
Fundamentals	Why OT demands different instincts	ICS security fundamentals
Threat intelligence	Who actually attacks control systems	The ICS threat landscape
Supervisory security	Protecting the SCADA layer specifically	SCADA security
Network architecture	Zones, conduits, and enforceable boundaries	SCADA network design
Access engineering	Letting the right people in, recorded	OT remote access architecture
Convergence strategy	Connecting OT and IT without merging their risks	OT/IT convergence strategy
Societal stakes	Why regulators and states care	Critical infrastructure protection

The last row deserves a note. Most OT runs infrastructure the public depends on — power, water, fuel, food. That is why the field carries regulatory weight IT rarely sees, and why national agencies publish advisories about controller firmware. The stakes section of the map is covered in critical infrastructure protection.

What ties the subdisciplines together is a shared method: reason from consequence backward. Not “what data is at risk” but “what physical event must never happen, and what paths could cause it.” Once that habit is installed, the rest of the field is detail.

What each side should learn from the other

Convergence is usually framed as OT’s remediation project. Four years of running both networks left me convinced the learning runs both ways.

IT should take from OT: change discipline that treats production as sacred, the pre-job walkthrough, the assumption that any modification can have consequences beyond its intent. The plant habit of asking “what does this do to the process?” before touching anything is just operational maturity, and most enterprise outages trace to its absence.

OT should take from IT: identity as a first-class control, telemetry as a default rather than an afterthought, and the honest admission that “isolated” networks stopped being isolated years ago. Shared accounts and unmonitored links were tolerable when the network was truly closed. It is not.

The plants that handle convergence well are not the ones with the biggest security budgets. They are the ones where a control engineer and a network engineer can sit in the same room and each explain the other’s worst-case scenario.

Where to go deeper

The reading path through the cluster, in the order I would assign it:

• ICS security fundamentals — the ground truth about how control systems behave. Start here.
• SCADA security — the head-term pillar for the supervisory layer: threat model and control set.
• The Purdue model in modern OT — the reference architecture and its modern exceptions.
• OT/IT convergence strategy — the boundary as a designed system rather than an accident.
• OT remote access architecture — the single control that most changes real-world OT risk.
• Critical infrastructure protection — the regulatory and societal frame around all of it.
• OT network reference architecture — the target-state diagram, for when you are ready to build.

The lasting distinction

Vendors will keep announcing that OT and IT have converged, usually while selling the connective tissue. The networks are converging; the disciplines are not, and should not. As long as some computers produce information and others produce physical consequences, the second kind will demand its own engineering culture — slower to change, harder to impress, and correct to be both. The tooling will keep merging. The respect for consequence is the part that must never converge away.