Secure Remote Access to PLC Networks: A Practical Guide for Integrators

Your PLC network is air-gapped. The automation integrator needs remote access for commissioning. The OT security team demands zero inbound ports. How do you bridge this gap without violating your security baseline?

This guide walks through a practical architecture for secure PLC remote access: an outbound-only WireGuard mesh with a self-hosted control plane, scoped ACLs, and compliance alignment for IEC 62443 and NIS2. We'll cover the threat model, network architecture, deployment checklist, and ACL design — with a data-flow diagram showing how connectivity flows from engineer to PLC without opening inbound firewall ports.

Threat Model: What Are We Protecting Against?

Before designing the solution, let's articulate what we're defending. In an OT context, the primary threats from remote access are:

1. Unauthorized PLC Exposure

If a PLC's TCP/102 (S7), TCP/502 (Modbus TCP), or Ethernet/IP port is reachable from the internet, anyone can attempt to connect. That might be a port scanner, a vulnerability scanner, or a targeted attack. The risk isn't just unauthorized control — it's reconnaissance, firmware extraction, and protocol-level exploitation.

2. Standing Access and Credential Theft

Traditional VPNs often have long-lived credentials. If an engineer's laptop is stolen, infected with malware, or their credentials are phished, attackers gain standing access to your OT network. The longer credentials remain valid, the larger the exposure window.

3. Lateral Movement Beyond PLC Subnets

Remote access should be scoped to only the PLC subnets an engineer needs. If they can reach your historian server, HMI stations, or file shares, you've created a lateral movement path. Principle of least privilege applies at the network level, not just the application level.

4. Lack of Audit Trail

When an engineer accesses your PLC network, can you answer: who accessed what, when, from which IP, and for how long? If your answer is "our VPN logs show something," that's insufficient. You need explicit, queryable records of remote access sessions with user identity and target subnets.

Architecture: Outbound-Only WireGuard Mesh

Voltrus Remote addresses these threats with a fundamentally different connectivity model:

┌─────────────────┐         ┌──────────────────┐         ┌─────────────────┐
│ Engineer Laptop │◄────────┤ Headscale Control│────────►│ OT Gateway      │
│ (TIA Portal)    │  WireGuard  Plane (Self-    │  DERP   │ (Linux Box)     │
│ 10.0.0.5        │  Mesh     Hosted)           │ Relay  │ 192.168.1.10    │
└────────▲────────┘         └──────────────────┘         └───────┬─────────┘
         │                                                        │
         │ Routes: 192.168.1.0/24 advertised by gateway           │
         │                                                        │
         └────────────────────────────────────────────────────────┘
                          │
                          ▼
                  ┌───────────────┐
                  │ Siemens PLC   │
                  │ 192.168.1.20  │
                  │ TCP/102       │
                  └───────────────┘

Key Points:
• Engineer initiates outbound to Headscale (no inbound ports)
• Gateway initiates outbound to Headscale (no inbound ports)
• DERP relay over TCP/443 for restrictive NAT
• Engineer receives scoped routes to advertised subnets only
• PLC appears at local IP in TIA Portal — no RDP layer
			

This architecture has three critical properties:

1. Outbound-only: Both the engineer's laptop and the OT gateway initiate outbound connections to your Headscale control plane. No firewall ports need to be opened inbound. The control plane can be hosted in your cloud account or on-premise.
2. Scoped routes: The gateway advertises only the PLC subnets you want accessible (e.g., 192.168.1.0/24). Engineers receive routes only to subnets their ACL permits. No lateral movement to unrelated networks.
3. Self-hosted custody: The Headscale control plane runs on infrastructure you control. You own the user registry, access logs, and machine identities. No third-party custody of your OT access records.

Deployment Checklist: Step-by-Step

Step 1: Deploy the Headscale Control Plane

Provision a small VPS (1 CPU, 512MB RAM is sufficient) or use an existing server. Install Headscale:

# Headscale control plane (Ubuntu/Debian)
curl -fsSL https://headscale.de/keys/headscale.repo | sudo tee /etc/apt/sources.list.d/headscale.list
sudo apt update && sudo apt install headscale

# Configure /etc/headscale/config.yaml
# Set your DERPs, ACL policy, database backend
sudo systemctl enable headscale
sudo systemctl start headscale

This control plane will manage WireGuard peer registration, route advertisement, and ACL enforcement. For production, run it behind a reverse proxy (nginx/Caddy) with TLS.

Step 2: Deploy the OT Gateway Device

On your PLC network, deploy a small Linux device with two network interfaces:

• WAN port: Connects to your upstream network (has internet breakout)
• LAN port: Connects to your PLC switch (192.168.1.0/24)

This can be a Raspberry Pi 4, an industrial mini-PC, or a hardened appliance. Install the Voltrus Remote agent:

# On the gateway device
curl -fsSL https://get.voltrus.id/gateway | sudo bash

# Register with your Headscale control plane
voltrus-remote register --control-plane=https://headscale.your-domain.com

# Advertise PLC subnets
voltrus-remote advertise 192.168.1.0/24

The gateway will initiate an outbound WireGuard connection to your Headscale control plane and advertise the 192.168.1.0/24 subnet. No firewall configuration is required.

Step 3: Define ACLs for Engineers

In Headscale's ACL policy, define per-engineer subnet access:

# headscale/acls.yaml
acls:
  - action: accept
    users: ["engineer-john@example.com"]
    routes: ["192.168.1.0/24"]

  - action: accept
    users: ["engineer-sarah@example.com"]
    routes: ["10.0.10.0/24"]  # Different site

  - action: accept
    users: ["admin@example.com"]
    routes: ["0.0.0.0/0"]  # Full access (use sparingly)

Reload ACLs without restarting the control plane:

headscale acl reload

Step 4: Engineer Installs Client

The engineer installs the Voltrus Remote client on their laptop:

# On engineer's laptop (Windows/macOS/Linux)
# Download from https://voltrus.id/voltrus-remote/downloads/

# Login to your control plane
voltrus-remote login --control-plane=https://headscale.your-domain.com

# Auth via browser (OAuth) or API key
# Client registers as WireGuard peer, receives scoped routes

After login, the engineer's laptop receives routes to the subnets their ACL permits. They can now ping the PLC at its local IP:

# From engineer's laptop
ping 192.168.1.20

# Works! PLC is reachable via WireGuard mesh

Step 5: Verify Native Tool Reachability

Open TIA Portal, GX Works, or Studio 5000. Add the PLC at its local IP address (192.168.1.20). Connect. It should work identically to on-site access, with no RDP layer and no screen-share lag.

Step 6 (Optional): Time-Boxed Grants

For temporary access (e.g., 1-week commissioning window), create time-boxed ACLs:

# headscale/timeboxed-acls.yaml
acls:
  - action: accept
    users: ["contractor@example.com"]
    routes: ["192.168.1.0/24"]
    start: "2026-07-13T00:00:00Z"
    end: "2026-07-20T23:59:59Z"

After the expiry timestamp, the contractor's routes are automatically withdrawn.

ACL Design: Least Privilege in Practice

Effective ACL design follows these principles:

Per-Project Scoping

# Site A PLCs
acls:
  - action: accept
    users: ["engineer-a@example.com"]
    routes: ["192.168.1.0/24"]

# Site B PLCs (different engineer)
acls:
  - action: accept
    users: ["engineer-b@example.com"]
    routes: ["10.0.20.0/24"]

Per-Protocol Segmentation

If you have multiple PLC protocols on different subnets, segment them:

# Modbus TCP PLCs only
acls:
  - action: accept
    users: ["modbus-specialist@example.com"]
    routes: ["192.168.10.0/24"]

# Ethernet/IP PLCs only
acls:
  - action: accept
    users: ["ethernetip-specialist@example.com"]
    routes: ["192.168.20.0/24"]

Read-Only Subnets (Future)

For monitoring-only access, advertise read-only subnets via a separate gateway with firewall rules blocking write protocols. This is roadmap for Voltrus Remote.

DERP Relay: Working Around Restrictive NAT

Some upstream firewalls block UDP entirely. Voltrus Remote falls back to DERP relay over TCP/443:

Normal WireGuard: Engineer ←UDP→ Headscale ←UDP→ Gateway

UDP Blocked:     Engineer ←TCP/443→ DERP Relay ←TCP/443→ Gateway
                 (masquerades as HTTPS)
			

DERP is integrated into Headscale and routes traffic over HTTPS-compatible TCP. No special firewall rules are needed — it just looks like web browsing to your upstream firewall.

Compliance Alignment: IEC 62443 and NIS2

This architecture aligns with key OT security standards:

IEC 62443-3-3 (System Security Requirements)

• SR 3.1: Controlled access to system assets — ACLs enforce subnet-level access control
• SR 3.2: Use of authenticatable information — Headscale enforces user identity before granting routes
• SR 3.4: Prevention of unauthorized data flow — outbound-only prevents unsolicited inbound connections

NIS2 (EU Cybersecurity Directive)

• Article 21: Security of supply chains — self-hosted control plane avoids third-party dependency
• Article 23: Cryptography — WireGuard uses audited, modern crypto (ChaCha20-Poly1305)
• Incident response: Access logs on self-hosted infrastructure support audit requirements

Operational Considerations

What Happens When the Gateway Loses Internet?

If the OT gateway loses connectivity (e.g., upstream router restart), the WireGuard tunnel drops. Engineers lose access to PLC subnets until the gateway reconnects. This is a feature, not a bug — it ensures access requires active connectivity, not standing VPN credentials.

How to Handle Emergency Access?

For emergency access (e.g., after-hours breakdown), create a separate ACL with broader routes and shorter expiry. This balances response time with least privilege. Voltrus Remote roadmap includes session recording and emergency approval workflows.

Multi-Tenant Scenarios

If you're an integrator managing multiple customers, deploy separate Headscale instances per customer. Avoid multi-tenancy on a single control plane — it complicates audit boundaries. Voltrus Remote roadmap includes billing and multi-tenant management.

The Bottom Line

Secure remote access to PLC networks doesn't require opening inbound firewall ports or trusting third-party SaaS with your OT connectivity. By flipping the model to outbound-only, scoped routes over a self-hosted WireGuard mesh, you get:

• Security: No inbound exposure, least-privilege ACLs, audit-ready logs
• Compliance: Aligned with IEC 62443, NIS2, and corporate OT baselines
• Usability: Native tool reach without RDP latency, TIA Portal works as if on-site
• Custody: You own the control plane, logs, and crypto keys

For integrators, this means faster commissioning: no travel for simple changes, direct PLC reach, and predictable performance. For OT security teams, it means enforceable least privilege and no standing VPN credentials.

The architecture isn't theoretical — it's deployed today across manufacturing, utilities, and process industries. The shift from "remote desktop into OT network" to "scoped network routes to PLCs" is a fundamental security improvement.