How would you get sensor and production data off the plant floor into a cloud platform without weakening the control network?

Draw the zones before you draw the pipes

The first move is not choosing a protocol. It is establishing which network zones exist, who owns each, and what is allowed to cross. Industrial networks are laid out in layers, an idea from the Purdue reference architecture that ISA-95 carried into how plants are actually built: field devices and controllers at the bottom, supervisory and site operations above them, then enterprise IT, with a demilitarised zone between plant and business. IEC 62443 gives this the vocabulary most teams use — zones grouping assets with a common risk profile, and conduits as the only sanctioned paths between them.

Design against that layout and the shape of the answer falls out. The control zone holds the PLCs and the drives. The supervisory zone holds SCADA and the historian. The DMZ holds exactly the components whose job is to be reachable from both sides — and nothing else. The enterprise zone and the cloud sit outside. Your ingestion path is a chain of hops, each terminating in a zone, and no single flow that traverses the whole stack.

An answer that opens with "we'll put an MQTT client on the PLC and publish to the cloud" has skipped the part being assessed. The protocol is the easy decision. Where the trust boundaries are, and which of them your design causes traffic to cross, is the decision the site's OT team will interrogate.

Why you do not expose a controller

The reason is not that a controller is poorly configured. It is that a controller mostly has nothing to configure. Many industrial protocols authenticate nothing at all: a PLC will faithfully accept a command to change a setpoint, force an output or stop from anyone who can reach its port, because it was designed on the assumption that only a controls engineer standing in the plant could reach it. There is often no user model, no rate limiting, no audit trail, and no concept of an unauthorised request to reject.

Worse, the mitigations you would reach for as a software engineer are unavailable. You cannot patch it on a Tuesday, because patching means stopping production, and the vendor's firmware may be validated as part of a qualified process. You cannot put an agent on it. Some controllers can be knocked out of service by a port scan, because their network stacks were never hardened against traffic they did not expect. A device that fails badly under unexpected input and cannot be updated is a device you protect by controlling what can reach it, not by improving it.

So the security control lives around the device rather than inside it. That is the whole reason segmentation is the discipline of this domain rather than authentication being it.

The direction of initiation is the argument

Here is where an experienced IT engineer's instinct runs backwards. In IT, pull feels safer: a scraper or a poller under your control, with its own schedule, its own credentials and its own back-pressure, beats trusting a fleet of clients to push at you. That instinct is right about data quality and wrong about this boundary, because it silently converts into a firewall rule permitting traffic into the plant.

Any pull from outside means someone opens an inbound path to the zone containing equipment that cannot defend itself, and that path is then available to anything that compromises the puller. It also becomes permanent: the rule outlives the project, the source address broadens, and in two years the plant has an inbound hole nobody can attribute to a requirement.

So on the boundary crossings the plant side initiates, always outbound. Practically that means a gateway or edge collector in the supervisory zone that reads the historian or subscribes to an OPC UA server, and publishes outbound to a broker in the DMZ. From the DMZ, a second component pushes or is bridged onward to the enterprise or the cloud. Nothing outside ever addresses anything inside.

Note that pull is still fine within a zone. A collector polling a historian in the same zone is not a boundary crossing, and that is where you get the scheduling control your instinct wanted. The rule constrains crossings, not every read.

The DMZ is a termination point, not a corridor

The failure that turns a correct-looking diagram into a wrong one is treating the DMZ as somewhere traffic passes through. If a cloud connection terminates on a broker in the DMZ and that same broker holds an open session into the control zone, you have built a proxy from the internet to a PLC with extra hops. The zone boundary is intact on the drawing and gone in practice.

The property to preserve is that each side connects only to the DMZ, and data moves between the two halves by replication rather than by relaying a session. A broker bridge that consumes from the inner broker and republishes to the outer one, or a historian replica that the enterprise reads while the plant instance pushes into it, both satisfy this. Where the risk assessment demands more, a data diode enforces one-way flow in hardware, so no return path exists to be misconfigured.

Two further habits follow. Give the egress path its own credentials with publish-only rights on its own topic space, so a stolen credential cannot subscribe to everything or write a command topic. And keep commands out of the same channel entirely: if the business genuinely needs to send a recipe change down, it becomes a request the plant side polls for and a human or a plant-side service applies, with the MES and the controls team in the loop. The download is authorised inside the plant, not delivered from outside it.

What a plant will actually push back on

Expect three objections, and having answers ready is most of what makes you credible on site. Load: your subscription adds work to a SCADA or OPC UA server that was sized years ago, so agree sampling rates and tag counts rather than subscribing to everything. Change: putting a new gateway in the supervisory zone is itself a change to a running plant and goes through change control, in a window. And the air gap: someone will tell you the network is isolated. It usually is not — there is a vendor modem, an engineering laptop that moves between zones, or a USB workflow — and the honest response is that this is precisely why segmentation and monitored conduits matter more than a belief in isolation.

Get the direction of initiation right and most of the rest is detail. Get it wrong and no amount of encryption makes the design acceptable.