Read-only PLC access: OT/IT segmentation explained

"I don't want anyone touching my PLCs." It's the most direct objection you hear when presenting an industrial gateway to a production manager, and it's a legitimate one: an hour of a stopped production line costs more than any gain a dashboard could promise.

Two answers exist to that objection. The first is a sales pitch: "don't worry about it." The second is technical, verifiable, and it's the only one that holds up in front of an automation engineer who knows their installation.

What "read-only" means at the protocol level

"Read-only" isn't a checkbox in a configuration menu. It's a property of the protocol used for every read:

• Over Modbus TCP, the gateway only ever sends read requests (function codes 01 to 04). Write function codes (05, 06, 15, 16) are never emitted, regardless of how a point is configured.
• Over OPC UA, the session the gateway opens only issues Read calls, never Write.
• Over MQTT, the gateway subscribes to messages the PLC publishes. It publishes nothing back to it.

This isn't a setting that could be disabled by mistake. It's the entire set of operations the agent knows how to perform. Register writes (a "reset faults" command on a PLC, for instance) simply aren't built into the gateway today.

For buses the gateway doesn't natively speak yet (Profinet, EtherNet/IP, EtherCAT, Profibus), the read-only principle doesn't change nature: hardware conversion modules exist from the gateway vendor to bridge these buses into it. That's ongoing integration work, not yet available on every configuration — not to be confused with a write channel that would bypass the constraint described above.

A connection that never originates from the cloud

The second principle concerns the direction of the connection. The gateway always initiates communication toward the cloud, never the reverse. In practice, the gateway calls the cloud to fetch its configuration and send its measurements. The cloud cannot initiate any inbound request to the gateway: no port is open on the OT network side to receive a connection.

This asymmetry has a direct consequence for classic attack scenarios: an intrusion on the cloud side cannot propagate to the OT network through a channel the gateway never opened.

The Purdue model, or why a DMZ exists

The reference model for organizing this kind of separation is the Purdue Enterprise Reference Architecture. It divides an industrial infrastructure into levels, from the field (sensors and actuators, level 0) up to the enterprise information system (level 5), with a demilitarized zone (DMZ) between the industrial levels and the IT levels.

The point isn't to make the two worlds airtight (data has to flow to be useful), but to guarantee that no traffic crosses the boundary without an identified, controlled checkpoint. A gateway that only reads, and that only ever initiates its connection outward, plays exactly that role of a one-way checkpoint.

IEC 62443: a framework, not a label

The IEC 62443 standard governs cybersecurity for industrial automation systems. Its part 2-1 describes what a security program should cover on the operator side: asset identification, access management, network segmentation, monitoring.

It's worth being precise here: IEC 62443 defines a framework of good practices, not a certification Nodal has obtained. The read-only principle and the split into two logical networks apply patterns recommended by this standard. That is not the same thing as an IEC 62443-4-2 certification issued by an accredited body, and no communication from Nodal should imply otherwise.

What this actually changes for your PLC fleet

Two logical network segments structure the installation: a read-only OT segment, where the PLCs live, and a single outbound path to the cloud. The configuration point where this separation actually plays out is simple to verify on the ground: does the gateway need an inbound port open anywhere on the OT network? The answer is no. That answer doesn't depend on any particular setting: it follows directly from how the gateway communicates.

That's something an automation engineer can verify themselves, with a network monitoring tool, rather than having to trust a sales promise.

At the scale of a full installation, this same read-only principle applies regardless of how many PLCs are connected: every measurement follows the same one-way path, from the PLC to the four agents that put it to use.