The Problem with Traditional VPNs in Industrial Environments
Traditional VPNs (site-to-site IPSec, server-based OpenVPN) were designed to connect corporate networks, not to support the maintenance of OT equipment by field technicians. When applied to an industrial context, they create well-documented operational complexities and security risks.
Maintenance teams know this: Setting up a VPN connection to troubleshoot a PLC remotely often involves submitting a ticket to the IT department, configuring firewall rules, installing a client on the technician’s computer, and sometimes assigning a fixed public IP address to the site—all before even being able to connect.
Modern industrial remote access addresses these challenges with a fundamentally different architecture.
Comparison of Traditional VPN vs. Eziwan Industrial Remote Access
| Criterion | Traditional VPN (IPSec/OpenVPN) | Eziwan Industrial Remote Access |
|---|---|---|
| Configuration | Complex (VPN concentrator, NAT/PAT rules) | Zero-config at the field level (ZTP) |
| Inbound Ports | Yes (UDP 500/4500 or TCP/UDP 1194) | None (outbound reverse tunnel) |
| Authentication | Pre-shared key or certificate | MFA (TOTP, SMS) + TLS certificate |
| Multi-site | Concentrator per site or hub-and-spoke VPN | Single portal for the entire fleet |
| Access granularity | Access to the entire VPN subnet | Access by device, by user |
| Audit and traceability | Basic logs on the concentrator | Comprehensive log: who, when, how many |
| Technician client | VPN software to be installed | Web browser only |
| Updates | Manual (concentrator firmware) | Automatic OTA via the cloud |
| Public IP required | Often (in the field) | No (outbound connection only) |
Reverse-tunnel architecture: Why no incoming ports are required
The fundamental architectural difference between a traditional VPN and Eziwan remote access is the direction of the initial connection.
Traditional VPN: The VPN concentrator listens on UDP ports 500 (IKE) and 4500 (NAT-T) for IPSec, or on TCP/UDP port 1194 for OpenVPN. The remote technician initiates the connection to the industrial site. These ports must be open and exposed to the Internet.
Eziwan Remote Access: The field router initiates an outbound connection to the Eziwan platform on HTTPS port 443—which is generally allowed through all industrial firewalls. This persistent tunnel is maintained at all times. When a technician logs in from the portal, the connection is routed through this existing tunnel. No incoming ports are ever opened on the field side.
Terrain (routeur Eziwan) → connexion HTTPS sortante → Cloud Eziwan
Technicien (navigateur) → portail web Eziwan → Cloud Eziwan
(proxy via tunnel)
Security: The Principle of Least Privilege Applied to OT
With a traditional site-to-site VPN, an authenticated technician gains access to the entire OT site subnet—typically a /24 subnet with dozens of devices. If the technician’s account is compromised (through phishing or credential stuffing), the attacker gains access to the entire OT network.
Eziwan Remote Access applies the principle of least privilege at the device level:
- By site: A technician is authorized only for the sites they maintain
- By equipment: Access to a specific Siemens HMI, not to the entire OT network
- By time slot: Access authorized only during maintenance windows
- Per session: Each connection generates a timestamped log containing the technician’s identity, the equipment accessed, and the duration
This traceability is essential for security audits and NIS2 compliance.
Zero-Trust: The Four Pillars of the Eziwan Architecture
1. No implicit trust — even from within the network, every access request is authenticated. The technician must authenticate using MFA for each session.
2. Least-Privilege Access — Each user’s access is limited to the resources necessary for the task at hand. No broad network access.
3. Microsegmentation — the OT network remains segmented; remote access opens only the necessary data flows to the target device.
4. Continuous monitoring and logging — all sessions are logged (who, when, source IP address, target OT device, duration) for traceability and anomaly detection.
Use Case: Remote Maintenance Without a Traditional VPN
Urgent Corrective Maintenance — A PLC triggers an alarm at 2 a.m. The on-call technician logs in from his phone using the Eziwan mobile app, accesses the PLC’s HMI in less than 30 seconds, diagnoses the issue, and restarts the process. No VPN client required, and no need to call IT support to grant access.
Maintenance Contractor — An outside service provider needs to work on a variable-frequency drive. You create temporary access for them in the Eziwan portal: authorized only for this drive, during the 4 hours of scheduled maintenance. The access expires automatically. You do not provide them with your IT system’s VPN credentials.
Security Audit — The CISO requests a list of remote accesses to OT sites from last month. The Eziwan portal generates a comprehensive report: every session, every technician, every piece of equipment accessed, and the duration of each session—all with just a few clicks.
How to Migrate from a Traditional VPN
The migration to Eziwan remote access can be done gradually, without interrupting existing access:
-
Phase 1 — Coexistence: The Eziwan router maintains the existing IPSec VPN tunnel to your IT system and simultaneously establishes the Eziwan reverse tunnel. The two connections coexist.
-
Phase 2 — Pilot Validation: At 3 to 5 sites, technicians use Eziwan remote access alongside the VPN. Validation of access quality and coverage of use cases.
-
Phase 3 — Transition: Gradual migration of technicians to the Eziwan portal. The traditional VPN remains in place as a backup during the transition period.
-
Phase 4 — Simplification: Removal of the VPN concentrator and associated firewall rules once the transition is complete.
See also: Personal APN vs. Industrial VPN · Industrial 4G vs. 5G Router · Teltonika Alternatives