Sending OT Data to the Cloud Without Inbound Exposure

01Key takeaways

1. 01

   OT cloud connectivity should be designed as outbound publication, not as a bidirectional API connection into the plant.

2. 02

   Inbound exposure is the core risk: any listening port, return session or cloud-initiated command path on the OT side is a foothold worth removing.

3. 03

   Outbound-only push patterns, brokers in a DMZ, and one-way hardware transfer each reduce reachability in a different way, and they compose well.

4. 04

   A data diode or unidirectional gateway can enforce that a cloud-facing conduit is physically publication-only, even if the cloud side is compromised.

5. 05

   Cloud connectivity does not remove the need for segmentation, asset inventory, identity, monitoring and a clear answer to how cloud commands, if any, ever reach the field.

02What OT cloud connectivity actually means

OT cloud connectivity is the set of architectures and controls used to move operational technology data from a plant, substation, pipeline or fleet into a cloud platform. The data is usually telemetry: sensor readings, alarms, events, process variables, runtime counters, historian extracts and asset health metrics. The destination is usually an IIoT platform, a time-series database, a data lake or a vendor analytics service.

The phrase hides an important design choice. Connectivity can mean a two-way connection where the cloud can also reach into the OT environment, or it can mean a one-way export where data leaves and nothing comes back. Those are very different risk postures even though both are called cloud connectivity.

The safest default for OT cloud connectivity is outbound publication: the field publishes data, and the cloud is never able to initiate a session, command or query back through that path.

03Why inbound exposure is the risk that matters

An inbound path is a path an attacker can use. If a cloud platform, a remote vendor or the internet can open a session into the OT network, then a compromise of that platform, a stolen credential or a supply-chain incident becomes a route to the control system. Many ICS intrusions begin with a legitimate remote-access channel that was trusted more than it should have been.

OT systems make this worse than typical IT. Controllers and field devices often have long lifecycles, sparse patching, weak or absent authentication on native protocols, and a direct relationship to physical process and safety. Reducing reachability is frequently more achievable than hardening every device. So the most durable cloud-connectivity controls focus on removing the inbound path rather than only filtering it.

• A listening service on the OT side, such as an exposed broker or remote-management agent, is a target for exploitation and brute force.
• A cloud-initiated command channel can be abused for remote control if the cloud tenant or its credentials are compromised.
• Return sessions from the cloud can carry command-and-control traffic that blends with expected management activity.
• Firewall rules that permit return traffic drift over time and quietly widen the conduit.
• Shared management or update channels can reintroduce an inbound route that the main data path was designed to avoid.

04Push, not pull: the outbound-only principle

The foundational pattern is to make the OT side the initiator and the publisher, never the listener. The field device or an edge gateway opens an outbound connection to the cloud, authenticates, and pushes data. The OT network exposes no inbound listening port to the cloud or the internet. Stateful firewalls then permit only the established outbound flow and its responses, not new inbound sessions.

This is the model behind most managed IIoT services and behind MQTT-style telemetry. A client inside the network connects out to a broker or ingestion endpoint over TLS and publishes messages. Because the session is client-initiated and outbound, there is no inbound port to scan or exploit. Outbound TLS with mutual certificate authentication is the realistic baseline, but on its own it is still a software control: the connection is technically capable of carrying return data, and a compromised broker or client can be told to do more.

Outbound-only push removes the inbound listener. It does not by itself remove the logical possibility of return traffic over the established session. That gap is exactly where one-way hardware transfer adds value.

05A layered reference architecture

A defensible OT-to-cloud design is layered, following the zone-and-conduit model in ISA/IEC 62443 and the Purdue-style segmentation in NIST SP 800-82. Data moves up through controlled boundaries, and each boundary narrows what can pass. No single device carries the whole burden.

Control zone

Controllers, PLCs and field devices publish process data to a local collector or historian. No device here talks to the cloud directly.

OT DMZ

A demilitarized zone holds the data broker, edge gateway or historian replica. It mediates between OT and the upper layers so OT never connects out directly.

Boundary control

A firewall, a data diode, or both enforce the conduit between the OT DMZ and the enterprise or cloud edge. This is where direction is enforced.

Cloud edge

An enterprise or cloud-side ingestion service receives the published data, applies schema validation, and forwards it to analytics, storage and dashboards.

The key discipline is that connections terminate at each layer. The control zone publishes to the DMZ; the DMZ publishes outward; the cloud edge ingests. No component in the cloud ever holds a session that reaches the control zone. The broker or replica in the DMZ acts as a break point so that even the outbound session does not run end to end into the plant.

06Where one-way transfer fits the cloud path

A data diode enforces direction in hardware. On the cloud-facing conduit, it lets the OT DMZ send data toward the cloud edge while making the reverse path physically absent. That is stronger than an outbound-only firewall rule because it cannot be reversed by a configuration change, a credential theft or a compromise of the cloud tenant.

Because cloud ingestion and many OT protocols expect acknowledgements, sessions or delivery confirmation, a diode is normally deployed as a unidirectional gateway: the diode enforces direction, and software on each side handles buffering, protocol adaptation, store-and-forward and monitoring. The sending side proxies the OT telemetry and forwards it across the one-way boundary; the receiving side reconstructs the stream and hands it to the cloud ingestion endpoint, often re-originating an outbound TLS session from a separate, lower-trust network.

For teams weighing how strict the cloud boundary should be, an AIRGAPNET controlled connectivity pattern can be compared against firewall-only outbound rules and diode-based transfer. The decision depends on consequence: a diode is most justified where a return path into the control zone would be unacceptable to safety, availability or recovery, and least necessary where the flow genuinely needs a two-way conversation.

07Protocols and data formats that suit one-way export

Not every protocol survives a one-way boundary cleanly. Protocols that depend on tight request-response handshakes, like raw OPC Classic DCOM or synchronous OPC UA client calls, are awkward across a diode because the acknowledgement cannot travel back. Publish-subscribe and streaming formats fit far better because the publisher does not require an answer to keep working.

• MQTT publish, often with Sparkplug B for structured industrial payloads, maps naturally to outbound telemetry.
• OPC UA PubSub, which decouples publishers from subscribers, suits one-way export better than the client-server profile.
• Syslog and structured event streams for logs and alarms forwarded to a SOC or cloud SIEM.
• File-based transfer of historian extracts, batch reports or backup snapshots, replicated outward on a schedule.
• Time-series exports such as compressed CSV or Parquet batches pushed to object storage.

The practical rule is to choose formats where delivery confirmation is handled on the sending side or by the gateway software, not by a round trip into the OT zone. Where a protocol insists on bidirectional state, terminate it in the DMZ and re-publish a one-way friendly representation across the boundary.

08Standards and compliance mapping

An outbound-only cloud design maps directly onto recognized OT security guidance. Using the standards language helps in audits and in risk-acceptance conversations, and it keeps the architecture honest about what each control actually does.

NIST SP 800-82 Rev. 3

Treats network segmentation, DMZs and minimizing OT reachability as core OT security practices; supports the layered collector-to-DMZ-to-edge pattern.

ISA/IEC 62443

Zones and conduits formalize the idea that a cloud-facing conduit can be defined, restricted and, where required, made unidirectional.

NIST SP 800-53

Controls such as boundary protection (SC-7) and information flow enforcement (AC-4) directly describe one-way and mediated data flows.

MITRE ATT&CK for ICS

Frames the threat: removing inbound paths reduces opportunities for Remote Services and external command-and-control techniques.

For regulated sectors, the same design supports NERC CIP electronic security perimeter requirements and similar obligations, because a publication-only conduit is far easier to document and defend than a bidirectional connection with a long firewall rule set.

09Common pitfalls that quietly reintroduce inbound exposure

Most failures are not in the headline data path. They are in the side channels, the convenience features and the management plane. A clean outbound design can be undone by a single overlooked return route.

• Cloud-to-edge command features enabled for convenience, such as remote configuration or device shadows that write back to the field.
• Management, update or VPN channels that open inbound paths the telemetry design was meant to avoid.
• Outbound rules written as broad any-to-cloud allowances that an attacker can ride in the return direction.
• Edge gateways that run a full OS, expose extra services, or hold credentials that reach into the control zone.
• A diode placed on the data path while a parallel firewall conduit carries the real return traffic.
• Trusting cloud-side input without validating that ingested data and any control intent are well formed and authorized.

The recurring lesson from CISA secure-by-design and bad-practices guidance applies here: a control is only as strong as its defaults, its management surface and the operating discipline around it. Audit the whole boundary, not just the diagram's main arrow.

10What if the cloud genuinely needs to send something back?

Sometimes a use case really does need downward flow: a setpoint change, a firmware update, a model deployed to the edge. The honest answer is that this is no longer pure one-way connectivity, and it should be treated as a separate, deliberately governed process rather than smuggled into the telemetry path.

Keep the high-volume telemetry path outbound-only and unidirectional. Handle the rare downward action through a distinct, heavily controlled channel: human-in-the-loop approval, a hardened jump path or vendor-access workflow, scheduled rather than always-on connectivity, and strong authentication and logging. Separating the two means a compromise of the analytics platform cannot trivially become control of the process.

Do not let one downward feature dictate the trust model for the whole connection. Isolate the exception so the common case stays one-way.

11OT cloud connectivity evaluation checklist

Before approving an OT-to-cloud design, reduce the review to concrete questions about direction, exposure and evidence.

• Is every cloud connection initiated outbound, with no inbound listening port on the OT side?
• Does any session, even an established one, run end to end into the control zone, or is it broken at a DMZ collector?
• What physically or cryptographically prevents the cloud from sending traffic back through the data path?
• Are downward actions, if any, handled by a separate, governed channel rather than the telemetry path?
• Can operators prove which data left, when, and whether transfers failed or buffered?
• Is the management, update and monitoring plane free of hidden inbound routes from the cloud or internet?
• How does the design map to NIST SP 800-82, ISA/IEC 62443 conduits, and any sector compliance obligations?

FAQFrequently asked questions

SRCSources of record