Documentation

An Ewon Cosy alternative: industrial remote maintenance without a dedicated box

Fixing a machine installed at a customer site, without travelling and without asking anything of the site firewall: that is the need that made remote-maintenance routers like the Ewon Cosy successful. VIGIL-MESH answers the same need with a software agent instead of a box: a Windows or Linux machine on the machine network — the industrial PC that is, more often than not, already in the cabinet — joins an end-to-end encrypted private network with no inbound port, and your technicians reach the PLC, the HMI and the supervision as if they were on site. This page compares the two models honestly, then walks through the migration from an integrator's point of view.

What the Ewon Cosy does very well

The Ewon Cosy, from HMS Networks, has become a de facto standard among machine integrators and builders. The model is crystal clear: a remote-maintenance router in the electrical cabinet establishes an outbound VPN tunnel to the vendor's cloud (Talk2M); the technician connects from their side, and the cloud brings the two ends together. The customer's firewall has nothing to open, the electrician knows how to wire the box, and the service team reaches the machine on commissioning day.

A box designed for the cabinet

DIN rail, industrial power supply, a clean separation between the machine network and the factory network: the Cosy is as much an electrician's product as an IT product, and it fits into the electrical drawing like any other component.

Nothing to ask of the customer's IT

The tunnel leaves outbound towards the vendor's cloud: no inbound port, no port forwarding, no meeting with the site's IT department. That is the argument that converted an entire profession.

A mature ecosystem

Extensive documentation, resellers, established habits in engineering offices: the box + cloud + licences model has been proven for years, and that maturity has real value.

A machine without an OS and no PC on the machine network. The VIGIL-MESH agent is software: it needs an operating system to run. If the machine network contains only a bare PLC and nothing allows adding a Linux or Windows machine to it, the dedicated box remains the natural solution.
The need for an integrated 4G router. On a site with no wired internet access, a box that also acts as a cellular router provides two services in one. VIGIL-MESH does not provide connectivity: it travels over it.
A customer policy that mandates hardware. Some clients require a physical remote-maintenance device, identified on the electrical drawing and physically unpluggable. That is a legitimate policy, and software does not answer it.

The box + cloud model, and what it implies at fleet scale

Nothing below is a hidden flaw: it is the stated way a remote-maintenance router backed by its vendor's cloud works, and it serves its use case very well. But when the fleet grows from five machines to fifty, the consequences of the model become cost and management items in their own right.

One box per machine or per site. Every cabinet gets its hardware: to buy, stock, wire, provision, and replace on failure. The logistics grow linearly with the fleet — including for machines whose cabinet already contains an industrial PC.
Access is a tunnel to one box at a time. The technician opens a session to one machine, then closes it and opens another. The fleet is not a network you walk through: it is a list of tunnels you work down.
The path goes through the vendor’s cloud. Tunnels are established towards its infrastructure, which brings the two ends together. Access to your machines therefore depends on the availability and rules of an external service — for that service’s exact guarantees, the vendor’s documentation is the authority.
Licences and accounts managed at the vendor. Who reaches what lives in the vendor’s portal, according to its commercial model. That is coherent — but it is not a rule of your network.

The VIGIL-MESH approach: the gateway is software

VIGIL-MESH replaces the box with a software agent — available for Windows, Linux, Android and NVIDIA Jetson, plus a browser node (WASM) to intervene with nothing installed. Installed on a machine of the machine network — the HMI’s industrial PC, a Linux box, a Jetson —, the agent turns that machine into a site gateway: it joins your private network through a single outbound connection and relays the authorized flows to the PLC, which does not change by one byte. The details of this setup are described in Remote access to a PLC.

A real LAN, not a pile of tunnels

All site gateways and technician workstations are members of one private network: every machine has a stable address and a MagicDNS name, and discovery and multicast work between members. The fleet is walked through like a local network.

End-to-end encrypted, blind relays

Sessions are end-to-end encrypted QUIC/TLS 1.3 connections with a hybrid post-quantum key exchange. When a relay is needed, the vigie carries opaque packets without holding the keys — and you can host your own private vigie.

Identity ACLs, audit, MFA

Deny by default: this service group reaches this gateway on these ports, and nothing else. Every access is logged, accounts are protected with MFA, and revoking a technician or a machine is immediate.

SSH terminal in the browser

From the console, an SSH terminal opens on the gateway right in the page: the browser becomes a mesh node, and your credentials never transit our servers.

Console inventory: the enrolled gateway is active, with its stable overlay address and its actions menu. — Once enrolled, the site gateway appears in the network inventory, online, with its stable address.

Qualitative comparison

Criterion	Ewon Cosy + Talk2M	VIGIL-MESH
Hardware required	A dedicated box per machine or per site, to buy and maintain	No box: a software agent on a Windows/Linux machine of the machine network (industrial PC, Jetson, Linux box) — often already present
Network model	On-demand tunnel to one box at a time, through the vendor's cloud	A permanent, real mesh LAN: gateways and workstations are members of the same private network, reachable by name
Multicast / discovery	Routed tunnel: automatic multicast discovery generally does not cross it	Real-LAN multicast and discovery between mesh members (mDNS, discovery protocols)
Serial port	Depends on the box's interfaces and the chosen model	Virtual-IO remote serial — in beta
Real-time UDP / video	Traffic carried inside the VPN tunnel, path depending on the vendor's infrastructure	End-to-end UDP, direct peer-to-peer path as soon as NAT traversal succeeds, seamless migration
Browser SSH terminal	Depends on the vendor portal's services	Yes: SSH client running in the page, credentials never sent to our servers
Cloud trust model	Tunnels are established towards the vendor's infrastructure, which brings the ends together — its documentation is the authority on exact guarantees	Structurally blind relays: E2E QUIC/TLS 1.3 + hybrid post-quantum sessions, the relay never holds the keys
Self-hosting the relay	The service relies on the vendor's cloud	Yes: self-hostable private vigie — the relayed path goes through a machine of yours

Migrating: the integrator scenario

The typical case: an integrator or machine builder that equips its machines at customer sites and provides remote maintenance — the full picture is in Industrial remote maintenance.

Your workshop standard is a Cosy in every cabinet. The model served you well — but the fleet has grown, and what used to be a reflex has become a management item:

Dozens of boxes to buy, provision, keep as spares and replace, one per delivered machine — including on machines whose cabinet already holds an industrial PC driving the HMI.
Accounts and licences to track in the vendor's portal, per technician and per customer, with rights that live outside your network.
Customer IT departments asking who terminates the tunnel, where the data transits, and why a third-party device permanently reaches an external cloud.
Machine-by-machine access: to compare two lines or supervise a fleet, you stack tunnels instead of walking through a network.

The starting point of the migration fits in one sentence: in most cabinets, the machine that can replace the box is already there.

1
Identify each machine's gatewayThe HMI's industrial PC, a Linux box, a Jetson: any Windows or Linux machine that sees the machine network can become the gateway. If there is none, add one — or keep the box on that machine: both coexist.
2
Create the workspace and one network per customerOne VIGIL-MESH network per end customer keeps fleets sealed from each other: your technicians see everything their rights allow, each customer only sees their machines.
3
Enroll the gatewayConsole → Networks → Machines → “Add a machine”: the assistant hands you a one-time enrollment key. The gateway generates its identity locally and opens no inbound port — a single outbound flow on 443 UDP.
4
Declare the equipment and write the ACLsMachine-network equipment is declared host by host (the PLC, the HMI). ACLs apply deny by default: the service group reaches the customer's gateway on the useful ports — and nothing else.
5
Verify in real conditionsThe gateway appears in the inventory with its stable address; the engineering tool reaches the PLC by its address through the gateway; the browser SSH terminal opens a session on the gateway from any workstation.
6
Switch over machine by machineThe Cosy stays in place until the gateway has proven itself. Once the machine is validated, the box is removed — or kept as a fallback for as long as you like. No big bang.

The console's “Add a machine” assistant: platform choice, one-time enrollment key and ready-to-copy command. — Step 3 in practice: the enrollment assistant generates the key and the command to run on the gateway.

Frequently asked questions

Can we keep the existing Ewon Cosy boxes during the migration?

Yes, and it is the recommended method. The two systems coexist without conflict: the box keeps its tunnel to the vendor's cloud, the VIGIL-MESH gateway establishes its own outbound connections. You migrate machine by machine, removing each box only once the gateway has proven itself — or leaving it as a fallback.

Do we need to install anything on the PLC?

No. The PLC is never modified: no agent, no firmware, no network configuration change. The gateway — the industrial PC or the Linux machine of the machine network — is what joins the mesh and relays the authorized flows to it.

What if the machine has no PC and no gateway on its network?

Two honest options: add a small dedicated Linux machine in the cabinet (it plays exactly the role of the box, under your control), or keep a remote-maintenance box on that machine. If the site also needs an integrated 4G router, the box combines both functions and remains the rational choice.

Will my engineering tool (PLC program upload) work?

Tools that reach the PLC by its IP address work through the gateway, inside the end-to-end encrypted session. On the other hand, automatic broadcast discovery on the machine network does not cross the gateway: declare the equipment by its address. Between mesh members (gateways, workstations), multicast and discovery do work.

Does the maintenance traffic go through your servers?

Never in cleartext. Sessions are end-to-end encrypted (QUIC/TLS 1.3, hybrid post-quantum key exchange); when a relay is needed, the vigie carries opaque packets without holding the keys. And if you want to own the relay too, the private vigie can be self-hosted at your site or your customer's.