Remote access to the plant floor without a VPN

Almost every plant we walk into handles remote access the same way. There is a VPN concentrator at the edge of the network, a set of credentials that gets shared more widely than anybody admits, and a rule that says the integrator can dial in on Tuesdays. It works, in the sense that the integrator gets in.

The problem is what else gets in. A VPN does one job: it puts a device on your network. Once that device is on the network, everything after that is the network being careful. Segmentation, firewall rules, and the hope that the laptop on the other end is patched.

What actually goes wrong

Three things, and they are not exotic. We see all of them in the first week of most engagements.

• The VPN account is shared. It belongs to a company rather than a person, so the audit log tells you a vendor connected, not who, and revoking access means changing a password that four people know.
• The tunnel is wider than the job. A contractor who needs one HMI gets a route to the whole cell, because the VPN grants network access and the network was never segmented finely enough to matter.
• Something has to be reachable from outside. A port forward, an exposed concentrator, or an inbound firewall rule, and that thing is now the front door to the plant whether or not anyone is using it.

None of these are configuration mistakes. They are what a VPN is. It is a network extension tool being used as an access control tool, and it was never the second thing.

The replacement is per service, not per network

EmberFLUX takes the opposite approach. Nothing listens on an inbound port. Every node makes an outbound connection to the fabric and holds it open, and access is granted to a named service rather than to a network.

In practice that means an integrator is authorised to reach one HMI on one line. Not the subnet the HMI sits on. Not the PLC beside it. The HMI. If they try to reach anything else, there is no route to try, because a route was never created.

What that changes on the floor

1. There is no inbound port to attack. The firewall rule that used to allow the VPN concentrator can be removed, and there is nothing to replace it with.
2. Access is per person and per service, so revoking a contractor is one identity change rather than a password rotation and an audit of who knew it.
3. The log says who reached what. Not that a tunnel came up, but that a named person opened a session to a named device at a time you can point at.

The part people ask about next

The first question is always what happens when the connection to the outside drops. The honest answer is the part that matters most, and it is also the part most platforms get wrong, so it deserves its own explanation rather than a sentence here.

The short version: the fabric is how you reach the plant from outside, and it is not how the plant reaches itself. Control traffic between nodes on a line does not leave the line, and it does not depend on anything upstream being reachable. A site that loses its uplink keeps running, because nothing about local operation was routed through somewhere else.

What this does not solve

It does not fix a flat network. If your PLCs and your office printers share a broadcast domain, zero trust remote access stops the outside world reaching them and does nothing about the laptop already inside. That is a separate piece of work and it is worth doing.

It also does not remove the need to decide who should reach what. The tooling makes that decision enforceable instead of aspirational, but somebody still has to make it. In our experience that conversation takes an afternoon and is the most useful afternoon of the project, because it is usually the first time anyone has written the answer down.