IEC 62443 for OT Remote Access: the Standard Explained
Timo Wevelsiep•Updated: 30.06.2026Editorial note: Versions, commands and prices may change. Please verify critical steps independently before production use. This guide does not replace individual consulting.
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.
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.
Frequently Asked Questions
Answers to the most important questions
IEC 62443 is the international series of standards for the cybersecurity of industrial automation and control systems (IACS), developed by IEC TC65 and ISA99. It is a voluntary technical standard, not a law, but it is widely recognised as the state of the art for OT security. The series is structured in four layers: general concepts (1-x), policies and processes (2-x), system requirements (3-x), and component requirements (4-x).
For remote access the standard mainly requires unique identification and multi-factor authentication for access via untrusted networks (SR 1.1 RE2, SR 1.13), least privilege through authorization enforcement (SR 2.1), automatic termination of idle remote sessions (SR 2.6), complete logging with timestamps (SR 2.8 to 2.12), encrypted and integrity-protected channels (SR 3.1, SR 4.1), and clean network segmentation into zones and conduits (SR 5.1, SR 5.2).
A zone groups assets with the same protection needs, for example a machine cell or a control system. A conduit is the controlled communication path between two zones. Each conduit enforces defined security measures, so that a single vulnerability stays confined to one zone. The model comes from IEC 62443-3-2 and is the basis of any standard-aligned remote maintenance architecture.
Security levels describe the type of attacker a zone or conduit must withstand. SL 1 protects against accidental violations, SL 2 against simple intentional attacks with low resources, SL 3 against sophisticated attacks with moderate resources and IACS-specific skills, and SL 4 against attackers with extensive resources. Each of the seven foundational requirements gets its own SL target, producing an SL vector per zone.
62443-3-3:2013 defines the system requirements (SRs) for an entire control system and the associated security levels. 62443-4-2:2019 defines the component requirements (CRs) for individual products such as controllers, embedded, host, and network devices. Both link through the same seven foundational requirements: the system (3-3) inherits its capability from the interplay of conformant components (4-2).
The core documents remain in force: 62443-3-3 in its 2013 edition, 62443-4-2 in its 2019 edition. Amendment drafts are in progress, notably EN IEC 62443-4-2:2019/prAA:2026, which was at DIS ballot in early 2026. The goal is harmonisation with the EU Cyber Resilience Act so that the standard can be cited as a listed European standard for CRA conformity.
Both, but at different levels. NIS2 and Germany's NIS2UmsuCG are law and mandate that you implement risk management measures. IEC 62443 is a standard that describes technically how to do it. In practice operators use IEC 62443 to demonstrate the state of the art that Section 30 of the BSIG requires in a structured, auditable way.
More on Remote Access
- What is Apache Guacamole?
- VNC in the browser: HMI remote access
- Remote maintenance without a VPN client
- Self-hosted TeamViewer alternative (RustDesk)
- NIS2-compliant remote access
- RBAC & audit for remote access
- What is ZTNA? (Zero Trust Network Access)
- IEC 62443 for remote access to OT
- SSO & MFA for the remote-access portal
- Privileged access management & session recording
- Remote maintenance & GDPR (data processing)
- WireGuard for site connectivity
- What is NetBird? (Zero-trust mesh VPN)
- What is Headscale?
- Expose internal services without a VPN
- Multi-tenant operator portal for plants
- OT/IT segmentation, DMZ & the Purdue model
- SSH bastion / jump host
- Siemens S7 / PLC remote access without open ports
- NetBird vs Tailscale vs WireGuard
- OpenVPN vs WireGuard
- Secure remote maintenance of machines & plants







