Securely Feed Your OT Data to AI

In an era where industrial AI is reshaping competitive landscapes, the ability to securely harness real-time data from Operational Technology (OT) to AI is not just an advantage — it's a necessity for sustainable growth. A clear need exists for unified data foundations to power AI models without exposing the production infrastructure to vulnerabilities.

Maintaining this kind of zero-attack-surface environment is difficult to achieve, but it is possible, through the strategic use of outbound connections and robust network segmentation.

Inbound connections = Open doors in a high-stakes environment

In industrial OT networks, every inbound connection is like an unlocked door in a critical facility: it creates a direct, attacker-initiated path into your most sensitive control systems. Attackers actively scan for these open ports (using tools like Shodan or masscan), exploit known vulnerabilities in the listening services and gain unauthorized access — often leading to lateral movement, command injection, ransomware or physical disruption of operations. 

While many users believe that a VPN provides a secure solution, VPNS often unfortunately offer only a false sense of security by merely extending the IT security perimeter into the plant network. If the IT network is compromised, an attacker can reach every connected node on the linked OT network because a VPN does not protect against inbound connections. Instead of relying on a VPN, a more effective security practice is to close all incoming firewall ports on the production system.

DMZ and standard protocols

For even more comprehensive protection, the NIS2 Directive and NIST CSF 2.0 require complete network segmentation, typically by using a DMZ (demilitarized zone). But this can be a challenge to implement. While a DMZ is the most secure way to connect OT and IT networks, making reliable connections through a DMZ is not realistic for popular industrial protocols like OPC UA and MQTT. These were conceived long before the industry prioritized secure remote access from outside the plant. 

OPC UA implementations are typically too complex to support multiple hops through a DMZ without introducing high latency or data loss. Furthermore, an OPC UA client on a DMZ typically requires an open firewall port to connect to the plant server, which is a risk most security administrators will not allow.

MQTT also faces challenges within a DMZ-protected architecture. While it seems that MQTT could be daisy-chained by making multiple client and broker connections, such an approach would require individual configuration for every node in the chain. More importantly, the MQTT Quality of Service (QoS) guarantees would not propagate through these chains, which can leave users unaware of stale or unreliable data at the end of the path. 

Because of these limitations, MQTT is best reserved for the edge. It is useful for gathering data from remote devices, or for the final step of moving data from a DMZ to the cloud. But it cannot serve well as an Industrial IoT backbone protocol.

The tunnel/mirroring solution

Bridging the gap between the plant and the AI system securely requires a different approach that is DMZ-compatible, integrates with existing protocols and can maintain a closed-firewall posture. 

Secure tunnel/mirroring software provides a solution by making outbound-only TCP connections from the OT side to a DMZ. This eliminates the attack surface by moving the potential risk to the DMZ, which can then be hardened independently. By mirroring complete data sets at each node, this technology ensures data consistency and reliability across the entire path from the production facility to the AI service.

This system works by connecting to the data source using standard protocols like OPC UA and mirroring that information into a unified namespace on the DMZ. From there, the data can be safely converted to MQTT for delivery to the AI system. 

Flexibility

With its robust support for multiple-hop connections, another tunnel/mirror option is to put an additional node on the AI system itself. This is especially useful for in-house AI systems that may not have or need an MQTT broker. Tunnel/mirror software that supports a universal namespace and offers several protocol options can pass the data directly to historians, event streams or custom AI tools.

With the right software, a tunnel/mirror approach can even be implemented on data diode-enabled systems to ensure no data packets return to the industrial network. This is especially valuable for high-security environments or critical infrastructure.

Emerging threats

The best security algorithms in use today may be vulnerable to quantum computing attacks in the future. Hackers using "harvest now, decrypt later" strategies may be able to leverage the anticipated power of quantum computing to crack passwords, certificates and other encryption devices. Tunnel/mirror and any other software for industrial data communication should support post-quantum cryptography (PQC), such as offered by the most recent OpenSSL tools, to enable quantum-resistant encryption for secure, real-time OT-IT data flows.

Indeed, creating a secure, reliable data from the shop floor to AI is one of the most challenging issues for control engineers today. The playing field is constantly shifting. Yet there are steps you can take to protect your OT and IT systems and still maintain a robust data connection between them.

The first step is to isolate your networks using a DMZ and tunnel/mirroring your data through it to connect to in-house or cloud-based AI systems. Companies using this approach can optimize their processes while keeping production data and networks isolated and secure.