Modbus, SCADA and PLCs: remote maintenance without exposure

The real need: intervening without traveling

Remote maintenance is not a comfort: it is what separates a twenty-minute production stop from a two-day one. Diagnosing a fault, reading registers, loading a program fix, checking a recipe — most interventions do not justify a trip, provided the machine can be reached remotely. Three situations come up constantly.

In all three cases, the question is not “how to get access” — solutions have existed for twenty years — but “how to get access without creating a permanent entry door onto equipment that cannot defend itself”.

Modbus and the protocols born without security

Modbus dates from an era when the automation network was a serial cable between two cabinets. Its Modbus TCP variant, which by convention listens on port 502, inherited the model: no authentication, no encryption, no integrity check. Any machine able to establish a TCP connection to the PLC can read the inputs, write the outputs and modify the registers. This is not an implementation flaw: it is the protocol, as designed — for a network assumed to be closed.

Modbus is not an isolated case. A large share of the automation protocols still in production rests on the same assumption of a trusted network: the peer’s identity is not verified, and exchanges travel in cleartext. The security of this equipment does not come from the protocol: it comes — entirely — from who can reach the network where it lives.

And exposed equipment does not stay discreet. Public scan engines continuously sweep the Internet address space and index the services that answer, industrial ports included. A PLC reachable from the Internet is not “hidden because nobody knows the address”: it is findable by anyone, with no particular effort, and it will answer whoever speaks its protocol.

Why the common practices are frightening

Faced with the need, the field improvised. Three practices dominate, each born from a real constraint — and each with a security or operations cost you always end up paying.

What these three practices share: the access is too broad (a whole network, a whole desktop) or too exposed (an open port onto the bare protocol), and it rests on site-side configuration that someone must create, document and remember to remove. At the scale of an installed base, that is as many entry doors as customers.

The approach: a gateway joins the mesh, the PLC stays home

The VIGIL-MESH model fits in one sentence: it is not the PLC that joins the private network, it is a site gateway — an industrial PC, an NVIDIA Jetson, a Linux box — placed between the machine network and the world. The gateway installs the VIGIL client and joins the mesh; the PLC does not move: it stays on its machine network, agentless, unmodified, invisible from the Internet.

• Zero inbound ports on the site side — the gateway only makes outbound connections: a single flow on 443 UDP, the same port as the modern web. Nothing to open on the customer’s firewall, nothing to forward, nothing to justify.
• Immediate connection, direct as soon as possible — traffic first goes through a relay, then migrates without interruption to the direct path once NAT traversal succeeds. The session survives network changes — useful for a site on 4G/5G.
• A stable address and a name — the gateway keeps the same address on the mesh wherever it is, plus a readable MagicDNS name. Supervision points to a name that never changes, not to a site’s public IP.
• One node, the whole workshop — a single connected node makes the equipment of the machine network it serves reachable inside the private network, under ACL control.

Strict ACLs: least privilege, machine by machine, service by service

Joining the mesh grants no rights. VIGIL-MESH ACLs are deny by default: any flow not explicitly authorized is refused. Rules are ordered — the first match decides — and designate their subjects by identity (machine, group, tag), never by IP address. For remote maintenance, this lets you write exactly the access you need: a given team reaches a given gateway, on a given service, and nothing else.

Every policy change produces a new generation signed by the controller, which the client verifies against the controller’s public key before applying it, even offline. Sensitive actions require strong authentication (MFA), and the audit log is hash-chained: a remote maintenance intervention leaves a verifiable trace — who had access to what, under which policy generation.

Modbus inside an end-to-end TLS 1.3 tunnel

The mesh asks nothing of the protocols it transports — and that is exactly what saves the bare ones. Between the technician’s workstation and the site gateway, each session is an end-to-end encrypted QUIC/TLS 1.3 connection, built on Ed25519 keys with a hybrid post-quantum X25519 + ML-KEM key establishment. The Modbus flow travels inside this tunnel: on the remote leg, it is never in cleartext.

• The relay is structurally blind — when traffic goes through a relay, it does not hold the keys and never sees the content. Relayed or direct, the path changes nothing about the encryption.
• A private relay is possible — if transiting a shared relay bothers you, you can host your own, dedicated to your workspace.
• Everything IP benefits — Modbus TCP, OPC UA, MQTT, a machine’s web HMI or VNC/RDP access to the supervision workstation travel in the same tunnel, each subject to its ACL rule.

OEMs and integrators: one workspace, per-site networks, autonomous islands

For a machine builder or an integrator following an installed base, structure matters as much as the tunnel. One workspace holds the whole base; inside it, each site or customer has its own network. ACLs partition it: machines of site A have no reason to see those of site B, and do not see them. The field-service team, meanwhile, receives rights by group — added and removed without rewriting the policy site by site.

• One network per site — each site is its own domain, with its machines, its MagicDNS names and its rules. Growing the base does not add tunnel complexity: it adds inventory lines.
• Autonomous islands — if a site’s Internet link goes down, the already-verified members present on site keep talking to each other. Local supervision survives the outage; only remote visibility waits for the link to return.
• Controlled publishing — a dashboard or historian on the mesh can be exposed cleanly through publications, without making the rest of the OT visible.
• Per-intervention audit — joins, revocations and policy changes are traced: you can answer a customer who asks who accessed their machine, and when.

On the workstation side, remote maintenance works from Windows or Linux at the office, from Android on the road, and even in the browser through the console’s WASM node — no VPN to install on the hotel machine.

The limits, stated plainly

VIGIL-MESH solves the remote access problem — who can reach what, encrypted, with no exposure. It does not claim to solve all of OT security, and it is better said upfront than discovered later.

• It is not an industrial firewall — the mesh transports authorized flows without inspecting the frames: it does not filter Modbus function codes, and does not block an illegitimate register write coming from an authorized workstation. Defense in depth on the machine network remains necessary.
• It is not turnkey compliance — the hash-chained audit and signed generations are useful building blocks for a compliance program, not the program itself. Risk analysis and organization remain to be done.
• Non-IP protocols fall outside the scope — PROFINET DCP, native EtherCAT and other non-IP layer 2 frames do not cross the core of the mesh, which is an L3 overlay. Where needed, they belong to an optional site L2 bridge on a gateway node.
• The direct path is not guaranteed — two symmetric NATs facing each other (site on 4G, technician on 4G) impose a permanent relay. The connection works, encrypted end to end, simply over a longer path.

Setting up remote maintenance

1. 1
   Create an account and a workspaceThe workspace will hold your networks — for example one network per site or per customer. Free for personal use.
2. 2
   Install the client on the machines involvedThe site gateway (industrial PC, Jetson, Linux box) on one side; the technicians’ workstations (Windows, Linux, Android) on the other.
3. 3
   Enroll each machineNetworks page → Machines → “Add a machine”, with a single-use key per machine.
4. 4
   VerifyEach machine gets its stable address and its MagicDNS name; a ping to the gateway confirms the path.
5. 5
   Reach the service as if localPoint the supervision or configuration tool at the gateway’s address or name, exactly as if you were on site.

Frequently asked questions