Blog

IT vs OT security: why the endpoint model breaks on the factory floor

Written by IXT | 22. sep. 2026, 07:41:50

A patch window that is routine for a laptop fleet halts a production line. That one sentence holds most of the difference between IT security and OT security, and it explains why tools built for the first keep failing in the second.

 

If you run devices that control physical processes, you already know this. The frustration is watching a security programme designed around managed endpoints get applied to a pump controller, a substation RTU, or a fleet of cabinet-mounted gateways spread across four countries.

 

 

What this article covers, and what it does not

This is a technical read on where OT security and industrial IoT security diverge from IT, and what that means for the controls you deploy.

 

It covers the agent assumption, the availability-first priority order in OT, the patching problem, why segmentation moves to the network layer, and where cellular connectivity sits inside the security discussion rather than beside it.

 

It does not claim that network-layer controls remove the need for asset inventory, incident response, or vendor governance. Those stay with you.

 

It does not claim IXT Zero Trust makes you NIS2-compliant. It addresses NIS2 Article 21(2) technical controls. Your compliance posture is still yours to own.

 

 

"The devices cannot defend themselves. They cannot run a client. They cannot flag anomalous behaviour. That has to happen at the network level. That is what we built." Henning Solberg, Founder and CTO, IXT.

 

 

 

 

 

 

 

IoT and OT are not one category

Most security conversations collapse the two. Treating them as one creates blind spots in both directions.

IoT devices connect sensors, appliances and instruments to a network so something gets measured, tracked or reported. An outage costs you data and visibility.

 

OT devices run the physical process. PLCs, RTUs, drives, safety systems, building management controllers. An outage costs you production, or water pressure, or grid stability. The consequence of failure is physical, not informational.

 

The distinction matters when you write policy. An IoT temperature probe tolerates a firmware update and a short reboot. A controller sequencing a batch process tolerates neither during a run, and the vendor warranty conditions are written accordingly.

 

 

The agent assumption

Almost every mature IT security control assumes software running on the endpoint. EDR agents. Patch agents. VPN clients. Certificate stores managed by MDM.

 

Take that assumption into an OT or industrial IoT estate and it collapses on first contact with the hardware. A sensor with 256KB of RAM runs no agent. A PLC certified for a safety function runs only what the vendor certified. A meter in a roadside cabinet has no operating system worth the name.

 

So the endpoint security model has nothing to attach to. Not partially, not with effort. The attachment point does not exist.

 

Two consequences follow for implementers. First, any control that depends on device-side software is out of scope for most of your estate, and pretending otherwise produces a coverage map that flatters you. Second, enforcement has to move somewhere the device cannot refuse it, which means the network path.

 

 

The priority order is inverted

IT security orders its concerns confidentiality, integrity, availability. OT inverts it: availability, integrity, confidentiality.

 

That inversion changes what a reasonable control looks like. An IT team accepts a false positive that quarantines a laptop for an hour. An OT team does not accept a false positive that isolates a controller mid-process, because the failure mode is mechanical.

 

It also changes the patching picture. OT asset lifecycles run 10 to 20 years. Vendor support ends long before the asset does.

 

Recertification after a patch costs real money and a maintenance window you get twice a year. The result is a population of known-vulnerable devices you are not going to patch, and a security model that has to work anyway.

 

Compensating controls are the whole game here. You are not closing the vulnerability. You are removing the path to it.

 

 

Flat networks are the real exposure

Ask what an attacker reaches after compromising one device in your estate. In most OT and industrial IoT deployments the honest answer is a great deal more than that device.

 

Private APNs are common and worth having. They are also frequently misread as a security control. A private APN hides traffic but does not defend it. Inside the APN, devices sit on the same flat network, addressable by each other, with no policy between them. Lateral movement is the whole attack, and a flat network is the environment it was designed for.

 

VPNs create a second version of the same problem, at the human end. A vendor technician with a VPN credential lands on the network, not on the one device they came to service. Eight hardware vendors means eight standing paths into your estate, and an IP conflict conversation every time a new one onboards.

 

Policy-based segmentation is what changes the arithmetic. Each device reaches the one application it needs and nothing else. Least privileged access, applied per device rather than per subnet. A compromise contains to a single asset instead of propagating across the fleet.

 

You cannot segment what you cannot see, which is why traffic mapping comes before policy. IXT Zero Trust Visualisation, built on Illumio, maps traffic across IXT-connected devices in real time and flags anomalous flows. Non-IXT traffic is outside that map, so treat it as one input to your asset picture rather than the whole picture.

 

 

Connectivity is part of the security design

Fixed site infrastructure is the assumption underneath most OT network designs, and in industrial and remote environments it is the weakest assumption in the stack. Wi-Fi coverage in a plant with moving metal. A wired backhaul owned by a landlord. A site network you inherited and cannot audit.

 

Cellular connectivity removes that dependency. The device gets a carrier-grade path that does not rely on infrastructure the operator does not control, and the identity of the device is established at the SIM rather than negotiated later by software the device cannot run.

 

Keep the layers separate when you evaluate this, because vendors blur them. The SIM identifies the device. SecureNet keeps traffic off the public internet through a private APN, private IPs and IPSec tunnels to your data centre or cloud. The Zero Trust layer checks every session in the network and cloud, with no exposed ports and device-initiated traffic only. Monitoring sits above all three, and IXT's CMP shows SIM status, usage and session logs in real time, against the 24 to 48 hour data delay that is common on other platforms.

 

Third-party access gets its own mechanism rather than a VPN credential. Privileged Remote Access gives a vendor a browser session to one device, time-limited, session-recorded, initiated outbound from the Zero Trust Exchange. No client install. No IP conflicts. No network access beyond the asset in question.

 

 

What NIS2 asks for at this layer

NIS2 Article 21(2) lists technical measures including access control, network segmentation, incident detection, supply chain access management and audit trail. IXT Zero Trust addresses those controls at the connectivity layer, and the audit trail covers every device, every user and every third-party contractor that reached a device, with what they did.

 

NIS2 also places accountability at board and C-suite level, which is why this stops being a network engineering discussion at some point in your organisation.

 

What stays with you: risk documentation, incident response plans, staff training, supplier governance frameworks, and any CRA conformity assessment for products you manufacture. No connectivity layer delivers those, and a vendor claiming otherwise is selling you a gap.

 

 

Where to start

Map traffic before writing policy. Segment by application rather than by subnet. Replace standing vendor VPN access with per-session access. Then check what proportion of your estate the endpoint model reaches, and plan the rest at the network layer.

 

 

See it argued properly

Henning Solberg and Trevor Dearing, Director of Critical Infrastructure Solutions at Illumio, go through this in detail on a live webinar: what separates OT and IoT security from IT, what Zero Trust means for devices with no agent, and how AI is compressing the time attackers need once inside.

 

Live webinar, Thursday 8 October 2026 at 10:00 CEST.

 

 

 


 

 

Why trust this guide

This guidance is based on real IoT and OT deployments in regulated industries including energy, utilities, and industrial environments.

 

IXT designs and operates secure connectivity architectures where:

  • devices are deployed across multiple countries and networks
  • SIM-level identity is enforced at the network edge
  • third-party access is controlled without VPNs
  • audit trails are required for regulatory compliance (including NIS2)
  •  

The patterns described here reflect how these environments are secured in practice, not theoretical models.

 

About the author

This article was written by the IXT Connectivity and Security team.

 

IXT operates a full MVNO core network and delivers secure IoT connectivity across 190+ countries and 600+ mobile networks. The team works directly with industrial, utilities, and infrastructure operators to design and secure large-scale IoT and OT deployments.

 

Their focus is on network-level Zero Trust architecture, SIM-based identity, and secure device communication without relying on VPNs or endpoint agents.