Zero Trust in OT: Segmentation and Detection in Industrial Networks

Zero trust in OT is not about installing agents on every PLC or demanding two-factor authentication from an automation controller. It is about no longer assuming that everything inside the plant network can be trusted: segmenting the network into zones with controlled conduits (the IEC 62443 model), granting remote access per identity and per session instead of through an open VPN, and watching the traffic with passive detection that puts no production at risk. What follows grounds that principle in a real plant, with twenty-year-old equipment that cannot be patched like a laptop.

What zero trust means on an industrial network

The term zero trust was born in the IT world and became mainstream with NIST SP 800-207, which defines it as an architecture in which no connection is considered trustworthy merely because it originates inside the perimeter. Every access is verified: who it is, from where, to which resource and with what least privilege. In an office that translates into federated identity, managed devices and per-application policies.

Carrying that idea into an industrial network requires an honest translation. A PLC cannot run an endpoint agent, a drive knows nothing about certificates rotated every 90 days, and a large share of shop floor protocols (Modbus TCP, PROFINET, EtherNet/IP in their classic versions) travel without authentication or encryption because they were designed for isolated networks. Zero trust in OT does not mean forcing those controls where they do not fit: it means applying the principle with the instruments the plant does accept. In practice, three:

• Segmentation: dividing the network into small zones and explicitly controlling what may cross from one to another. If the PLC cannot defend itself, let the network defend it.
• Access by identity and by session: every remote connection to a plant asset is granted to a specific person, for a specific asset, during a specific window, and it is logged.
• Continuous visibility: an inventory of what is connected and traffic monitoring to detect behaviour that departs from the usual pattern, without interfering with the process.

To keep it concrete, we will use one example throughout the article: a plastic injection moulding plant with 14 machines, each with its own PLC, two robotic cells, a SCADA in the control room and an external systems integrator who services the injection machines via remote access. It is an ordinary case and it contains every problem we are going to cover.

Why a plant is not protected like an office

The first reaction of many IT managers on taking over plant security is to apply the familiar playbook: antivirus, monthly patching, vulnerability scans. In OT that playbook fails for structural reasons, not because shop floor staff are careless.

The consequence is direct: in OT, control shifts from the device to the network. Since the endpoint cannot be hardened, what surrounds it is hardened instead. That is why segmentation is not just another item in a catalogue but the measure on which all the others rest. And that is why it should be designed alongside the connectivity architecture: how data is collected from the PLCs conditions which conduits are needed, as seen in our work on PLC connectivity.

Segmentation: zones and conduits under IEC 62443

The IEC 62443 series is the reference framework for cybersecurity in industrial automation systems, and its most useful contribution at the architecture level is a vocabulary: zones and conduits. A zone is a set of assets sharing security requirements; a conduit is the defined, controlled communication channel connecting two zones. Anything that does not pass through a declared conduit must not be able to pass at all.

The criterion for grouping assets into zones is neither physical topology nor cabling convenience, but the question: which assets should fall together if something goes wrong? In our injection moulding plant, a reasonable design would be:

• One zone per production cell: each injection machine with its PLC, its HMI and its peripherals forms a zone of its own (or machines are grouped by line if they share a process). If one machine is compromised, the incident does not spread to the other thirteen.
• Supervision zone: the SCADA, the historian and the engineering workstations. It talks to the cell zones through conduits carrying only the strictly necessary protocols.
• Industrial demilitarised zone (iDMZ): the boundary between plant and corporate network. No flow goes straight from IT to a PLC: it passes through intermediaries in the iDMZ (a data broker, a jump server, a patch repository).
• Remote access zone: the single point through which the integrator and the plant's own staff enter when working from outside, discussed further below.

Conduits are materialised with industrial firewalls or access control lists on managed switches, with rules written in the positive: what is listed is allowed and everything else is denied. A typical conduit rule between the supervision zone and a cell would be: the SCADA (one specific IP address) may read from the PLC (another specific IP address) on the supervision protocol port, and nothing else. IEC 62443-3-2 formalises this exercise as a per-zone risk assessment that assigns each zone a target security level; for a first iteration the principle is enough: small zones, explicit conduits, deny by default between zones.

One rarely advertised benefit: the exercise of defining conduits forces an inventory of what talks to what, and that inventory tends to uncover surprises. In real plants there turn out to be direct connections from office workstations to PLCs, vendor access nobody remembered and obsolete protocols still active. That alone makes the exercise worthwhile.

From the Purdue model to real segmentation

The Purdue model (whose hierarchy was later adopted by ISA-95) arranges the plant into levels: process and instrumentation at the bottom, control above it, supervision above control, manufacturing operations and, at the very top, the corporate systems. For years, OT security doctrine was a literal reading of that diagram: a firewall between every level and communication only between adjacent levels.

That reading is still a good starting point, but modern data architectures put it under strain. When the plant publishes telemetry through an edge gateway and an MQTT broker (with Sparkplug B or another payload convention), the data no longer climbs step by step: the gateway reads from the PLCs and publishes towards a broker that may sit in the iDMZ or in the cloud. Far from breaking segmentation, this pattern favours it when designed well, because the traffic becomes unidirectional from the inside out: the gateway initiates all outbound connections and no external system needs to open sessions towards the control network. The broker in the iDMZ acts as the single, auditable conduit between the plant and the data consumers.

The operating rule that sums up both: Purdue to think about the boundaries, zones and conduits to draw them, and plant-initiated outbound flows whenever the use case allows it. For the data architecture side, the pillar on OT/IT integration develops how that bridge is built without opening the control network.

Secure remote access to the plant

Remote access is by far the most common entry path for OT incidents, and also the hardest to eliminate: the integrator at our injection moulding plant needs to get in to diagnose faults, and denying that access costs hours of downtime. The problem is not that access exists; it is how it tends to be set up. The patterns worth eradicating:

• A corporate VPN that, once inside, gives flat visibility of the entire plant network.
• 3G/4G routers that machine builders install on their equipment, creating back doors outside all control of the plant owner.
• Shared credentials of the "maintenance" kind used by several external companies and rotated by nobody.
• Remote desktops exposed directly to the internet, with or without a VPN in front.

The zero trust pattern for industrial remote access rests on four pieces:

1. Single point of entry: all external access goes through a jump host or access gateway located in the iDMZ. The vendors' cellular routers are removed or isolated.
2. Named identity with two-factor authentication: every external technician has their own account. Strong authentication is enforced at the gateway, not at the PLC, which would not know how to apply it.
3. Per-session, per-asset authorisation: access is granted for a specific intervention on a specific machine, ideally with prior approval from someone at the plant, and it expires on its own. Outside an approved session, the conduit is closed.
4. Logging and recording: the gateway leaves a trace of who entered, when and to which asset and, in demanding environments, records the session. When a machine is left misconfigured after an intervention, that trace is worth gold.

At the example plant, the change is tangible: the integrator goes from having a VPN that sees all 14 machines to requesting a session on injection machine 7, receiving approval from the shift manager and working within a two-hour window that is logged. The service the plant receives is the same; the exposed surface, a fraction.

Threat detection: passive versus active

Segmenting and controlling access reduces the probability of an incident; detecting it in time reduces its cost. In OT, monitoring has a starting constraint that does not exist in IT: the security tool itself must never become a risk to the process. Hence the central distinction between passive and active detection.

Passive detection fits naturally with segmentation: the places worth listening to are precisely the conduits between zones, because all lateral movement passes through them. In industrial networks, moreover, the traffic is extraordinarily regular (the same devices talking to the same devices, with the same protocols, in fixed cycles), which makes deviations stand out far more than on an office network. A write request to the PLC of injection machine 7 from an address that had never written before is a textbook alert, and a passive system sees it without having touched the process.

On active detection it is worth being clear: it has value (a passive inventory only sees what talks, and a silent device can go unnoticed), but it must earn the right to be used. Passive visibility first, then selective active queries using the vendor's native protocols, never a generalist IT scanner launched against the control network.

Living with legacy equipment

Every plant with a history has equipment no security guide accounts for: a PLC from the nineties controlling a perfectly productive machine, an industrial PC running Windows XP because the machine's software runs on nothing newer, a serial gateway translating a proprietary protocol. Replacing them for security reasons rarely survives a cost analysis, and the zero trust approach does not demand it. It demands treating them as what they are: assets that cannot defend themselves and must be defended from the outside.

The usual compensating measures, from least to most effort:

1. A micro-zone of its own: the legacy asset is enclosed in the smallest possible zone, with a minimal conduit. The XP machine at our plant only needs to talk to its machine and receive programs from the engineering workstation: two rules, everything else closed.
2. Harden the environment, not the device: disable unused ports on the switch it connects to, pin its physical address, remove the internet access it should never have had.
3. Protocol gateways: interpose a modern device that speaks the old protocol inwards and a secure one outwards, so the exposed stretch is encrypted and authenticated even though the final stretch cannot be.
4. Data diodes or unidirectional gateways: when a critical zone only needs information extracted from it (history, telemetry), a physically unidirectional link eliminates the return path by construction. It is the expensive option, common in regulated sectors.
5. Reinforced monitoring: precisely because the asset cannot be patched, its traffic is watched more closely than the rest.

Honesty matters here: a plant with well-segmented, well-monitored legacy equipment is safer than a plant with modern equipment on a flat network. The state of the machine fleet conditions the effort, not the feasibility.

Phased roadmap

None of the above is deployed in a weekend, and pretending otherwise is the best way to stop production. A reasonable sequence for a mid-sized plant:

1. Visibility (weeks): asset inventory and communications map, obtained through passive discovery. Without this step, any firewall rule is a gamble.
2. IT/OT boundary (weeks to months): stand up the iDMZ, cut the direct flows between corporate and control networks, and channel remote access through the gateway with named identities. It is the step with the best ratio of effort to risk avoided.
3. Internal segmentation (months): define zones and conduits and roll them out in stages, starting in monitor mode (the rule logs what it would block without blocking it) and switching to enforcement once the traffic map confirms nothing breaks.
4. Detection and response (continuous): permanent passive monitoring on the conduits, alerts integrated with whoever will act on them and response procedures that reflect plant reality (who gets called at three in the morning and what can be switched off without damaging the process).

This technical journey also has a regulatory dimension: for many European industrial companies, the NIS2 directive turns a good part of these measures into a legal obligation, with requirements on risk management, incident reporting and management accountability. That angle, who is in scope and how to sequence compliance, is covered in the pillar on NIS2 and OT cybersecurity.

Frequently asked questions

At Captia Connect we design industrial connectivity architectures where security is not an afterthought: segmentation, remote access and data publication are conceived together. If you are working out how to put your plant network in order, the Captia Connect page shows how we work, and the industrial data platform shows how that segmented network underpins data acquisition and publication.