OT and IT Security Are Different Disciplines Sharing a Network
The first time an authenticated vulnerability scan takes down a production line, the argument about whether operational technology and information technology are different stops being theoretical. A junior SOC analyst runs a standard sweep across a newly discovered subnet. The scanner probes an older TCP/IP stack on a programmable logic controller running a packaging line. The controller’s network buffer overloads, the device halts, and the physical line stops. The scanner reports success. The plant loses a weekend of production while engineers fly in to manually reset the system.
This happens because the two environments operate under different physical and economic constraints. In corporate IT, if a system detects an anomaly, the default safe state is to isolate the machine and lock the user out. On a manufacturing floor, locking an operator out of a control system during a pressure spike creates a physical hazard. Availability comes first.
IT security assumes an endpoint is an endpoint. Installing a standard endpoint detection and response agent on a Windows-based human-machine interface doesn’t just risk blue-screening the machine; it usually voids the original equipment manufacturer support contract for a multi-million-dollar piece of capital equipment. A patch deadline in IT does not create a shutdown window in OT. A patch window on the plant floor is a scheduled production event planned months out, requiring a stopped line, vendor support on the phone, and a tested rollback plan.
Who owns the OT network?
The core conflict is rarely technical. It is about who has the authority to say no. The CISO owns the enterprise risk, but the plant manager owns the profit and loss and the safety record. If IT security can force a patch that takes a line offline, they own the production loss. If the plant manager can veto any security control, they own the ransomware risk.
You have three structural options for ownership, depending on your organization’s size and maturity.
- IT owns it, OT has a dotted line. This works when IT has a dedicated OT security function with actual plant experience. It fails when IT treats the plant floor as just another subset of the corporate network and tries to enforce standard endpoint policies.
- OT owns it, IT provides standards and tooling. This works when you have many plants, the OT engineering team is strong, and IT can supply passive monitoring and identity management without touching the process. It fails when OT has no security headcount and IT loses all visibility into the environment.
- Joint ownership with a named accountable executive. This works only if that person controls the downtime budget or has the authority to force a production stop. Otherwise, it is just a committee that meets quarterly and decides nothing.
The useful test for any of these models is simple: who can approve or stop an active scan, a firewall rule change, or a firmware update? If the answer is a committee, the committee will meet after the outage.
How far do you segment?
Plant managers will often claim the OT network is airgapped. It isn’t. There is always a vendor logging in via a cellular modem to pull diagnostics, an engineer walking across the floor with a USB drive, or a legacy historian database dual-homed to the corporate network so executives can see production dashboards. The IT/OT boundary at most plants is a firewall that exists on a Visio diagram and a workstation with two network cards that everyone pretends not to see.
Because you cannot control the endpoint due to age, warranty constraints, or fragility, all security must be enforced at the network layer. You have to decide how far to segment.
- Full Purdue model segmentation. This is the correct target for most plants. It requires capital, downtime, and a designated firewall owner for every cell and zone boundary. It is usually a multi-year program.
- Targeted segmentation around the riskiest paths. You focus first on vendor remote access, engineering workstations, and the IT/OT boundary. This is cheaper, faster, and buys credibility with the plant operations team.
- Flat network with a monitored boundary. This is acceptable as an interim state only if you have passive monitoring and a documented plan. It is not acceptable as a destination.
The direction you push depends on the cost of downtime per hour, whether the equipment vendors support network changes, and whether the plant actually has a maintenance window you can use to install the new switches.
What security tooling is safe to deploy?
Visibility in IT means polling the endpoint. Visibility in OT means watching the wire and staying out of the way. Standard IT asset management relies on active polling. OT network stacks, running protocols like Modbus or Profinet, were not designed for hostile or malformed traffic. A scan is not read-only to a device that assumes every packet is well-formed.
When selecting tooling, you must match the mechanism to the device criticality and vendor support terms.
- Passive monitoring and network taps. Safe in almost all environments. No packets are injected. This is the correct starting point for asset discovery and anomaly detection.
- Protocol-aware OT intrusion detection. Safe when it is passive and tuned. It requires OT protocol expertise to interpret the alerts.
- Agent-based endpoint detection. Fine on Level 3 systems like site operations servers, historians, and jump hosts, provided the OEM explicitly supports it. Not fine on controllers, panel PCs running vendor images, or anything with a safety certification.
- Active scanning. Only deploy with vendor approval, inside a scheduled window, on a representative spare device first. Never run it on a production line without a rollback plan.
If the vendor says no agent, you do not force the agent. You wrap the unpatchable legacy system in network controls. You put a dedicated industrial firewall in front of it, restrict its communication strictly to the specific IP addresses it needs to function, and block all outbound internet access.
Exceptions will happen. A shared local admin password across forty human-machine interfaces, written on a laminated card in the control room, is often not laziness. It is what happens when changing the password breaks the vendor’s recipe push and nobody has the authority to accept the downtime to fix it. Treat it as a risk with a cost. Document the decision, name the owner, and apply a compensating control like network segmentation.
Similarly, a vendor’s need to repair one machine is not a reason to give its VPN account the whole plant. Remote access should terminate in the IT network, pass through a dedicated jump host in the industrial DMZ with mandatory multi-factor authentication, and expire when the work is done.
A patch deadline does not create a shutdown window, so the security architecture is ultimately defined by the plant maintenance schedule.
Takeaways
- Ownership models for OT security depend on who can approve or stop an active scan, firewall change, or firmware update.
- Segmentation decisions hinge on downtime cost, vendor support, and maintenance windows.
- Passive monitoring is the safe starting point; active scanning and agents require vendor approval and rollback plans.
Questions
- Who should own OT security: IT or the plant operations team?
- It depends on the organization. IT ownership works when there is a dedicated OT security function with plant experience. OT ownership works when the engineering team is strong and IT can supply passive monitoring and identity management. Joint ownership only works if a named executive controls the downtime budget.
- Why can't you run standard vulnerability scans on an OT network?
- OT devices often run older TCP/IP stacks and protocols like Modbus or Profinet that assume every packet is well-formed. A scan can overload a controller's network buffer, halt the device, and stop a production line. Active scanning requires vendor approval, a scheduled window, and a tested rollback plan.
- How do you secure unpatchable legacy OT systems?
- Wrap them in network controls: put a dedicated industrial firewall in front of the system, restrict communication to the specific IP addresses it needs, and block all outbound internet access. Document the risk, name the owner, and apply compensating controls like segmentation.