IEC 62443 is the international series of standards for the cybersecurity of industrial automation and control systems (IACS). For OT remote access it does not prescribe a single clause but an architectural principle: plants are segmented into zones and conduits, every access via an untrusted network enforces strong authentication including MFA, least privilege, encryption, a session time limit, and complete logging - scaled by a security level (SL 1 to SL 4). This article explains the relevant parts of the series (status 2026), what the standard concretely requires for secure remote access, how a sovereign platform implements it, and how the standard differs from NIS2.
What IEC 62443 is - and what it is not
IEC 62443 is a voluntary technical standard, developed by IEC committee TC65 together with the ISA99 group. It is not a law or a regulatory order, but it is widely recognised across industries as the state of the art for OT security. That is exactly what makes it valuable for regulated operators: building to IEC 62443 lets you demonstrate to auditors and authorities, in a traceable way, that your safeguards match the current state of the art.
The series is organised into four groups:
| Part | Coverage | Status |
|---|---|---|
| 62443-1-1 | Concepts and models (terms, zones, security levels) | 2009 |
| 62443-2-1 | Security programme for asset owners | 2024 |
| 62443-2-4 | Requirements for service providers (e.g. remote maintenance) | 2023 |
| 62443-3-2 | Risk assessment and system design (zones and conduits) | 2020 |
| 62443-3-3 | System requirements and security levels | 2013 |
| 62443-4-1 | Secure product development lifecycle | 2018 |
| 62443-4-2 | Technical requirements for components | 2019 |
Three parts are central for remote access: 62443-3-2 provides the zone model, 62443-3-3 the system requirements, and 62443-4-2 the component requirements.
Zones and conduits: the architecture model
The heart of the standard is segmentation. A zone groups assets with the same protection needs - for example a machine cell, a SCADA system, or office IT. A conduit is the single controlled communication path between two zones and enforces defined security measures there. Direct connections across zone boundaries are not allowed.
For remote access the picture is clear: an external maintenance session never runs directly onto the controller but through a conduit that typically terminates in a DMZ at the IT/OT boundary. How to build this separation cleanly is covered in OT/IT segmentation with a DMZ for remote maintenance.
Security levels SL 1 to 4 and the seven foundational requirements
Every zone and conduit is assigned a target security level (SL-T). The levels describe the type of attacker you protect against:
- SL 1: Protection against casual or accidental violation.
- SL 2: Protection against simple intentional attacks with low resources and generic skills.
- SL 3: Protection against sophisticated attacks with moderate resources and IACS-specific skills.
- SL 4: Protection against attacks with extensive resources and high motivation (nation-state-class actors).
The requirements are grouped into seven foundational requirements (FR): FR1 identification and authentication control (IAC), FR2 use control (UC), FR3 system integrity (SI), FR4 data confidentiality (DC), FR5 restricted data flow (RDF), FR6 timely response to events (TRE), and FR7 resource availability (RA). Each FR receives its own SL target, so a zone is described by an SL vector of seven values. Higher levels are reached through requirement enhancements (RE): the base requirement applies from SL 1, RE 1 is added at SL 2, RE 2 at SL 3, and RE 3 at SL 4.
62443-3-3 and 62443-4-2: system and component requirements (status 2026)
62443-3-3:2013 defines 51 system requirements (SR) for a complete control system and the associated SL-C capability. 62443-4-2:2019 translates this logic to individual products and describes component requirements (CR) for four component types: software application, embedded device, host device, and network device. Both parts link through the same seven FRs - a system reaches its SL only if its components provide the matching capability.
On currency: the core documents remain in force (3-3 from 2013, 4-2 from 2019). A revision is running in parallel, above all EN IEC 62443-4-2:2019/prAA:2026, which was at DIS ballot in early 2026. The aim is harmonisation with the EU Cyber Resilience Act so that EN IEC 62443 can be cited as a listed European standard for CRA conformity. If you are building today, implement the existing editions and track the drafts - their main additions tighten secure boot, firmware signing, and the evaluation methodology.
What the standard concretely requires for secure remote access
From the system requirements in 62443-3-3 you can derive a concrete checklist for remote access:
| Remote access requirement | Foundational requirement | Example SR |
|---|---|---|
| MFA for access via untrusted networks | FR1 (IAC) | SR 1.1 RE2 |
| Monitor and control all access methods | FR1 (IAC) | SR 1.13 |
| Least privilege (authorization enforcement) | FR2 (UC) | SR 2.1 |
| Automatic termination of idle remote sessions | FR2 (UC) | SR 2.6 |
| Auditable events, timestamps, non-repudiation | FR2 (UC) | SR 2.8 to 2.12 |
| Integrity-protected communication | FR3 (SI) | SR 3.1 |
| Encrypted channels (confidentiality) | FR4 (DC) | SR 4.1 |
| Network segmentation and zone boundary protection | FR5 (RDF) | SR 5.1, SR 5.2 |
| Continuous monitoring of access | FR6 (TRE) | SR 6.1, SR 6.2 |
In short: no direct reach-through to OT, every remote session through a controlled boundary, each session authenticated, authorized, encrypted, time-limited, and logged. How to turn this into practical remote maintenance is covered in the guide Secure remote maintenance of machines and plants.
How a sovereign platform implements IEC 62443
A bare VPN does not meet these requirements - it connects networks instead of controlling access. A sovereign remote management platform instead brings identity, authorization, encryption, and audit together at a controlled boundary, operated in Germany and free of dependence on US cloud services:
- Identity and MFA centrally through an identity provider such as Authentik, covering SR 1.1 and SR 1.13.
- Encrypted conduits via WireGuard that cleanly separate OT zones from IT (SR 3.1, SR 4.1, SR 5.1).
- Least privilege, session limits, and recording through a browser gateway, so no broad VPN client is needed on third-party devices (SR 2.1, SR 2.6).
- Monitoring and audit through a SIEM such as Wazuh, backed by ongoing CVE monitoring and a regular security audit of the architecture (SR 6.1, SR 6.2).
This approach already proves itself in practice: for ABCO Water Systems in Australia we operate the hardened remote access to distributed water treatment plants with HMI access, role-based permissions, and a full audit trail - exactly the model of zones, conduits, and controlled sessions that IEC 62443 describes. Where network access needs a mesh VPN, WZ-IT operates it as Managed NetBird from €349.90 net per month; the base package includes monitoring, updates, backups and support.
IEC 62443 vs. NIS2: standard versus law
The two frameworks interlock but sit at different levels. NIS2 and Germany's NIS2UmsuCG are law: they mandate that in-scope entities implement risk management measures under Section 30 of the BSIG and threaten fines for non-compliance. IEC 62443 is a standard: it describes in technical detail what those measures look like for OT. The law states the "whether" and "that", the standard provides the "how".
In practice operators use IEC 62443 for exactly this: to demonstrate, in a structured way, the state of the art that NIS2 requires. Which NIS2 obligations specifically apply to remote access is covered in the guide on NIS2-compliant remote access.
This article is general information and not legal advice. For a binding assessment of your obligations and the right security level targets, please consult qualified advisors; we are happy to support the technical implementation. Book a free initial consultation.
