There is a tension between IT and OT in industrial control systems. Ownership boundaries are defined in terms of machinery operation with priority given to safety and real-time deterministic requirements.
For clarity, we associate IT with vertical data transfer into the enterprise network. By contrast, OT is associated with machinery on the factory floor and machine to machine data transfer.
Key Takeaways
- We have smart hardware that never gets updated (let’s be honest) behind our industrial firewalls. The seemingly secure vertical integration leaks into the horizontal.
- Deterministic machine and process control are non-negotiable.
- OT and IT teams live in a constant state of constructive tension.
- OT interfaces with IT using clear descriptions of PLC buffers and protocols.
This article is part of the DigiKey Field Guide for Industrial Automation
Location: Teach It → Industry Context
Difficulty: 
Engineer — difficulty levels explained
Author: Aaron Dahlen | MSEE | Senior Applications Engineer, DigiKey
Last update: 15 Mar 2026
Figure 1: Workbench image — populated with a safety PLC and safety-rated distributed I/O.
A Linux Host Hiding Behind Your Firewall
Let’s begin our IT vs OT discussion with a scar. Many years ago I worked in a lab that had an advanced GPS receiver connected to a flat network (a common broadcast domain). An outside port was opened for this GPS receiver, allowing timing data to be remotely retrieved. This was a terrible idea from a network security perspective as the GPS receiver contained a small Linux host. With an open port, the remote user could SSH into the GPS and then access the network. Using this technique, Eve and Mallory had internal network access from behind the firewall, as if they had just connected a local laptop to an open network port. That GPS receiver wasn’t a secure piece of hardware, it was an unpatched and unmonitored digital doorway into the network.
Network Classification at the Machine Interface
With regards to networks, we can classify machine control as:
-
Safe: This includes the safety PLCs, light curtains, E-Stops, and networks such as PROFISAFE. This is where we design for the Safety Integrity Level (SIL) or Performance Level (PL) requirements. Any network failure will cause the machine to enter a fail-safe state.
-
Deterministic: This category includes time-critical signals that a machine requires to operate. Ethernet-connected distributed remote I/O (not specifically identified as safety-rated). An example is a central PLC in a distribution center that coordinates the movement of objects on a conveyor. A network failure disables the machine but does not make it unsafe for the operator (when viewed through a SIL/PL lens).
-
Buffered Edge: This class of communication is important but not deterministic. This is where the horizontal factory floor interfaces with the vertical enterprise network. Staying with the conveyor example, the vertical computers provide “what goes where” data. The PLC provides telemetry data for the folks in the control room: job status, speed, rejection, and faults. The use of buffers differentiates between edge and deterministic control. The deterministic signals live close to the PLC scan cycle while edge devices are more tolerant of network fluctuations. A network fault is tolerated and even expected. However, this does not imply network communication is inconsequential as our example conveyor does not move without external instructions.
There is zero room for negotiation when it comes to safety systems. The design as well as the continued maintenance of this reflexive safety network falls squarely on the shoulders of the machine designers including the PLC programmer. This is OT territory. Each hazard must be identified and appropriate SIL/PL mitigation implemented.
The deterministic interface is generally a function of the OT team. This could be visualized as a set of “do upon network failure” settings for the distributed I/O.
In my opinion, the IT and OT edge boundary is best viewed as an agreement on the buffer mechanism (Figure 2). Together, the teams define handshake, retry, network glitch, as well as power-failure protocols. For example, the PLC may store critical messages in a retentive buffer while a larger buffer holds non-critical messages. This article presents a prototype for a PLC-side buffer. Here we can see the essential fields including running sequence number, head and tail pointers, status, and the message buffer itself.
Tech Tip: Version control can be a nightmare for maintenance. This is especially true when there are multiple smart devices on the network. The worst case is when the sensors, switches, and PLC all have different software. Here, technicians must be skilled in all environments and the “golden” configuration files for each device must be independently preserved.
There is a good argument for integrating all machine-programmable hardware into a single software development environment. Yes, this can be expensive, but that cost is amortized across every minute of saved downtime.
Figure 2: Priority ring buffer type definition.
Network Hygiene and Burden of Responsibility
Networks are complex. There is a chasm between just making things work and making things reliable under all conditions including graceful failure when things go wrong. Also, cybersecurity adds to the complexity.
Now consider preferences:
-
The IT instinct tends toward visibility and central control (policy) across the entire infrastructure. IT sees updates as routine.
-
The OT instinct is to lock things down with an emphasis on safety and deterministic communications. OT is deeply suspicious of anything that could potentially impact safety and determinism.
-
Let’s not forget the plant manager and the technicians that repair the machine. When things break, they want the ability to quickly restore the equipment. For example, a layer-3 Ethernet switch controlled from within an integrated software suite such as TIA Portal is easier to handle than a third-party switch.
Rather than point fingers about who is correct, let’s explore this from the burden of responsibility perspective. We have arrived at the edge of human limitations. Yes, in theory, a skilled PLC programmer and OT extraordinaire could claim the entire horizontal OT boundary. IT would be presented with a single semi-isolated port on the PLC. But what about that simple GPS receiver lurking on the network? Does the OT have the necessary skill set to identify and then mitigate all hazards.
Unlikely, and it would take decades to grow that skill set.
Likewise, IT is unlikely to have the skills required to understand the safety and deterministic timing of the PLC-based machinery.
Consequently, we arrive at the disquieting conclusion that OT and IT live in tension. It’s a productive tension that requires the best of both teams. OT preserves the machine’s autonomy via safety and crash-resistant determinism. The teams then work together at the interface level (e.g. buffers) to ensure reliable data transport, sound configuration of infrastructure, and best cybersecurity practices.
Continue Exploring Industrial Control Systems
If this discussion was helpful, you may also want to explore:
DigiKey Navigation
- Full Catalog: Industrial Control & Automation
Related Foundational Articles
About This Author
Aaron Dahlen, LCDR USCG (Ret.), is a Senior Applications Engineer at DigiKey in Thief River Falls. His background in electronics and industrial automation was shaped by a 27-year military career as both technician and engineer, followed by over a decade of teaching.
Dahlen holds an MSEE from Minnesota State University, Mankato. He has taught in an ABET-accredited electrical engineering program, served as coordinator of an electronic engineering technology program, and instructed military technicians in component-level repair.
Today, he has returned to his home in northern Minnesota, completing a decades-long journey that began with a search for capacitors. Read his story here.
