The convergence of information technology (IT) and operational technology (OT) is a prerequisite for implementing real-time analytics and predictive equipment maintenance. However, the downside of this integration has been an expanded attack vector on critical infrastructure. Against the backdrop of strict NIS2 directive requirements, direct integration of corporate and industrial systems has become a critical vulnerability that demands immediate architectural restructuring.
According to the ENISA Threat Landscape 2025 report, organizations classified as essential entities under NIS2 accounted for 53.7% of all affected organizations analyzed during the reporting period. Secure integration requires the complete abandonment of direct connections between ERP systems and SCADA in favor of strict segmentation according to the ISA/IEC 62443 standard, utilizing an industrial demilitarized zone (IDMZ) with API gateways and asynchronous message brokers.
Why direct ERP and SCADA integration is an architectural error
The desire to obtain production output data directly from the production line often pushes developers toward the simplest path: configuring a direct point-to-point connection between a corporate database (ERP or BI) and a SCADA or MES database. While described in legacy system integration patterns, this approach creates two fundamental threats today:
- Breach of the security perimeter. A direct connection violates the isolation of the industrial network. If the corporate IT segment is compromised (via phishing or office service vulnerabilities), attackers gain a direct network path to physical controllers, allowing them to manipulate processes.
- Risk of real-time system failure. Industrial control systems are designed for continuous, real-time operation. Massive analytical queries from the IT department can overload SCADA servers or lock database tables, leading to delays in transmitting critical control commands.
The zones and conduits concept in ISA/IEC 62443: designing security boundaries
The ISA/IEC 62443 standard defines a security framework for industrial automation systems through the concept of "Zones and Conduits." The architecture is broken down into logical zones (levels according to the Purdue model) with identical security requirements.
Industrial networks (levels 0-3) are isolated from corporate systems (levels 4-5). For legitimate data exchange, a level 3.5 is designed—the industrial demilitarized zone (IDMZ). Communication between zones is conducted exclusively through secure channels (Conduits). No data packet can transit through the IDMZ without termination and inspection at an intermediate gateway.
Anatomy of an integration gateway in the IDMZ: API gateways and brokers
The implementation of communication channels is based on enterprise integration patterns. Instead of fragile direct connections, managed gateways are used.
Deployment of an API gateway as a proxy server
To control synchronous requests in the DMZ, an API Gateway (such as Kong or similar solutions) is deployed. The ERP system does not communicate directly with the MES; it sends a request to the API Gateway. The gateway centralizes authentication, provides TLS termination, and applies rate limiting. This ensures that excessive traffic is rejected before it reaches vulnerable OT systems.
Ensuring integrity: Schema Registry and asynchronous decoupling
For transmitting telemetry arrays, it is recommended to use asynchronous message brokers (such as Apache Kafka). This creates complete isolation in terms of time and protocol. Implementing Change Data Capture (CDC) technology allows for tracking changes in industrial databases and transmitting them as events without executing direct SQL queries against SCADA.
To ensure data reliability, a Schema Registry is used—a tool for controlling data contracts. It guarantees that only validated telemetry with the correct structure reaches IT analytics from the OT segment, preventing failures at the corporate level.
Platform approach of the Intecracy Group alliance
Creating a reliable architecture requires secure tools on both the OT and IT sides. The Intecracy Group alliance offers a platform approach for designing such infrastructure. For industrial IoT/SCADA solutions, the AZIOT platform is used, while corporate data-consuming applications are built on the UnityBase platform (a joint development of the alliance companies, where InBase is the key developer).
UnityBase is a low-code platform that allows for the creation of high-load enterprise systems with built-in mechanisms for integration with gateways in the IDMZ (via automatically generated REST API). For projects subject to strict regulatory requirements (such as NIS2) or requiring on-premises deployment, the platform's official documentation recommends using the Enterprise or Defence commercial editions. These provide row-level security (RLS), Active Directory integration, and immutable audit trails, which are critical for the secure processing of technological information.
NIS2 compliance: a checklist for system integration architects
To design a secure integration infrastructure, it is important to understand the difference in threat levels across various architectural patterns.
| Integration pattern | Threat level | Impact on OT segment | ISA/IEC 62443 compliance |
|---|---|---|---|
| Direct connection (Direct DB/API) | Critical | High risk of real-time system failure | Non-compliant |
| API Gateway in DMZ (Proxy) | Low | Controlled (authenticated synchronous requests) | Partial (for controlled APIs) |
| Asynchronous broker + CDC | Minimal | Zero (complete isolation by time and protocol) | Full (recommended pattern) |
Architect's checklist for cybersecurity compliance:
- Traffic isolation: Abandon direct point-to-point connections; terminate all connections in the industrial demilitarized zone (IDMZ).
- Data contract control: Use a Schema Registry to validate messages arriving from OT to IT.
- Overload protection: Implement rate limiting at the API gateway level to protect controllers.
- Authentication: Centralized access verification and encryption at segment boundaries.
Building integration gateways requires a fundamental change in architecture, but it is the only reliable path to secure IT and OT convergence in the modern threat landscape.
FAQ
How can a secure gateway between IT and OT be built according to ISA/IEC 62443 requirements?
A secure gateway is built based on the Zones and Conduits concept. Direct connections between the corporate network (IT) and the technological network (OT) are prohibited. An industrial demilitarized zone (IDMZ, level 3.5 according to the Purdue model) is created, where all communications are terminated using proxy servers, API gateways, and asynchronous message brokers.
Which protocols (OPC UA, MQTT, HTTPS) should be used to transmit data to the industrial DMZ?
Protocols like OPC UA function within the industrial segment, but their direct transmission to IT is not recommended. In the DMZ, the integration gateway must perform protocol translation, converting data into secure web standards (HTTPS, JSON) or publishing events via brokers (e.g., MQTT combined with Kafka) with authentication control.
How can NIS2 compliance be ensured when integrating SCADA with corporate systems?
To ensure NIS2 compliance, all direct connections (Direct DB/API) to SCADA must be eliminated, isolating processes via an IDMZ. Use API Gateways to control synchronous requests with mandatory rate limiting, and use asynchronous brokers with Change Data Capture (CDC) and a Schema Registry for secure telemetry transmission without impacting controller performance.