Industrial VPNs. Site-to-site, remote access, and why a flat VPN into the control LAN is a bad idea.
"Just throw a VPN at it" is one of the most common — and most dangerous — answers to OT connectivity. This article walks through the legitimate uses of VPNs in industrial systems, the categories of VPN, the segmentation patterns that make them safer, and what to do instead when "site-to-site VPN into the control LAN" is on the table.
The legitimate uses
- Site-to-site for plant-to-plant data exchange. Connecting an operations center to a remote site over the public internet — historian replication, engineering access, fleet-wide dashboards.
- Remote engineering and vendor support. Maintenance vendors logging in to troubleshoot a PLC or update firmware.
- Cloud-edge sync. A cloud analytics workload (like Aevus) reading telemetry from an on-prem historian.
- Mobile / road-warrior engineering. A site engineer using a laptop from home or hotel.
All of these are legitimate. None of them justify a flat VPN that lands directly in the control LAN.
Why "flat VPN into the control LAN" is the wrong pattern
A flat VPN gives the remote user — or attacker who has compromised the remote user — unrestricted layer-3 access to whatever's reachable on the control LAN. Once inside:
- Every PLC, RTU, and HMI is directly addressable. Modbus, OPC, DNP3 traffic flows freely.
- The compromised credential has the same privileges as the operator whose credential it is.
- Lateral movement is bounded only by what the attacker can discover — and the asset inventory in most OT environments is incomplete by definition.
- Audit trail is minimal: a VPN log says "user X connected at time Y for duration Z." What they did inside is not captured.
This is exactly the architecture that's produced most published OT incidents involving remote access — Oldsmar water plant, Colonial Pipeline, multiple Trisis-related incidents. Not because the VPN technology failed, but because the trust model the VPN implies ("you're inside, so you're trusted") is wrong.
The right patterns
1. Brokered remote access (the strongest pattern)
Replace VPN-into-OT with a session-brokered jump host. The user authenticates (MFA required), the broker validates entitlement, the broker establishes the OT connection on the user's behalf, the broker records the session. Tools: BeyondTrust, CyberArk, Cisco Secure Equipment Access, Claroty SRA. The OT network never sees the user's IP.
2. Site-to-site VPN terminated in a DMZ
When site-to-site is genuinely needed, the VPN tunnel terminates in an industrial DMZ — not in the control LAN itself. Specific traffic types (replicate historian, retrieve file) are allowed from the DMZ inward via narrow firewall rules. The DMZ is the enforcement boundary.
3. Zero-trust replacement for VPN entirely
Modern: replace the VPN concept with zero-trust network access (ZTNA). Cloud-brokered identity verification, per-application access, no concept of "inside the network." Tools: Zscaler Private Access, Cloudflare Zero Trust, Tailscale, Twingate. Increasingly common for enterprise IT; slowly making its way into OT.
What "VPN" actually means in 2026
The word "VPN" covers very different technologies. Worth being explicit:
| Term | What it actually is | OT-appropriate use |
|---|---|---|
| IPSec site-to-site | Encrypted tunnel between two routers | Plant-to-plant, DMZ termination only |
| OpenVPN / WireGuard | User-mode VPN for client devices | Engineering laptops, DMZ termination |
| SSL/TLS VPN | Web-portal-based remote access | Largely superseded by ZTNA |
| SD-WAN | Software-defined WAN with encryption built in | Branch-site connectivity |
| ZTNA | Identity-aware per-application access | The replacement for VPN going forward |
| "Free VPN" | Consumer privacy product | Never. Never use for industrial. |
How Aevus connects (without using a flat VPN)
Aevus's connection pattern to customer sites is outbound-only from the customer site to Aevus's cloud. The customer's edge collector establishes a TLS session out to Aevus's ingress endpoint. No inbound VPN. No flat tunnel. The session carries telemetry one-way. The Aevus cloud has no reverse-path to write to the customer's field equipment — enforced architecturally by IL-9000.
VPNs are a tool, not a default.
If your team is replacing flat VPNs with broker-based remote access, or evaluating a cloud platform that connects to OT without one, Aevus is the model.
Related Articles
The OT security controls that actually move the needle.
NIST 800-207 principles applied inside the OT boundary.
MRP, DLR, PRP, HSR — failover times and where each fits.
Ready to see how this applies to your operation? Start a pilot conversation — no commitment, no field changes.