---
title: How to cross the IT OT barrier with NIS2?
slug: how-to-cross-the-it-ot-barrier-with-nis2
createdAt: 2026-05-28T11:10:51.195Z
---
# How do you cross the IT OT barrier with NIS2?
**Audience**: *This page is written primarily for IT architects and security teams who must implement a NIS2 compliant IT OT boundary. Non-technical readers, such as plant managers and compliance officers, can read it to understand how Mantsu crosses that boundary safely.*
***
# What are IT and OT in manufacturing?
Let us first start with a clear definition of IT & OT in the context of Manufacturing Systems:
- **IT (Information Technology):** The traditional office networks, databases, email servers, business applications. The focus lies on confidentiality and integrity of the data. A breach can lead to serious legal repercussions.
- **OT (Operational Technology): **The hardware & software that control and measure the physical processes on the shopfloor (DCS, SCADA, PLC, IIoT). The focus lies on availability and security. An interruption or breach of the network can lead to a standstill and also to physical dangerous situations.
If we consider the classic ISA-95 domains: the IT domain is situated on level 4 & level 3, while the OT domain will be situated on the lower levels.
# What is the NIS2 EU directive?
NIS2 (Network and Information Security Directive 2) is an EU cybersecurity directive that entered into force in January 2023. It replaces the original NIS directive from 2016 and had to be transposed into national law by October 2024. Belgium implements it through CyFun, governed by the Centre for Cybersecurity Belgium.
**Context**
:::Paragraph{indent="1"}
Cyber threats against European infrastructure grew significantly through the late 2010s and early 2020s. The original NIS directive proved too narrow in scope and was applied inconsistently across member states. A stronger, broader framework became necessary.
:::
**What changed**
:::Paragraph{indent="1"}
NIS2 expands the list of sectors in scope to include manufacturing, food production, waste management, and postal services. Security requirements are more concrete and enforceable. Penalties are substantial, reaching up to €10 million or 2% of global annual turnover for essential entities.
:::
**Core obligations**
:::Paragraph{indent="1"}
Organisations must apply risk-based measures across six areas: network segmentation, access control, encryption, vulnerability management, supply chain security, and business continuity. Incidents must be reported to the national authority within 24 hours of detection, with a full report within 72 hours.
:::
**Relevance for industrial environments**
:::Paragraph{indent="1"}
NIS2 explicitly brings OT and ICS environments into scope. Securing the factory floor is now a legal obligation, not an optional best practice.
:::
# What does a NIS2 compliant architecture look like?
**The core principle**
:::Paragraph{indent="1"}
NIS2 (and its Belgian implementation via CyFun) requires that the DMZ between IT and OT is not merely a firewall rule, but an **enforced architectural boundary**, meaning no direct routable path should exist between the OT network and the corporate IT network. All data exchange must pass through controlled intermediaries in the DMZ itself.
:::
**Why the DMZ exists at this boundary**
:::Paragraph{indent="1"}
The ISA-95 Level 3 ↔ Level 2 interface is where business-driven data requests meet operational control systems. An uncontrolled connection here means a compromised ERP or MES can reach PLCs and SCADA systems directly. This is the exact attack vector seen in incidents like Industroyer and the Oldsmar water plant breach. NIS2 Article 21 mandates risk-based technical measures precisely to prevent this lateral movement.
:::
**The MQTT + Edge Node architecture**
:::Paragraph{indent="1"}
The most practical and NIS2-aligned pattern for this boundary uses two components working in tandem:
:::
:::Paragraph{indent="1"}
**1. Edge Node (OT side, Zone 1–2)** The edge node sits in the OT network, close to the control layer. It initiates all connections: it *pulls* data from PLCs or historians and *pushes* it outward toward the DMZ. Crucially, it never accepts inbound connections from the IT side. This **unidirectional initiation** is the key security property: the OT network is never listening for external requests.
:::
:::Paragraph{indent="1"}
**2. MQTT Broker (in the DMZ, Zone 3.5)** The broker acts as the controlled rendezvous point. It receives published messages from the edge node and makes them available for subscription by IT-side consumers (MES, data lake, ERP integrations). The broker holds the data temporarily and enforces access control: IT systems subscribe to specific topics; they cannot query the OT layer directly. The broker is the only system that has network adjacency to both sides, and it communicates with each side on separate network interfaces.
:::
```mermaid
graph LR
subgraph OT["🔒 OT Network — Zone 1–2"]
PLC[PLC / Historian]
EN[Edge Node]
PLC -->|data| EN
end
subgraph DMZ["🛡️ DMZ — Zone 3.5"]
BR[MQTT Broker]
end
subgraph IT["🏢 IT Network — Zone 3–4"]
APP[MES / ERP / Data Lake]
end
EN -->|"PUBLISH — outbound only\nTLS 1.3 + mTLS"| BR
BR -->|SUBSCRIBE| APP
APP -. "blocked: no inbound\nconnection into OT" .-> EN
style EN fill:#e8f4f8
style BR fill:#fff3cd
```
***
NIS2 / CyFun controls this architecture satisfies:
:::Paragraph{indent="1"}
**Network segmentation (CyFun PR.AC / IEC 62443 SR 5.1)** The MQTT broker enforces a hard zone boundary. No IP route exists between OT and IT; traffic is mediated at the application layer only, per topic and per authenticated client.
:::
:::Paragraph{indent="1"}
**Principle of least privilege (CyFun PR.AC-3)** Topic-level ACLs on the broker ensure an MES subscription can only read plant/line1/+/status. It cannot write to OT topics or query historian data beyond what is explicitly published. Write paths back into OT (e.g. setpoint commands) require a separate, hardened channel with additional authentication, or are disallowed entirely.
:::
:::Paragraph{indent="1"}
**Encrypted transport (CyFun PR.DS-2 / NIS2 Art. 21.2)** All MQTT connections use TLS 1.3 with mutual TLS (mTLS) certificate authentication. The edge node and all IT subscribers hold individual certificates, so a compromised IT subscriber cannot impersonate the edge node.
:::
:::Paragraph{indent="1"}
**Audit logging and monitoring (CyFun DE.CM / NIS2 Art. 21.2e)** The MQTT broker logs all connect, publish, and subscribe events. This provides a full audit trail of what data crossed the DMZ, when, and by which authenticated client. This directly supports NIS2's incident detection and reporting obligations.
:::
:::Paragraph{indent="1"}
**Resilience and availability (NIS2 Art. 21.2c)** The edge node buffers messages locally when the broker is unreachable (e.g. during a broker update or network interruption). This decoupling means OT operations are never dependent on IT-side availability, which is a core OT resilience requirement.
:::
***
Additional hardening considerations:
:::Paragraph{indent="1"}
**Firewall rules**: only the edge node's IP is permitted to reach the broker's MQTT port (8883) from the OT side. The broker's IT-facing port is similarly restricted to known subscriber IPs.
:::
:::Paragraph{indent="1"}
**Data diode option**: for the most sensitive OT environments (e.g. safety-instrumented systems), a hardware data diode can replace or supplement the broker on the OT→DMZ leg, making the unidirectional property physically enforced rather than just logical.
:::
:::Paragraph{indent="1"}
**No historian in the DMZ**: a common mistake is placing the process historian in the DMZ for "easy access." Under NIS2/CyFun, the historian stays in the OT zone; only contextualized, aggregated MQTT payloads cross the boundary.
:::
:::Paragraph{indent="1"}
**Patch and vulnerability management**: the MQTT broker is an IT/OT-facing component and falls under NIS2's requirement for timely vulnerability remediation. It should be treated as critical infrastructure, not a set-and-forget middleware.
:::
Summary mapping
| **Architectural element** | **Purdue zone** | **NIS2 / CyFun control** |
| -------------------------------- | ---------------------- | -------------------------------------------------------- |
| Edge node | Zone 1–2 (OT) | Initiates only, no inbound (segmentation) |
| MQTT Broker | Zone 3.5 (DMZ) | mTLS, ACLs, audit log (access control + monitoring) |
| MES / ERP subscriber | Zone 3–4 (IT) | Subscribe-only to permitted topics (least privilege) |
| Firewall rules | Zone boundaries | Restrict by IP + port + direction (network segmentation) |
| TLS 1.3 + mTLS | All links | Encrypted transport (data integrity) |
***
# Frequently asked questions
**How does Mantsu cross the IT/OT barrier under NIS2?**
With an edge node that only initiates outbound connections and an MQTT broker in the DMZ, so no routable path exists between the OT network and corporate IT.
**Does NIS2 forbid direct IT to OT connections in a Mantsu architecture?**
It requires an enforced architectural boundary; Mantsu's design ensures no direct routable path between the OT network and corporate IT.
**What role does Mantsu's MQTT broker play at the boundary?**
It is the controlled rendezvous point in the DMZ: the only system with network adjacency to both sides, enforcing topic-level access control.
**How does Mantsu secure the data crossing the boundary?**
All MQTT connections use TLS 1.3 with mutual TLS certificates, and the broker logs every connect, publish, and subscribe event for the audit trail NIS2 requires.
***
**Summary**: *Mantsu crosses the IT OT boundary with an edge node that only initiates outbound connections and an MQTT broker in the DMZ. No routable path exists between IT and OT, which satisfies the NIS2 requirement for an enforced architectural boundary.*