TeamViewer Alternative for PLC Remote Access: Why OT Teams Are Switching
Your automation integrator is asking for remote access to commission a PLC. You could give them TeamViewer credentials. But should you?
In the last 18 months, we've seen a decisive shift in how industrial teams approach remote access. The old model — install TeamViewer or AnyDesk on an HMI, share credentials, hope for the best — is colliding head-first with modern OT security requirements. From IEC 62443 to NIS2 compliance, regulators and auditors are increasingly rejecting "third-party remote desktop software" on critical infrastructure networks.
The problem isn't that TeamViewer is insecure — it's that TeamViewer was designed for IT support, not OT networks. Let's unpack why a WireGuard-based secure remote access mesh is fundamentally different, and why teams managing PLC networks from Siemens, Rockwell, Mitsubishi, Omron, and Schneider are switching to outbound-only, network-level access.
The Hidden Risks of TeamViewer on OT Networks
When you install TeamViewer on an HMI or engineering workstation in your OT network, you're not just adding a remote access tool. You're introducing three structural risks that violate modern OT security baselines:
1. Always-On Graphical Backdoor
TeamViewer runs as a persistent service with a background daemon. Once installed, it's reachable 24/7 from the internet — even when your engineer is offline. If the TeamViewer account is compromised ( reused passwords, phishing, credential stuffing on the TeamViewer web portal), attackers gain direct graphical access to your OT network. No VPN, no jump host, no logging — straight to a Windows desktop with TIA Portal, GX Works, or Unity Pro installed.
2. Third-Party Relay Dependency
All TeamViewer traffic routes through TeamViewer AG's infrastructure. Your PLC programming traffic — including proprietary protocol handshakes, project files, and diagnostic data — traverses servers you don't control. From a compliance perspective, you're outsourcing custody of your OT network's remote access logs to a German SaaS company. For aerospace, defense, or critical infrastructure, this is often an automatic fail in security audits.
3. Inbound Exposure + NAT Traversal
TeamViewer uses aggressive NAT traversal: UPnP, hole punching, relays, fallback mechanisms designed to "just work." That's great for IT support. It's terrible for OT security, where no inbound ports is a non-negotiable baseline. TeamViewer's architecture assumes connectivity is worth almost any cost — opening ports, routing through relays, whatever it takes. In OT, connectivity is secondary to containment.
Real-world incident: In 2024, a manufacturing company's OT network was accessed via a compromised TeamViewer account reused by a former integrator. The attackers spent 8 months mapping ICS assets before ransomware deployment. Root cause: no outbound-only constraint, no least-privilege network segmentation, and no audit trail of remote access sessions.
What Engineers Actually Need: Reach the PLC, Not the Desktop
Here's the crucial insight: your integrator doesn't need remote desktop access to your HMI. They need network-level access to your PLC.
When an engineer says "I need TeamViewer to reach the PLC," what they actually mean is: "I need my programming software (TIA Portal, GX Works, SoMachine, Studio 5000) to reach the PLC's IP address."
That's it. They don't need to see your HMI screens. They don't need to browse your file shares. They need network reachability to the PLC subnet.
A WireGuard-based remote access mesh provides exactly that — and nothing more. Instead of a graphical backdoor into a Windows desktop, you provision a scoped route: engineer's laptop can reach PLC subnet 192.168.1.0/24 via a WireGuard tunnel. No RDP, no VNC, no file system access. Just Layer 3 reachability to the devices that actually need remote access.
How a WireGuard Mesh Is Fundamentally Different
Voltrus Remote uses a self-hosted WireGuard mesh with a Headscale control plane. Here's how it differs from TeamViewer architecturally:
Outbound-Only Connectivity
Your OT gateway device (a small Linux box on your PLC network) initiates outbound connections to your Voltrus Remote control plane. No firewall ports need to be opened inbound. The gateway connects to Headscale over WireGuard, registers its public key, and establishes routes to advertised subnets. Engineers then receive routes to those subnets via the same mesh.
This is the opposite of TeamViewer's model. TeamViewer assumes your device should be reachable from anywhere, anytime. Voltrus Remote assumes your OT network should initiate outbound only, on your terms, to infrastructure you control.
Default-Deny, Least-Privilege ACLs
Every engineer in Voltrus Remote gets an ACL defining exactly which PLC subnets they can access. An engineer working on Site A's Siemens PLCs gets routes to 192.168.1.0/24 only. They have no reachability to Site B's Rockwell PLCs at 10.0.2.0/24 unless explicitly granted.
TeamViewer has no network-level ACL concept. If you have credentials to a machine, you have full desktop access to everything on that machine's network (subject to Windows permissions, which are often lax in OT environments).
Self-Hosted Control Plane
The Headscale instance managing your WireGuard mesh runs on your infrastructure — your VPS, your cloud account, your audit logs. You own the user registry, you own the access logs, you own the machine identities. TeamViewer, by contrast, is a managed SaaS where audit trails are subject to their data retention policies and transparency.
DERP Relay Over TCP/443 for Restrictive NAT
Some OT networks sit behind upstream firewalls that block UDP (common in "internet break-out" scenarios). Voltrus Remote falls back to DERP relay over TCP/443 — masquerading as HTTPS traffic. TeamViewer has relays too, but DERP is integrated into the WireGuard control plane (Headscale) that you host, not a third-party you trust.
Cryptographic Hygiene
Voltrus Remote doesn't reimplement WireGuard crypto. The agent drives the official Tailscale client (an open-source WireGuard implementation) at your Headscale control plane. The gateway's WireGuard private key never leaves the device; Headscale stores only the public key for routing. TeamViewer, by comparison, uses its own proprietary crypto protocol with opaque key management.
Comparison: TeamViewer vs Voltrus Remote
| Aspect | TeamViewer | Voltrus Remote |
|---|---|---|
| Access Type | Graphical remote desktop (RDP/VNC-style) | Network route to PLC subnet (Layer 3) |
| Connectivity Direction | Bi-directional (inbound exposure via NAT traversal) | Outbound-only (gateway initiates to control plane) |
| Firewall Requirements | UPnP, port forwarding, or aggressive NAT traversal | None (outbound to control plane over TCP/443) |
| Network Segmentation | No built-in ACLs (depends on Windows permissions) | Per-engineer ACLs limiting reach to advertised subnets |
| Control Plane | TeamViewer AG SaaS (third-party custody) | Self-hosted Headscale (your infrastructure) |
| Regulatory Compliance | Questionable for OT/critical infrastructure | Aligned with IEC 62443, NIST 800-82, NIS2 |
| Crypto Implementation | Proprietary protocol (opaque, vendor-controlled) | WireGuard via Tailscale client (audited, open-source) |
| Audit Trail | Limited to TeamViewer account activity | Full access logs on your self-hosted control plane |
| Lateral Movement Risk | High (desktop access to all applications) | Low (network access to scoped subnets only) |
The Native Toolchain Works Better Over WireGuard
Here's a practical benefit integrators love: TIA Portal, GX Works, SoMachine, and Studio 5000 work natively over a WireGuard route. The PLC is just at its local IP address — 192.168.1.10, same as on-site. No screen-share lag, no RDP compression artifacts, no "remote desktop feels sluggish" complaints.
Compare this to TeamViewer: the engineer remotes into your HMI, opens TIA Portal, and experiences the full latency of a remote desktop session. WireGuard eliminates that layer entirely. The PLC is directly reachable from the engineer's laptop, as if they were plugged into your switch.
When TeamViewer Might Still Make Sense (And When It Doesn't)
TeamViewer is excellent for IT support: helping Grandma fix her printer, troubleshooting a remote office PC, quick one-off desktop access. It's the wrong tool for ongoing PLC remote access because:
- OT networks require outbound-only — TeamViewer's NAT traversal fights this
- Least-privilege network segmentation — TeamViewer has no ACL concept
- Auditability — Self-hosted control planes beat SaaS custody
- Regulatory alignment — IEC 62443 expects scoped network access, not graphical backdoors
Migration Path: From TeamViewer to WireGuard Mesh
If you're currently using TeamViewer for PLC access, here's how to migrate without disrupting operations:
- Deploy a Linux gateway on your PLC network (small industrial PC or Raspberry Pi with ethernet)
- Install the Voltrus Remote agent — it registers with your Headscale control plane
- Advertise PLC subnets — e.g., 192.168.1.0/24 for Siemens PLCs
- Create ACLs for engineers — per-site, per-subnet, time-boxed if needed
- Engineers install Voltrus Remote client — receives routes to authorized subnets
- Test with TIA Portal/GX Works — PLC appears at local IP, no RDP layer
- Decommission TeamViewer — remove from HMIs, revoke credentials
Secure PLC Remote Access Without Inbound Ports
Voltrus Remote gives your engineers network-level access to PLCs via an outbound-only WireGuard mesh — no inbound firewall ports, no third-party relays, no desktop backdoors.
Explore Voltrus Remote →The Bottom Line
TeamViewer solved the wrong problem for OT networks. It gave you anytime, anywhere desktop access — when what you actually needed was scoped, outbound-only network access to PLCs.
Voltrus Remote flips the model: your OT network initiates outbound connections to your self-hosted control plane, engineers receive scoped routes to PLC subnets, and you retain full custody of access logs and crypto keys. No inbound ports. No graphical backdoors. No third-party relay dependency.
For integrators, it means faster commissioning: no RDP lag, direct native tooling reach to PLCs, and predictable performance. For OT security, it means compliance with IEC 62443, NIS2, and internal baselines that require least-privilege network segmentation.
The shift isn't subtle — it's architectural. And for teams managing Siemens S7-300/400/1200/1500, Rockwell ControlLogix, Mitsubishi MELSEC, Omron NJ/NX, or Schneider Modicon M340/M580, the difference is the difference between "remote access" and "secure remote access."