OT/IT Segmentation, DMZ and the Purdue Model for Remote Maintenance

OT/IT segmentation for remote maintenance means the control network (Operational Technology) is consistently separated from the office IT network and the internet, and remote access runs only through a dedicated handover space - a remote-access DMZ. That DMZ hosts the WireGuard endpoint, a browser gateway and a jump host. They receive the connection from outside, check identity and role, and open only one clearly defined path into the plant. There is no continuous wire from the internet down to the PLC. Two established concepts give this structure: the Purdue model as a level map and the zones and conduits of the IEC 62443 standard.

The Purdue Model: Thinking in OT Levels

The Purdue Enterprise Reference Architecture (PERA), known as the Purdue model, was developed at Purdue University in the 1990s and is still the reference for segmenting industrial networks. It places every system into a level, from the physical process up to the enterprise network. Levels 0 to 3 are the OT side (the physical plant and its control systems), Levels 4 and 5 are the IT side (business systems and the internet). Between them sits the decisive buffer: Level 3.5, the industrial DMZ.

Remote access does not naturally fit this rigid hierarchy: an external technician who needs a PLC on Level 1 comes from the far outside. That is precisely why remote access is the most common reason conduits become too permissive. The clean answer is not to tunnel the access straight through, but to terminate it in Level 3.5.

Why OT Must Be Separated from IT and the Internet

OT systems play by different rules than office IT. PLCs often run for years without patching, speak unauthenticated fieldbus protocols and are optimised for availability and real time, not for hardening. An attacker who reaches Level 1 directly from the office network or through a hijacked remote-access connection can disrupt processes, defeat safety functions or damage equipment. Segmentation limits the blast radius: if one zone falls, the attacker does not automatically pivot into the next. How this comes together in practice for machines and plants is covered in our overview of secure remote maintenance of machines and plants.

The Remote-Access DMZ: One Path, No Passthrough

The remote-access DMZ (Level 3.5) is the only place where external access terminates. It hosts three components: the WireGuard endpoint as the encrypted entry, the browser gateway (Apache Guacamole) for RDP, VNC and SSH without a client, and an SSH jump host (bastion) for administrative access to servers and engineering systems. Identity (SSO/MFA), the role model (RBAC) and the complete audit trail live here too.

Internet / Technician
        |
        |  (1) WireGuard conduit - initiated outbound from the site
        v
+--------------------------------------+
|  Level 3.5  -  Remote-Access DMZ     |
|  - WireGuard endpoint (conduit)      |
|  - Guacamole browser gateway         |
|  - SSH bastion / jump host           |
|  - SSO/MFA  +  RBAC  +  audit        |
+--------------------------------------+
        |  (2) exactly one conduit - deny-by-default, filtered
        v
+--------------------------------------+
|  Level 3   Site operations (MES, EWS)|
+--------------------------------------+
        |  (3) filtered conduit
        v
+--------------------------------------+
|  Level 2   SCADA / HMI               |
|  Level 1   PLC / RTU / IED           |
|  Level 0   Sensors / actuators       |
+--------------------------------------+

Germany's BSI explicitly recommends this build. The IT-Grundschutz module IND.3.2 "Remote maintenance in the industrial environment" (and OPS.1.2.5) states that the remote-maintenance system should run as a jump server or application layer gateway in its own security segment - a DMZ - separated from all other networks by firewalls, with each session approved in advance by a responsible person and limited in time. That is exactly what the jump host is for; its build and hardening are covered in our article on the SSH bastion and jump host.

Zones and Conduits under IEC 62443

While the Purdue model provides the map, the international IEC 62443 standard formalises the implementation. It groups assets with common security requirements into zones; any permitted communication between two zones runs through a conduit - a defined, controlled channel with its own requirements. IEC 62443-3-2 covers the risk assessment and the partitioning into zones and conduits and assigns each zone a target security level (SL-T from 0 to 4). IEC 62443-3-3 provides the technical system requirements, organised under seven foundational requirements - among them identification and authentication control (FR 1), use control (FR 2) and restricted data flow (FR 5), which carries the zone-and-conduit logic.

Applied to remote maintenance: the OT plant is a zone with a high target level. The path to it is exactly one conduit that terminates, authenticates, filters and logs in the DMZ. The WireGuard tunnel is itself a conduit from outside into the DMZ - not into the OT zone. A standard-aligned deep dive with a mapping to concrete measures is in our article on IEC 62443 for OT remote access.

Where WireGuard and the Gateway Sit Exactly

The WireGuard tunnel is established outbound from the site to the DMZ. That is the key point: no inbound ports need to be opened at the plant and no device is exposed to the internet. WireGuard uses modern cryptography (Curve25519, ChaCha20-Poly1305) and has been in the mainline Linux kernel since 5.6. Its setup and topology are covered in WireGuard site connectivity; background and operations on our WireGuard expertise page.

Behind the tunnel, also in the DMZ, sits the browser gateway. It accepts the authenticated request and only then - constrained by RBAC - opens the specific RDP, VNC or SSH session to the approved device. The technician works in the browser, with no VPN client on the laptop. The single path into the OT zone stays under full control and logging.

No Passthrough: Deny-by-Default

The load-bearing principle is deny-by-default: no connection is allowed unless a role needs it for a task - time-limited, per site, per device, per protocol. A direct path from the internet or the office network to the PLC does not exist because the architecture does not provide for it. Known vulnerabilities in the components in use should be monitored (our CVE monitoring), and a security audit checks the segmentation before go-live.

Standards, Law and Practice

IEC 62443 and the BSI module IND.3.2 are the technical guardrails; legally, many operators also fall under NIS2, transposed in Germany by the NIS2 implementation act in force since 6 December 2025. It requires risk management, access control, MFA and logging, among other things - a segmented remote-access DMZ feeds directly into that. Setting up remote access in a NIS2-compliant way is covered in NIS2-compliant remote access. This article is general information and not legal advice. We are engineers, not lawyers.

How WZ-IT Builds This

We build sovereign remote-maintenance platforms exactly to this pattern: segmentation per Purdue, zones and conduits per IEC 62443, a remote-access DMZ with a WireGuard conduit, a Guacamole gateway and a jump host, plus SSO/MFA, RBAC and a complete audit trail - run on our own EU infrastructure. For ABCO Water Systems in Australia we run remote access to distributed water-treatment plants this way (ABCO Water case study).

If you want to cleanly separate OT and IT for remote maintenance or replace an existing solution, our remote management platform is the direct entry point. We are happy to discuss your case in a free initial consultation.

Related Articles in This Cluster

• WireGuard site connectivity
• Secure remote maintenance of machines and plants
• SSH bastion and jump host
• IEC 62443 for OT remote access
• NIS2-compliant remote access