Making Outbound Connections for OT Data Security

Summary

Secure access to data from a production system means making outbound connections. In the current climate of cybercrime, any inbound connection constitutes a real vulnerability. Attackers conduct regular and frequent port scans on target systems to discover vulnerable points in a network. They send packets to specific ports to determine which of them are open, closed or filtered, identifying every possible point of entry into supposedly isolated systems. 


Therefore, any open incoming firewall port constitutes an attack surface. Unfortunately, most industrial protocols, like OPC, require inbound connections. They are based on the traditional server-client model, where the client initiates the connection to request data from a server.
 

Attacks are directed at applications

The problem is deeper than just the port or protocol. OPC UA or any other protocol may be secure in itself, but attacks are most often directed at applications that use it. The risk is that the listening application has an exploitable flaw that may or may not be due to the protocol implementation.

For example, an application may perfectly implement OPC UA, yet be vulnerable to flaws in OpenSSL. The application may have no exploitable flaws in OPC UA or SSL, but still have a buffer overrun in a string processing function executed on incoming data. No application is free of bugs. Every open incoming port is an opportunity for an attacker to probe an application for exploitable flaws, and can give instant access to a network if an exploit is discovered.
 

VPN: A false friend

Some users familiar with the IT world may think that employing a VPN can provide secure access to OT data. Not so. A VPN merely extends the IT security perimeter into the plant network, effectively connecting the two networks. Any successful hack of the IT network that breaks into the VPN can reach every other connected node, including those on a linked OT network. A VPN does not eliminate inbound connections.
 

Best practice – close all inbound firewall ports

The best security practice is to not open any incoming ports at all in any OT network firewall. There are two options for doing this: a broker or secure tunnel/mirroring.

Broker

One approach to closing all inbound firewall ports is to use a broker-based protocol like MQTT. Each MQTT data source or data receiver makes an outbound client connection to the MQTT broker. OPC UA PubSub also uses a broker to support outbound connections for OPC UA, MQTT or others. For both OPC UA PubSub and MQTT, large-scale, complex IoT or OT-to-IT systems may require more flexible and robust solutions. For example, the MQTT protocol can be enhanced by using Sparkplug and/or a smart MQTT broker.
 

Secure tunnel/mirroring

A second approach for keeping all inbound firewall ports closed is secure tunnel/mirroring. This approach makes an outbound TCP connection from the server side to the client side, eliminating the need to open any inbound firewall ports. The result: zero attack surface. It can also be used for segmenting networks with a DMZ. Outbound-only connections are configured from the OT side to the DMZ, as well as from the IT side to the DMZ. The potential attack surface moves to the DMZ, which can then be hardened to manage the security risk.

DMZ

A DMZ (demilitarized zone) is the most secure way to connect OT and IT networks, using outbound-only connections to separate them and ensure authenticated, restricted data flow. However, implementing reliable connections through a DMZ is difficult for both OPC UA and MQTT protocols. The literature on these protocols mentions DMZ support, but our testing and experience in the field show this is more difficult to implement than it sounds. OPC UA is too complex to make multiple hops through a DMZ architecture without introducing high latency or risk of data loss. Simple, one-hop MQTT connections can be made through a DMZ, as long as the broker runs in the DMZ itself. But any connections requiring multiple broker/client connections lack data consistency and reliable quality-of-service indicators across nodes, leaving users unaware of stale data.
 
In contrast, there are tunnel/mirroring systems that support DMZ use by mirroring complete data sets at each node. This ensures consistent, accessible data at all points in the chain. Such a system may be enabled to identify network problems or outages, and mark data as disconnected until the connection resumes, ensuring data reliability for the full data path.
 

Data diodes

Some high-security, critical infrastructure applications require a hardware data diode to ensure that not a single data packet gets back to the industrial network. Neither OPC UA or MQTT can support this kind of connection natively, and rely on UDP for data diode support. UDP was not designed for industrial data communications, though, as it may deliver inaccurate, out-of-sequence, or incomplete messages. On the other hand, there are tunnel/mirror options that use TCP to provide data diode support for systems requiring that level of secure architecture.
 
Whichever option best suits your particular architecture, the first step in securing remote access to plant or process data is to keep all firewall ports closed. Data diode, DMZ, broker, tunnel/mirroring or some combination of these offer solutions you should not overlook.

_{This feature also appears in Automation.com Monthly's 2nd Annual Cybersecurity Trends report (October 2025).}