Modern industrial enterprises require data to optimize costs and implement predictive maintenance. This necessitates transmitting telemetry from the operational technology (OT) environment to cloud analytics services. However, connecting industrial equipment directly to external networks creates critical risks for physical process continuity.
According to the ENISA Threat Landscape 2025 report, 4,875 incidents were analyzed during the reporting period (July 1, 2024, to June 30, 2025). Statistics show that 53.7% of affected organizations were classified as 'essential entities' under the NIS2 directive. This highlights that attackers are focusing on infrastructure where a cyberattack can lead to production shutdowns. Technical directors and CISOs face the challenge of integrating cloud analytics without exposing programmable logic controllers (PLCs) to the external environment.
The trap of direct integration: why the cloud should not see PLCs
A fundamental architectural error is creating a direct network route from a PLC to cloud storage. Industrial protocols (such as Modbus TCP or basic versions of OPC UA) were designed for isolated environments and often lack robust authentication and encryption mechanisms.
Connecting a controller to the cloud, even using a VPN, creates a threat. If the cloud environment or IT staff accounts are compromised, an attacker can send control commands directly to the PLC. Since cloud analytics only requires historical telemetry, a direct connection is an unjustified compromise of the physical security perimeter.
Architectural isolation instead of classic firewalls
The extensive Cisco Cybersecurity Readiness Index 2025 study, covering 8,000 business leaders across 30 countries, demonstrates the need to rethink protection approaches. Installing a classic firewall between the corporate network and production no longer provides sufficient segmentation.
In accordance with modern guidelines for protecting critical infrastructure (specifically architectural isolation principles aligned with CISA CPG), it is necessary to implement session termination at segment boundaries:
- Full prohibition of direct IP routing between the OT segment and any external network.
- Mandatory protocol translation: data is transmitted via intermediate nodes (gateways).
- No technical capability to initiate connections from the outside into the industrial network.
Unidirectional gateways (data diodes) and protocol isolation in practice
The most reliable pattern for exporting industrial data is the use of unidirectional gateways (data diodes). This allows for physical or software-based prevention of packet flow in the reverse direction—back to the controllers.
A typical secure transmission process looks like this:
- A local industrial gateway in the OT network collects telemetry from the PLC using internal protocols. The gateway has no external IP address.
- Protocol conversion: data is converted into a secure, structured format (e.g., JSON). The industrial protocol does not leave the production floor.
- The generated packet is transmitted via a unidirectional interface (hardware or strict software data diode), which blocks any incoming traffic.
- An external broker in the IT segment receives the data and sends it to the cloud via MQTT or HTTPS.
The role of an intermediate platform: filtering, auditing, and access control
Managing such infrastructure requires a robust software layer at the network edge. Collecting, normalizing, and performing initial processing of industrial data from within the OT environment is typically achieved through cyber-physical systems, such as the AZIOT Platform.
For creating secure audit gateways and access control at the IT/OT junction, it is advisable to use the UnityBase platform. UnityBase is a full-stack JavaScript low-code platform, which is a joint development by companies within the Intecracy Group (where InBase is a key developer). Thanks to its Domain metadata mechanisms, the platform allows for the configuration of an isolated transaction management layer.
Utilizing UnityBase platform mechanisms ensures:
- Implementation of a role-based access control (RBAC) model for strict separation of access rights to integration gateway settings.
- Maintenance of an immutable audit trail, which is critical for NIS2 compliance and conducting cyber incident investigations.
- The ability to deploy on-premises to maintain full control over the perimeter.
For critical infrastructure projects with heightened security requirements, the platform's official documentation recommends using commercial Enterprise (EE) or Defence (DE) editions, which provide advanced authentication and integrity control capabilities.
How to build a secure bridge between OT and the cloud
When planning architecture, cost optimization principles should be considered. As noted in the Microsoft Azure Well-Architected recommendations (Cost Optimization section), modeling costs and security at the design stage is significantly more effective than attempting to optimize a system post-factum. Adding security layers to an already operational, insecure architecture leads to excessive capital expenditures.
It is also worth integrating the FinOps Framework, which makes cloud infrastructure management a shared responsibility among engineering, security, and finance teams. This ensures that the costs of transporting telemetry through secure gateways remain economically justified.
IT/OT architectural protection matrix for cloud integration
| Architecture Level | Primary Security Requirement | Technical Implementation |
|---|---|---|
| OT Level (PLC/SCADA) | Direct connection prohibited | Data collection via local gateway without an external IP address. |
| Gateway Level | Protocol isolation | Conversion of Modbus/OPC UA to JSON with field filtering. |
| Transport Level | Unidirectional transmission | Blocking reverse traffic to OT (Data Diode). |
| Audit Level (UnityBase) | Access control and logging | Application of RBAC and an immutable audit trail for configurations. |
| Cloud Level | Privilege limitation | Receipt of depersonalized telemetry only, without control rights. |
Architectural isolation allows industrial companies to leverage all the benefits of cloud technologies while maintaining confidence that physical assets are fully isolated from external cyber threats.
FAQ
How can data transmission to the cloud be ensured if industrial protocols (OPC UA, Modbus) lack built-in security?
A protocol isolation method is used for this. A local gateway within the OT network reads data from the PLC and converts it into a secure format (e.g., JSON). The industrial protocol is not routed to the external network, which eliminates the possibility of direct exploitation by the cloud.
Can a standard firewall be used instead of a hardware data diode for IT/OT segmentation?
A classic firewall creates a logical barrier that can be bypassed in the event of a configuration error or the discovery of a vulnerability in the firewall software itself. Using a hardware or strict software data diode physically or at the driver level makes it impossible to transmit traffic in the reverse direction, drastically reducing risks.
How can feedback (e.g., setting updates) be organized from the cloud to the OT without creating security holes?
Feedback is never implemented as a direct connection. Updates are uploaded to an intermediate server in a demilitarized zone (DMZ). The local gateway from within the OT periodically initiates a request for signed updates, verifies their digital signature, and only then applies the changes within the industrial network.