Secure Remote Access for PLCs and SCADA: Architecture, VPN, and NIS2 Compliance
By 2025, more than 78% of industrial PLC malfunctions can be diagnosed and resolved remotely—without the need for a technician to visit the site. Yet most manufacturers still send a technician on-site for 15- to 30-minute service calls that cost them €800 to €2,000 each. The main obstacle: the (legitimate) fear of exposing their OT network to the Internet.
This guide answers the question that all automation and industrial IT managers ask: How can you enable remote access to your PLCs without creating a vulnerability in your OT network? Technical architecture, VPN protocols, access control, audit trails, NIS2 compliance—it covers it all.
Why OT Remote Access Is Not Like IT Remote Access
The Specific Constraints of OT Networks
Operational Technology (OT) networks have constraints that are radically different from those of the traditional IT world. Ignoring them means either losing remote access or creating a major security vulnerability.
Legacy protocols that are insecure by design:
- Modbus TCP/RTU: no authentication, no encryption—designed in 1979 for closed networks
- S7comm (Siemens): proprietary protocol, port 102, vulnerable to man-in-the-middle attacks without an external encryption layer
- EtherNet/IP (Rockwell): port 44818, CIP protocol — no native security in older versions
- PROFINET: Siemens/Ethernet real-time protocol, latency-critical, incompatible with standard application proxies
Real-time constraints and availability: A PLC controlling a production line cannot be restarted to apply a security patch. Maintenance windows are scheduled in advance, often on a monthly or annual basis. Any unplanned interruption—even as short as 30 seconds—can have serious physical or financial consequences.
Aging equipment in production: Siemens S5, Schneider Premium, and Allen-Bradley SLC 500 PLCs that are 15 to 25 years old are commonly found in production. No built-in encryption, no modern authentication—just RS485 and Modbus.
Very Different Consequences of a Breach: A breach of the IT network compromises data. An intrusion into the OT network can shut down a production line, trigger a safety failure, or, in the worst-case scenario, cause a physical incident (as in the 2015 Ukrainian Power Grid incident or the 2017 Triton/TRISIS attack on an instrumented safety system).
The Most Dangerous Trap: Direct Port Forwarding
The temptation is real: to open port 102 (S7) or port 80 (web HMI) on the site's router and access the PLC from anywhere. It's quick, requires no configuration—and is disastrous.
In 2024, the Shodan search engine continuously indexes more than 45,000 industrial control systems directly exposed to the Internet in France. A Siemens PLC accessible via the S7-comm port is detected by automated scanners in less than 48 hours. Documented consequences include:
- Tampering with PLC programs by malicious actors
- Intentional production shutdowns (OT ransomware)
- Exfiltration of know-how (programs, recipes, production parameters)
- Sabotage of safety instrumented systems (SIL)
No PLC (Siemens, Schneider, Rockwell, ABB, Omron) should be directly accessible from the Internet—even if protected by a password, even on a non-standard port. The only secure architecture relies on a VPN or a Zero Trust Network Access system.
The 3 Secure Remote Access Architectures
Architecture 1: Site-to-Office VPN — the industry standard
This is the most common architecture and the one best suited for 90% of industrial applications. An on-site industrial router maintains a constant encrypted outbound VPN tunnel to a cloud hub or your data center. The technician connects via a VPN client on their computer.
Key Features:
- No incoming ports on the site network—the site firewall blocks all incoming traffic
- The VPN tunnel is established from the inside to the outside (outbound connection from the gateway)
- All OT protocols pass through the encrypted tunnel: S7comm, Modbus TCP, EtherNet/IP, PROFINET (Layer 2)
- The technician sees the PLC as if it were locally on the site’s LAN
- TIA Portal, Unity Pro, Studio 5000, FactoryTalk — compatible without modification
Setup: 20 minutes on the site side (Gateway installation), 5 minutes on the technician's side (OpenVPN or WireGuard client).
Architecture 2: Jump Server / OT Bastion
In environments with strict security policies (chemical, nuclear, and water industries) or involving multiple teams of personnel (service providers, integrators, and machine manufacturers), a bastion server enhances isolation.
The bastion server only forwards explicitly authorized connections. It logs all traffic, blocks everything by default, and grants access only to devices on the whitelist defined for each technician.
Recommended for: OIV, EE (NIS2), ISO 27001-certified sites, high-risk industries (chemical, pharmaceutical, energy).
Architecture 3: Zero Trust Network Access (ZTNA)
For large fleets (50+ sites) with multiple teams and external partners (OEM equipment manufacturers, integrators, subcontractors), the Zero Trust model is essential. The principle: never trust, always verify.
Each access attempt is evaluated based on:
- Identity: Who is logging in? (MFA required, LDAP/SSO compatible)
- Context: From which device? At what time? From which location?
- Least Privileges: Access only to mission-critical systems, nothing more
- Auditability: Every command and every data flow is audited and can be replayed
| Criterion | Traditional VPN | Bastion | ZTNA |
|---|---|---|---|
| Deployment Complexity | Low | Medium | High |
| Permission Granularity | Network/VLAN | Device | Variable/session |
| Auditing and Traceability | VPN connections | SSH commands | All actions |
| Scalability (100+ sites) | Medium | Good | Excellent |
| NIS2 OIV-compliant | Yes (properly configured) | Yes | Yes (native) |
| Infrastructure cost | Low | Medium | High |
Practical Guide: Remote Access to a Siemens S7-1200 PLC
Prerequisites
- Eziwan gateway installed on the site network (subnet 192.168.1.0/24)
- S7-1200 PLC at address 192.168.1.10 (confirm via TIA Portal locally)
- Technician account created on the Eziwan platform
- TIA Portal v17 or later installed on the technician’s PC
- OpenVPN or WireGuard client installed
Step 1 — Check the site's network topology
From the Eziwan dashboard → Site → Network Configuration:
# From the Gateway's CLI interface (local SSH or console)
eziwan route list
# Expected result:
# 192.168.1.0/24 via eth0 (LAN) → announced via VPN tunnel
# 0.0.0.0/0 via lte0 (WAN) → default route LTE
eziwan connectivity test 192.168.1.10
# Expected result:
# Ping 192.168.1.10 OK (4ms)
# Port 102 (S7) : OPEN
Step 2 — Create a technician account on the platform
Eziwan Dashboard → Access → Technicians → New Access:
- Enter the technician's email address (automatic invitation)
- Select the authorized site(s):
Site-Lyon-Usine-A - Set the time range:
Lun-Ven 7h-19h - Select the accessible devices (optional):
192.168.1.10only - Access expiration date (recommended for service providers)
- Generate the VPN profile — OpenVPN
.ovpnor WireGuard.conf
The technician receives an email containing their encrypted configuration file and installation instructions.
Step 3 — Installing the VPN client (technician)
Windows (recommended: OpenVPN GUI):
# Installation via winget
winget install OpenVPN.OpenVPN
# Import the profile (drag and drop it into the OpenVPN notification area)
# or via the command line:
openvpn --config "C:\eziwan\site-lyon.ovpn" --daemon
Linux:
sudo apt install openvpn network-manager-openvpn-gnome
# Import the profile via NetworkManager
sudo nmcli connection import type openvpn file /home/user/site-lyon.ovpn
sudo nmcli connection up site-lyon
macOS (Tunnelblick):
# Installer Tunnelblick (tunnelblick.net)
# Double-click the .ovpn file → automatic import
Step 4 — Connecting to the PLC
Once the VPN is active, TIA Portal detects the PLC as if it were on the local network:
TIA Portal → Online → Accessible devices
→ 192.168.1.10 — Siemens S7-1200 CPU 1212C DC/DC/DC
→ Firmware: V4.5
→ S7comm connection (port 102) established
→ Tunnel latency: 18 ms (acceptable for TIA Portal)
What's happening technically:
Typical total latency: 15 to 35 ms on 4G LTE — more than enough for TIA Portal, which works properly up to 100 ms.
Compatibility via PLC Programming Software
| Software | Manufacturer | Protocol | Eziwan VPN Compatible | Notes |
|---|---|---|---|---|
| TIA Portal v17+ | Siemens | S7comm / PROFINET | ✅ Native | Latency < 50 ms required |
| Unity Pro / EcoStruxure | Schneider | MODBUS TCP / UNI-TE | ✅ Native | M340, M580, Premium |
| Studio 5000 / FactoryTalk | Rockwell | EtherNet/IP / CIP | ✅ Native | ControlLogix, CompactLogix |
| Sysmac Studio | Omron | EtherNet/IP / FINS | ✅ Native | NX, NJ series |
| GX Works | Mitsubishi | MELSEC | ✅ Native | Q, FX5 series |
| CODESYS | Multi-vendor | MODBUS TCP / OPC-UA | ✅ Native | CODESYS Runtime |
| Step 7 Classic | Siemens (legacy) | S7comm | ✅ Compatible | S7-300/400, S7 v1 protocol |
TIA Portal is sensitive to latency during online debugging sessions. Above 80 ms, behavior may become erratic (connection timeouts, slow display of blocks online). 4G LTE typically provides 15–35 ms, which is acceptable. 3G (if still available), with 80–150 ms, can cause problems.
Remote Access to a HMI and a SCADA System
Siemens WinCC / KTP HMI (via VPN)
The HMI is on the site's local network (e.g., 192.168.1.20). With the VPN active:
- WinCC Runtime: accessible directly via the local IP address
- Simatic HMI: S7comm protocol; behaves the same as the PLC
- KTP Panel: accessible via TIA Portal online
Wonderware AVEVA SCADA (HTTPS reverse proxy)
For SCADA systems with a web interface (Wonderware, Ignition, WinCC OA), Eziwan can configure a secure reverse proxy without requiring a VPN on the user side:
# Reverse Proxy Configuration on the Eziwan Gateway
proxy_rules:
- name: scada-lyon
description: "SCADA Wonderware System Platform — Usine Lyon A"
internal: http://192.168.1.100:80
external: https://scada-lyon.eziwan.com
tls: true # HTTPS with an auto-renewing Let's Encrypt certificate
auth: eziwan_sso # SSO Eziwan with mandatory MFA
allowed_users:
- superviseur@entreprise.fr
- technicien-maintenant@entreprise.fr
session_timeout: 30m # Logout after inactivity
audit_log: true # All logged actions
Users access https://scada-lyon.eziwan.com through their browser, authenticate via SSO + MFA, and are directed to the SCADA interface—without a VPN client, from any device.
Ignition (Inductive Automation)
Ignition has a native web gateway. With Eziwan:
Ignition Gateway (192.168.1.50:8088)
→ Access via the Eziwan reverse proxy with HTTPS + MFA
→ Or direct access via VPN (local port 8088)
→ Or via Ignition Cloud (if an Ignition Cloud license is included)
The 7 Golden Rules of OT Remote Access Security
1. No incoming ports exposed on the site
This is an absolute rule. The Eziwan Gateway blocks all incoming ports by default. The only allowed connection is outgoing (VPN tunnel to the cloud). Even the Gateway’s SSH management port is disabled on the WAN side.
2. Systematic MFA for all access points
No access to a VPN connection, the Eziwan portal, or SCADA access without two-factor authentication. Supported methods: TOTP (Google Authenticator, Authy), FIDO2 physical key (YubiKey), SMS (not recommended).
3. Time-Limited Access for Service Providers
A system integrator working on your bottling line for two days does not need permanent access. Create an access permission with an expiration date and a time range. The access permission is automatically revoked.
4. One account per person; no shared credentials
A single VPN account shared by the entire team = no traceability. Each technician (in-house or external) must have their own personalized account. In the event of an incident, you'll know exactly who was connected and when.
5. Comprehensive logging and a minimum retention period of 12 months
All VPN connections, configuration changes, and access to equipment must be logged, including: timestamp, identity, source IP address, and session duration. Minimum retention period: 12 months (NIS2 requires 3 years for OIVs).
6. Strict OT/IT Segmentation
Control systems (OT network) must not be on the same VLAN as the IT servers. The Eziwan Gateway can manage multiple LAN interfaces with strict inter-VLAN firewall rules. Access from the IT network to the OT network goes through a controlled DMZ.
7. Immediate Revocation of Access Upon Departure
Departure Protocol: Account deactivation on the day of departure, immediate deactivation of the VPN certificate, and audit of sessions from the past 30 days. To be documented in your HR procedure.
NIS2 and IEC 62443 Compliance
NIS2 Requirements for Remote Access
The NIS2 Directive (which has been in effect in France since October 2024 following its transposition) requires critical and important entities to implement specific measures regarding remote access:
| NIS2 Requirement | Article | Eziwan Solution |
|---|---|---|
| Strong Authentication (MFA) | Art. 21 §2b | TOTP/FIDO2 MFA for all access |
| Communication Encryption | Art. 21 §2h | OpenVPN AES-256-GCM or WireGuard ChaCha20 |
| Access Logging | Art. 21 §2j | Comprehensive, exportable logs with configurable retention |
| Third-Party Access Management | Art. 21 §2i | Temporary, user-specific, revocable access |
| Incident notification | Art. 23 | Automatic alerts for abnormal access |
| Vulnerability management | Art. 21 §2e | Gateway firmware automatically updated |
IEC 62443 Mapping
The IEC 62443 standard defines Security Levels (SL) for industrial control systems. The Eziwan architecture covers:
| Security Level | Requirements Covered by Eziwan |
|---|---|
| SL 1 — Protection against unintentional attacks | Basic authentication, firewall, logs |
| SL 2 — Protection against simple intentional attacks | MFA, encryption, audit trail, segmentation |
| SL 3 — Protection against sophisticated attacks | ZTNA, advanced network segmentation, anomaly detection |
The Eziwan platform generates a downloadable NIS2 compliance report (PDF) that includes: an access inventory, logs for the last 12 months, and security configuration. It can be used directly for your ANSSI audits or by third-party auditors.
Troubleshooting: Common Problems
TIA Portal cannot detect the PLC via VPN
Possible causes:
- The route to the site's subnet is not being forwarded by the VPN → check the tunnel interface configuration (
eziwan route liston the gateway) - The Windows firewall is blocking S7comm on the "Public" network → change the VPN network profile to "Private"
- S7comm timeout < tunnel latency → in TIA Portal, increase the connection timeout to 5,000 ms (Settings → PG/PC Interface)
Latency too high for TIA Portal (> 80 ms)
Checks:
# Ping test from the technician's PC to the PLC (VPN active)
ping 192.168.1.10 -n 20
# If latency > 80 ms, check:
# 1. 4G signal quality at the site (RSRP > -100 dBm recommended)
eziwan modem signal
# 2. VPN hub location (select Europe/France)
# 3. Network congestion on the technician's end (test from another network)
VPN connection established but PLC inaccessible
# Check the route from the Gateway
eziwan route test 192.168.1.10
# If a timeout occurs: Check the Ethernet cable between the gateway and the site switch
# Check that the PLC responds locally
eziwan ping 192.168.1.10 --source lan
# If a timeout occurs: Check the PLC's IP configuration and physical status
Frequently Asked Questions
How many technicians can connect at the same time? There is no limit on the number of simultaneous VPN connections in standard Eziwan plans. At a single site, two technicians can work simultaneously on different PLCs. The 4G bandwidth (typically 20–50 Mbps) is shared among all active connections.
Is it possible to use our existing corporate VPN instead of Eziwan? Yes, if your corporate VPN can interface with a router that establishes a standard IPSec tunnel. The Eziwan Gateway supports IPSec/IKEv2 as an alternative tunnel. However, the loss of audit trails, granular access control, and ZTP is significant for multi-site fleets.
Can remote maintenance sessions be recorded (video)? Session recording (screen recording) is available in the Eziwan Enterprise plan through integration with PAM (Privileged Access Management) tools such as CyberArk or Teleport. It is not a native feature of the standard plan.
Does remote access work for PLCs using non-IP protocols (Profibus, HART)? For Profibus: Requires a Profibus → Modbus TCP or Profibus → Ethernet gateway on-site. This type of gateway (e.g., Anybus X-gateway) is then accessible via the VPN tunnel. For HART: HART transmitters are generally accessible via their local Modbus interface or via a HART multiplexer.
How do you handle a contractor technician who changes companies? Revocation is immediate via the Eziwan portal: the account is deactivated, the VPN certificate is revoked, and access is cut off instantly. The technician can no longer log in, even if they retain their VPN configuration file (the revoked certificate is rejected by the gateway).
Does remote access interfere with the PLC's operation? No—the Eziwan Gateway is a transparent network device. It does not interfere with the fieldbus or PLC-HMI communications. The PLC does not “see” the remote connection: it receives Modbus or S7comm requests as if it were being queried from the local network.
Further Reading
- Comparison: Industrial VPN vs. Zero Trust for OT
- Guide: OT Cybersecurity — Threats and Protections 2026
- NIS2 Compliance Checklist for Industry
- Documentation: VPN Configuration on the Eziwan Gateway
- Guide: Industrial 4G LTE Router — Migrating from ADSL
- Use Case: OEM Machine Manufacturers — Integrated Remote Maintenance
Secure remote access to your PLCs is no longer a luxury in 2025—it is an operational necessity (reducing service call costs) and a regulatory requirement (NIS2). With the right architecture, you can reduce your field maintenance costs by a factor of 3 to 5 while simultaneously strengthening the security of your OT network.
Need an audit of your current remote access architecture? Schedule a technical demo — our team will perform a comprehensive assessment of your OT security in 45 minutes.
Additional Resources
- Remote Access to PLCs — secure remote access solutions for industrial controllers
- Industrial Remote Access — VPN and zero-trust architecture for industrial sites
- Cloud SCADA — SCADA monitoring from the cloud with secure remote access
- Guide: Remote Access to PLCs — a comprehensive guide to remotely accessing your PLCs
- Industrial Monitoring and Remote Support — remote support solutions for industry
