How to cross the IT OT barrier with NIS2?

introduction 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 nis2 eu directive in short 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 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 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 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 nis2 explicitly brings ot and ics environments into scope securing the factory floor is now a legal obligation, not an optional best practice nis2 compliant architecture the core principle 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 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 — 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 the most practical and nis2 aligned pattern for this boundary uses two components working in tandem 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 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 ot network (zone 1–2) dmz (zone 3 5) it network (zone 3–4)───────────────────── ────────────── ───────────────────── plc / historian mes / erp / data lake │ │ edge node ──── publish (outbound only) ──▶ mqtt broker ◀── subscribe │ tls 1 3 + mtls │ └──────────────────────────────────────────┘ no inbound connections accepted by ot side nis2 / cyfun controls this architecture satisfies 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 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 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 — a compromised it subscriber cannot impersonate the edge node 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 — directly supporting nis2's incident detection and reporting obligations 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 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 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 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 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