Secure OT-to-Cloud Architecture: Export Historian, OPC UA and MQTT Data Without Opening an Inbound Path

By Denrich Sananda 26-10-2026 6 min read

Every industrial operator is now being asked to get process data into a cloud analytics or AI platform. The request arrives from operations or a digital team with a business case attached, and the security team's objection is always the same and always correct: the proposed architecture opens a path into the control network, and once that path exists it can be used for more than data export.

The objection is not an argument against cloud analytics. It is an argument against one specific architecture. There are patterns that move process data out without creating an inbound path, and knowing them turns a blocked project into a design decision. Our analysis of how Industry 4.0 expands the OT attack surface covers why this pressure keeps growing.

Why the default architecture is the problem

Most cloud connectors are built for IT environments and assume outbound TLS with a return channel: the agent polls for configuration, acknowledges delivery, receives commands. From a firewall rule perspective it looks outbound-only, which is how it gets approved. In practice it is a bidirectional session initiated from inside your control network to an internet endpoint, and the cloud side can send instructions back down it.

That may be acceptable at Level 3 for a historian replica. It is not acceptable from a control zone, and the distinction gets lost because the rule looks the same in both cases.

Four patterns, ranked by how much they give up

Pattern	How it works	What it costs you
Hardware one-way transfer	A diode moves data from the OT zone to a staging system outside, which forwards to the cloud. No inbound path exists.	No remote configuration, no acknowledgement to the source, no cloud-initiated anything. Highest assurance, least flexibility.
Historian replica in a DMZ	Replicate to a second historian at Level 3.5. Cloud connectors talk only to the replica.	The replica is exposed, and replication is usually bidirectional unless deliberately constrained.
Broker in the DMZ	MQTT broker or OPC UA aggregator at Level 3.5. OT publishes to it, cloud subscribes from it.	Workable and common. The broker becomes a trust boundary you must harden and monitor.
Direct cloud agent on OT	An agent on an OT host connecting straight out.	Simplest and the one to avoid from control zones. The return channel is the exposure.

MQTT and OPC UA are not equivalent here

MQTT is publish-subscribe and naturally one-way at the application layer: a publisher pushes to a broker and does not need anything back. That makes it well suited to a diode or a DMZ broker. OPC UA in its common client-server mode is request-response, so a client outside querying a server inside requires an inbound path. OPC UA does offer a publish-subscribe mode, and if the architecture matters to you, that choice is worth making deliberately rather than inheriting whatever the integrator proposes.

What to decide before anyone builds

Which zone the data actually leaves from. Level 3 historian data and Level 2 control data warrant different answers. See our Purdue model guide.
Whether anything needs to come back. Usually nothing does. Projects assume a return path because the connector has one, not because the use case needs it. Ask the question explicitly.
What the data is worth to an attacker. Process data can reveal production volumes, recipes and capacity. Confidentiality is not usually the driver in OT, but exported data is the exception.
Who owns the DMZ component. A broker or replica at Level 3.5 needs patching, monitoring and an owner. Unowned DMZ infrastructure is how these projects decay.
How you will know it stopped. A one-way feed that silently stops looks identical to a quiet process. Alert on absence.

The AI question, briefly

Cloud AI platforms raise the same architectural question with more commercial pressure behind it. The platform wants a lot of data, often continuously, and vendors frequently propose a direct agent because it is the fastest route to a demonstration. The architecture decision is unchanged: get the data out through a controlled path and accept that the platform cannot reach back. Where a vendor insists on bidirectional access for model deployment or remote tuning, that is a scope conversation, not a security concession.

Why Choose Arista Cyber

We design these paths on live plants and we are candid about what each pattern costs in flexibility, because the cheapest architecture to build is rarely the one you can defend. We supply OWA data diode appliances where hardware enforcement is the right answer, and we will tell you when a hardened DMZ broker is proportionate instead. See our OT cybersecurity services and our case studies.

Next Steps

Establish which zone the data leaves from and whether anything genuinely needs to return. Those two answers eliminate most of the architecture options and turn a stalled approval into a design review.

Common Questions

Can we send OT data to the cloud without opening an inbound path?

Yes. Hardware one-way transfer, a DMZ broker or a historian replica all achieve it. The pattern to avoid from a control zone is a direct cloud agent, because its return channel is the exposure.

Is an outbound-only firewall rule enough?

Not necessarily. Most cloud connectors establish a bidirectional session from inside, which satisfies an outbound rule while still allowing the cloud side to send instructions back.

Is MQTT or OPC UA better for this?

MQTT is publish-subscribe and naturally one-way at the application layer, which suits a diode or DMZ broker. OPC UA client-server is request-response and implies an inbound path, though OPC UA publish-subscribe mode avoids that.

Where should the cloud connector sit?

Outside the control zone, at Level 3.5 or beyond, talking to a replica or broker rather than to production systems. And it needs a named owner for patching and monitoring.

What about cloud AI platforms that want bidirectional access?

Treat that as a scope conversation. Export the data through a controlled path and require the vendor to justify any return channel on the use case rather than on connector convenience.

Blocked on a cloud analytics project?

Arista Cyber designs OT-to-cloud data paths that operations and security can both sign: zone determination, pattern selection, broker or diode architecture and the monitoring that tells you when a one-way feed stops.

Request an OT-to-cloud design review