Industrial VPN vs. TeamViewer: Why Consumer-Grade Tools Are Not Sufficient in OT Environments
This question comes up regularly in industrial remote access projects: "Why not just use TeamViewer? That's what we already do for IT support."
The short answer: OT networks are not IT networks. The controllers running on them operate physical machines—an erroneous command or an intrusion can have industrial—or even human—consequences. Consumer-grade tools were designed for a radically different context.
This article goes beyond a simple answer. It explains the actual threat model, details the requirements of the IEC 62443 standard, and presents the technical criteria for evaluating an industrial remote access solution.
1. The Purdue Model and OT Confidence Levels
To understand why OT remote access is different, you need to be familiar with the Purdue model (Purdue Enterprise Reference Architecture), the international standard for industrial network segmentation.
Niveau 5 : Réseau d'entreprise (ERP, email, bureautique)
─────────────────────────────────────────────
Niveau 4 : Réseau IT de site (serveurs, SGBD, Active Directory)
─────────────────────────────────────────────
Niveau 3 : Réseau supervision (SCADA, MES, historiens)
─────────────────────────────────────────────
Niveau 2 : Réseau contrôle (IHM, ingénierie)
─────────────────────────────────────────────
Niveau 1 : Réseau terrain (automates, variateurs, capteurs)
─────────────────────────────────────────────
Niveau 0 : Process physique (capteurs, actionneurs, moteurs)
Industrial remote access typically involves Levels 1 and 2—PLCs and engineering tools. These levels must never be directly accessible from higher levels without control, and certainly not from the Internet.
Segmentation between network layers is the first line of defense. Remote access, by definition, crosses this segmentation—hence the enhanced security requirements.
2. The Real Risks of Uncontrolled Access to an OT Network
What Is Exposed on an Industrial OT Network
A typical OT network includes:
- Programmable logic controllers (S7, M340, CompactLogix) that control the machines
- Variable-frequency drives that control the motors
- Industrial HMIs for monitoring and configuration
- SCADA systems that monitor the entire process
- Measuring instruments (pressure, temperature, and flow sensors)
This equipment was designed for reliability in isolated environments, not to withstand network attacks. The Modbus protocol does not provide for any authentication. S7Comm (Siemens) historically had no encryption. Profinet, EtherNet/IP—most industrial protocols assume a trusted network.
Anatomy of an Attack on an Insecure OT Remote Access System
Here's how an unsecured industrial remote access system is typically compromised:
Phase 1 — Reconnaissance (automatic, passive): An automated scanner (Shodan, Censys, or a custom script) identifies the plant’s public IP address and discovers an open port (standard VPN on UDP 1194, Modbus port 502, S7Comm port 102). This phase does not generate any suspicious logs and lasts a few seconds.
Phase 2 — Exploiting the Access: If the VPN is protected only by a weak password (or if the credentials have been stolen through phishing), the attacker gains access. If it is a directly exposed Modbus port, the attacker can read and write without any authentication.
Phase 3 — Internal Reconnaissance: Once access has been gained, the attacker maps the OT network: which PLCs are accessible, which variables can be read, and which process zones are controlled.
Phase 4 — Malicious Action: Actions may be immediate (shutting down production, changing parameters) or covert (gradually changing setpoints to degrade product quality without triggering an alarm).
The most dangerous attacks are not the most spectacular ones. A change of ±5% in a dosing setpoint at a chemical or pharmaceutical facility may go undetected for days, with potentially catastrophic consequences for the quality of the finished product.
Documented Incidents
ANSSI and CISA (Cybersecurity and Infrastructure Security Agency, United States) regularly document incidents involving poorly secured industrial remote access systems:
- TeamViewer on a water treatment control station (Florida, 2021): An attacker altered chemical treatment levels via TeamViewer installed on the SCADA system of a drinking water treatment plant. The attack was detected by the on-site operator, but could have gone unnoticed.
- VPNs without MFA in the energy sector: Several documented incidents in which stolen VPN credentials allowed access to regional power grids in Europe.
- Modbus port forwarding: Security researchers have consistently demonstrated the ability to modify settings on industrial control systems accessible directly from the Internet.
3. Open Ports vs. Outbound Tunnels: The Fundamental Difference
"Exposed Inbound Port" Architecture
[Internet] ──→ [Pare-feu usine : port ouvert] ──→ [Réseau OT] ──→ [Automate]
This model exposes an Internet access point. Whether it is a VPN port (UDP 1194 for OpenVPN, UDP 500/4500 for IPsec) or an application port (502, 102, 443), this port is constantly monitored.
Life Cycle of an Exposed Port:
- Port opens → indexed by Shodan within 24–48 hours
- Initial scanning attempts → a few days after the port is exposed
- Automated exploitation attempts → as soon as a known signature is identified
- Targeted exploitation → if the system is identified as critical or of interest
"Outbound-Only Tunnel" Architecture
[Réseau OT] ──→ [Gateway : connexion sortante] ──→ [Cloud] ←── [Opérateur]
What’s fundamentally different:
- The connection is initiated from the inside — just like a web browser
- From the factory firewall’s perspective: outbound HTTPS traffic to a known IP address
- No incoming ports to open, no firewall rules to modify
- No exposed ports = no network attack surface on the factory side
If the Eziwan cloud infrastructure were compromised (a hypothetical scenario), an attacker would not be able to bounce through to the factory network—the connection is one-way from the perspective of the initiator.
Why TeamViewer Isn't "As Secure" as OpenVPN
TeamViewer does use a cloud relay (the attacker does not connect directly to the factory), but the structural issues are different:
| Issue | Explanation |
|---|---|
| Third-party infrastructure | Sessions pass through TeamViewer servers. If TeamViewer is compromised (as it was in 2016), your sessions are too. |
| Audit trail dependent on subscription | Full logs are only available with premium subscriptions. In the free version, there are no exportable logs. |
| Inadequate authentication model | A 9-digit code exchanged via email does not constitute strong authentication. |
| No OT isolation | TeamViewer grants access to the Windows machine running it—and from that machine, potentially to the entire OT network. |
4. What IEC 62443 and ANSSI Say
IEC 62443 — the reference standard
The IEC 62443 standard defines cybersecurity requirements for industrial systems. For remote access, Security Level 2 (SL2)—the recommended level for most industrial facilities—requires:
SR 1.1 — Human Identification and Authentication: Every user accessing the system must be individually identified and authenticated. Shared accounts (a single "maintenance" account for the entire team) are explicitly prohibited.
SR 1.7 — Enhanced Authentication (Enhancement SL2): Two-factor authentication (MFA) is required for remote access at the SL2 level. A password alone is not sufficient.
SR 2.6 — Access via Untrusted Networks: All access from the Internet to the OT network must be encrypted, authenticated, and logged. This requirement is the normative equivalent of an outbound tunnel + MFA + audit logs.
SR 6.2 — Continuous Monitoring: Remote access must be logged continuously—who logged in, when, from which IP address, and for how long.
ANSSI Recommendations
ANSSI publishes guides specifically for industrial systems. Its five principles for industrial remote access are:
- Segmentation: Remote access must not pass directly through the OT network—it must go through an industrial DMZ
- Strong Authentication: MFA is mandatory for all remote access to Level 1 or 2 equipment
- Encryption: all remote communications must be encrypted using up-to-date algorithms
- Logging: comprehensive, exportable, time-stamped logs retained for at least 3 months
- Least privilege: each technician may only access equipment within their scope
ANSSI publishes these recommendations in its guide "Managing Digital Risk in Industrial Systems," which can be downloaded for free at ssi.gouv.fr. All industrial maintenance managers are encouraged to read it.
5. OpenVPN vs. IPSec vs. L2TP in an Industrial Setting
Not all VPNs are created equal when it comes to gateways embedded on ARM CPUs with reconnection and memory constraints.
Detailed Comparative Analysis
| Criterion | OpenVPN | IPSec (IKEv2) | L2TP / PPTP |
|---|---|---|---|
| Transport | UDP or TCP 443 | UDP 500/4500 (ESP/IKE) | UDP 1701 / TCP 1723 |
| Firewall / NAT traversal | Excellent (TCP 443 gets through everywhere) | Average (NAT-T required) | Variable |
| Reconnection after 4G disconnection | Fast (persist-tun, ~2–5 s) | Excellent (MOBIKE, virtually transparent) | Slow (15–60 s) |
| Cryptographic primitives | TLS, AES-256-GCM | AES-256, SHA-2 (IKEv2) | Weak (PPTP/MS-CHAPv2 not recommended) |
| Authentication | X.509 certificate per client | PSK or X.509 certificates | Username / password |
| CPU load (ARM Cortex-A) | Moderate | Low (hardware acceleration possible) | Low |
| Maturity / Certifications | Extensively audited, widely adopted | FIPS 140-2 certified | Outdated (PPTP should be avoided) |
OpenVPN: Eziwan's Default Choice for Embedded Gateways
The key point for businesses: traversing firewalls and reconnecting after a 4G outage. OpenVPN encapsulates the tunnel within TLS on TCP port 443—the same port used by HTTPS—allowing it to pass through where other protocols are blocked (carrier firewalls, corporate proxies). When combined with persist-tun, the tunnel reestablishes itself within seconds after a Dual SIM switch, without requiring a full renegotiation.
Each technician has their own X.509 certificate, which can be revoked individually from the cloud dashboard—a key requirement for NIS2 traceability.
IPSec (IKEv2) for environments that require it
IPSec remains the standard in enterprise and regulated industrial environments that require FIPS 140-2-certified protocols. Its MOBIKE mechanism handles IP address changes in a virtually transparent manner—making it particularly well-suited for Dual SIM failover. Configuration is more complex (PKI, X.509 certificates, SA policies), but interoperability with existing network equipment is maximized. The Eziwan Gateway also supports L2TP, PPTP, and GRE for legacy interoperability scenarios.
6. How Eziwan Implements Zero Exposed Ports
The Eziwan architecture applies the above principles systematically:
Connection Architecture
- The gateway at the factory initiates the OpenVPN connection to the Eziwan cloud infrastructure over UDP port 1194
- The connection is authenticated using X.509 certificates generated during provisioning
- No incoming ports are open on the factory network
- Operator access goes through the Eziwan cloud, with integrated MFA (TOTP or push notification)
- Each session is logged: user, timestamp, duration, actions performed
Migration Process from TeamViewer
If you are currently using TeamViewer on industrial monitoring workstations, here is a step-by-step migration process:
Phase 1 — Parallel Deployment (Weeks 1–4):
- Install Eziwan gateways at 5 to 10 pilot sites
- Keep TeamViewer active in parallel during the validation phase
- Train teams on how to use the Eziwan VPN client and the dashboard
Phase 2 — Phased Rollout (Weeks 5–8):
- Disable TeamViewer at pilot sites after validation
- Roll out to the remaining sites in waves of 10–20 sites
- Verify that Eziwan audit logs meet the teams’ needs
Phase 3 — Uninstallation and Cleanup (Week 9+):
- Uninstall TeamViewer from all monitoring workstations
- Revoke TeamViewer licenses
- Archive old TeamViewer logs as needed for compliance
Post-Deployment Validation Checklist
After deploying Eziwan, check the following:
- No incoming TCP/UDP ports open on the factory firewall (scan from the Internet)
- MFA enabled for all remote access accounts
- Individual accounts created for each technician (no shared accounts)
- Access rights verified by scope (Technician X can only view their assigned sites)
- SMS/email alert tested to validate the notification channel
- Audit logs tested and exported (for future audit)
- Access revocation procedure documented and tested
Final Comparison Table
| Criterion | TeamViewer / AnyDesk | Traditional VPN (site-to-site) | Eziwan |
|---|---|---|---|
| Inbound ports exposed | No (third-party cloud relay) | Yes | No |
| Session traceability | Partial (subscription) | Depends on the device | Full + export |
| IEC 62443 SL2 compliance | ✗ | Partial | ✓ |
| ANSSI recommendation compliance | ✗ | Partial | ✓ |
| Integrated MFA authentication | Optional | Optional | Integrated |
| On-site network intervention | No | Yes | No |
| Full OT isolation | ✗ | Partial | ✓ |
| Exportable audit logs | Premium subscription | Depends on equipment | Standard |
| Reconnection after 4G disconnection | 30–60 s | 5–30 s | < 2 s (OpenVPN) |
| Deployment without network expertise | Yes | No | Yes (ZTP) |
For practical implementation on a Siemens S7 PLC, see How to Connect to an S7 Remotely Without Opening a Port. For detailed information on IEC 62443 requirements, see IEC 62443 and Industrial Remote Access.
FAQ — Industrial VPN vs. TeamViewer
Isn't TeamViewer sufficient if you're only accessing a monitoring workstation, not the PLC directly?
Not necessarily. The supervisory workstation typically has access to the Level 1 network (PLCs) via SCADA software. A compromise of the workstation—whether via TeamViewer or another vulnerability—indirectly grants access to the PLCs. OT isolation must be considered in terms of the network, not the application.
Is WireGuard a viable alternative to OpenVPN for industrial gateways?
WireGuard offers superior performance and a smaller (better-audited) codebase, but it has one limitation: it runs only over UDP, with no TCP option. In networks where UDP is blocked (such as by certain mobile carriers or corporate proxies), WireGuard may fail where OpenVPN over TCP 443 would work. For industrial 4G gateways with potentially unreliable connections, OpenVPN remains the most versatile choice.
Can we use an existing corporate IPsec VPN solution instead of Eziwan?
Yes, if the existing solution meets the IEC 62443 SL2 criteria (named accounts, MFA, exportable logs, least privilege). A recurring issue with enterprise site-to-site VPNs used in the OT environment is the lack of granularity: the VPN grants access to an entire network segment rather than to a specific device. Eziwan can complement an enterprise VPN solution by adding granularity and audit logs.
Does ANSSI maintain a list of approved remote access solutions for the OT?
ANSSI does not publish a list of "approved" solutions, but rather evaluation criteria. For OIVs and OSEs, PRIS-certified service providers (Security Incident Response Providers) can conduct a formal assessment. The ANSSI criteria are consistent with the IEC 62443 SL2 requirements described in this article.
How long does it take to migrate from TeamViewer to an industrial VPN solution?
For a network of fewer than 20 sites, the migration can be completed in 2 to 4 weeks: parallel deployment, team training, and a phased switchover. The critical step is training technicians on the VPN client—allow 1 to 2 hours per person. The process is detailed in Section 6 of this article.
Does your organization currently use TeamViewer or a traditional VPN connection on an OT network?
Download the OT Cybersecurity White Paper →
The document details the recommended target architecture, the migration process from an existing system, and the criteria for evaluating a solution that complies with IEC 62443.
