VIGIL MESH

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

CriterionTosibox (Lock + Key)VIGIL-MESH
Hardware requiredA 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 modelPoint-to-point tunnels between Keys and Locks — one site at a timeA permanent, real mesh LAN: gateways and workstations are members of the same private network, reachable by name
Multicast / discoveryDepends on the tunnel mode and chosen configurationReal-LAN multicast and discovery between mesh members (mDNS, discovery protocols)
Serial portDepends on the box's interfaces and the chosen modelVirtual-IO remote serial — in beta
Real-time UDP / videoTraffic carried inside the VPN tunnel; direct path or assisted by the vendor's infrastructure depending on the networkEnd-to-end UDP, direct peer-to-peer path as soon as NAT traversal succeeds, seamless migration
Browser SSH terminalNot part of the Key + Lock model itself; see the vendor's offerYes: SSH client running in the page, credentials never sent to our servers
Cloud trust modelTrust anchored in the physical Key-Lock pairing; brokering assisted by the vendor's infrastructure when needed — its documentation is the authorityStructurally blind relays: E2E QUIC/TLS 1.3 + hybrid post-quantum sessions, the relay never holds the keys
Self-hosting the relayDepends 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.

Frequently asked questions

Can we keep the existing Tosibox Locks and Keys during the migration?
Yes, and it is the recommended method. The two systems coexist without conflict: the Lock keeps its tunnels, the VIGIL-MESH gateway establishes its own outbound connections. You migrate machine by machine, remove the Lock once the gateway has proven itself, and collect the physical Keys over the course of visits.
What happens to the “I take back the Key, access disappears” move?
It becomes even faster: revocation from the console is immediate and does not require recovering an object. The revoked identity loses all reachability instantly, wherever the person is — and the audit trail keeps a record of all their past sessions, which a physical object never told you.
Does a lost or stolen workstation give access to the fleet?
No more than it was authorized to: deny-by-default ACLs already limited that workstation to what its rights allowed. As soon as the loss is noticed, you revoke it from the console — immediate effect — and accounts remain protected by MFA: the workstation alone, without the additional factor, is not enough.
Can we really do without any dedicated hardware?
On one condition, stated honestly: you need a Windows or Linux machine on the machine network — that is what replaces the Lock. Often the HMI's industrial PC is already there; otherwise a small Linux machine in the cabinet is enough. If there can be none, or if the box must also bring 4G connectivity, dedicated hardware remains the right choice.
Who can see the remote-maintenance traffic?
No one but the two ends. Sessions are end-to-end encrypted (QUIC/TLS 1.3, hybrid post-quantum key exchange); the direct path is preferred, and when a relay is needed, the vigie carries opaque packets without holding the keys. The private vigie can be self-hosted if you want to own the relay too.
Read nextIndustrial remote maintenance