Documentation
A Tosibox alternative: industrial remote access without hardware keys
The Tosibox model has an elegance everyone understands: a Lock in the cabinet, a Key in the pocket, and physically pairing the two creates the access right. No account to explain, no abstraction — trust fits in the hand. VIGIL-MESH answers the same remote-maintenance need with the opposite move: software identities instead of objects. A Windows or Linux machine of the machine network becomes the gateway, every technician is an identity protected by MFA, and granting or removing access is a rule you write — not an object you ship or chase to get back. This page compares the two models honestly, then walks through the migration for an integrator.
What Tosibox does very well
The Tosibox model rests on two objects: the Lock, a device installed on site next to the equipment, and the Key, a physical object handed to the technician — with software and mobile variants depending on the vendor's offer. Pairing happens physically, by presenting the Key to the Lock, and that materialized bond then governs the connections: encrypted point-to-point tunnels between Key and Lock, direct when the network allows it.
Trust fits in the hand
Physical pairing is understood by everyone — the electrician, the buyer, the CISO: whoever holds the Key gets in, whoever does not, does not. No mental model to teach.
Point to point, no mandatory cloud in the middle
Connections link the Key to the Lock, directly when the network allows it. This sober architectural choice rightly appeals to cautious industrial environments.
Deployment in three moves
Plug in the Lock, pair the Key, hand it to the technician. To equip an isolated site or a contractor, the simplicity of the ritual is a genuine quality.
- A machine without an OS and no PC on the machine network. The VIGIL-MESH agent is software: it needs an operating system. 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 a 4G router integrated into the box. On a site without wired internet, a box that also brings cellular connectivity provides two services in one. VIGIL-MESH does not provide connectivity: it travels over it.
- A policy that mandates hardware — including the physical token. If the customer’s security policy requires a dedicated device on the electrical drawing, or a hardware access token handed over in person, the Key + Lock model is designed precisely for that.
The Key + Lock model, and what it implies at scale
The model's strength — trust materialized in objects — becomes its burden when the fleet and the teams grow. Nothing hidden there: it is the logical consequence of the architectural choice, openly stated by the vendor.
- Objects to buy, track and recover. Every site gets its Lock, every technician their Key: a hardware inventory to fund and maintain. A technician leaving or a contract ending becomes a logistics operation — recovering or invalidating the object — where you would want a simple rule to edit.
- One box per site or per machine. As with any hardware model: purchase, spare stock, wiring, replacement — including in cabinets that already hold an industrial PC.
- Access is point to point towards a Lock. You reach one site at a time, through its Lock’s tunnel. The fleet is not a network you walk through with your tools: it is a keyring of tunnels.
- Brokering remains a service. When the direct path does not come through, the vendor’s infrastructure helps establish or relay the connection — for the exact guarantees, its documentation is the authority.
The VIGIL-MESH approach: identities instead of objects
VIGIL-MESH transposes the model into software. The Lock becomes a software gateway: an agent installed on a Windows or Linux machine of the machine network — industrial PC, Linux box, NVIDIA Jetson —, joining your private network through a single outbound connection and relaying authorized flows to the PLC, with no inbound port. The Key becomes an identity: every technician authenticates with their account (protected by MFA), from an enrolled workstation or even a plain browser. The PLC-side setup is detailed in Remote access to a PLC.
Granting access = writing a rule
A new contractor? An identity, a group, an ACL: they reach the gateway of the relevant site, on the useful ports, and nothing else — deny by default. No object to ship, no pairing tour.
Removing access = one click, not a chase
Revocation is immediate from the console: the identity loses all reachability, and the audit trail keeps a record of every past session. Nobody chases a Key in a former technician's pocket.
A real fleet LAN, not a keyring
All gateways and authorized workstations are members of the same private network: readable MagicDNS names, discovery and multicast between members, an SSH terminal from the browser. The fleet is walked through like a local network.
End-to-end encrypted, blind relays
End-to-end encrypted QUIC/TLS 1.3 sessions with a hybrid post-quantum key exchange. The direct path is preferred; when a relay is needed, the vigie carries opaque packets without holding the keys — and the private vigie can be self-hosted at your site.
Qualitative comparison
| Criterion | Tosibox (Lock + Key) | VIGIL-MESH |
|---|---|---|
| Hardware required | A Lock per site or machine, a Key per technician (software variants depending on the offer) | No dedicated hardware: a software agent on a Windows/Linux machine of the machine network — often already present |
| Network model | Point-to-point tunnels between Keys and Locks — one site at a time | A permanent, real mesh LAN: gateways and workstations are members of the same private network, reachable by name |
| Multicast / discovery | Depends on the tunnel mode and chosen configuration | 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; direct path or assisted by the vendor's infrastructure depending on the network | End-to-end UDP, direct peer-to-peer path as soon as NAT traversal succeeds, seamless migration |
| Browser SSH terminal | Not part of the Key + Lock model itself; see the vendor's offer | Yes: SSH client running in the page, credentials never sent to our servers |
| Cloud trust model | Trust anchored in the physical Key-Lock pairing; brokering assisted by the vendor's infrastructure when needed — its documentation is the authority | Structurally blind relays: E2E QUIC/TLS 1.3 + hybrid post-quantum sessions, the relay never holds the keys |
| Self-hosting the relay | Depends on the vendor's offer (dedicated central components) | Yes: self-hostable private vigie — the relayed path goes through a machine of yours |
Migrating: the integrator scenario
The typical case: an integrator equipping machines at customer sites with one Lock per cabinet, whose technicians — and sometimes customers — hold Keys. The full picture of the topic is in Industrial remote maintenance.
The Key + Lock ritual served you well. But the fleet has grown, teams rotate, and object-based trust shows its cost:
- A Lock to buy and wire per delivered machine — including in cabinets that already hold an industrial PC.
- Keys to fund, distribute, inventory — and to recover or invalidate at every technician departure, contract end or loss.
- Point-to-point access: every intervention opens one site's tunnel; supervising the whole fleet or comparing two machines is not the model's natural move.
- End customers asking questions: who holds a Key to their site, how fast can it be removed, what trace remains of each session.
The migration replaces both objects at once: the Lock with a software gateway on a machine already present, the Key with an identity you create, restrict and revoke in seconds.
- 1Identify each machine's gatewayThe HMI's industrial PC, a Linux box, a Jetson: any Windows or Linux machine that sees the machine network can replace the Lock. If there is none, add a small Linux machine — or keep the Lock on that site: both coexist.
- 2Create the workspace and one network per customerOne VIGIL-MESH network per end customer: fleets stay sealed from each other, and each customer can receive access limited to their own machines — without holding a Key to anything else.
- 3Enroll the gatewayConsole → Networks → Machines → “Add a machine”: one-time enrollment key, identity generated on the machine itself, no inbound port — a single outbound flow on 443 UDP. It is the software equivalent of pairing.
- 4Recreate the keyring's rights as ACLsEvery distributed physical Key becomes a rule: this technician (identity + MFA) reaches this gateway on these ports, deny by default for everything else. The audit trail logs every session — something the keyring never told you.
- 5Verify in real conditionsThe gateway appears in the inventory with its stable address; the engineering tool reaches the PLC through the gateway; the browser SSH terminal opens a session from any workstation, with no Key in the pocket.
- 6Switch over machine by machineLocks and gateways coexist without conflict: migrate at the pace of maintenance visits, remove the Lock once the gateway has proven itself, and collect the physical Keys as you go — the object model's final collection round.

- The gateway's platform: Windows for an HMI industrial PC, Linux for a site box or a Jetson.
- The enrollment command: the key is single-use and expires on its own — nothing to recover later, unlike an object.
- The console waits for the machine: as soon as the agent connects (outbound), the gateway appears in the inventory.