How to cross the IT OT barrier with NIS2?

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 isa 95 levels showing the it domain on levels 3 and 4 and the ot domain 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 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 what does a nis2 compliant architecture look like? 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 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 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 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 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, so 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 this directly supports 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) 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