Giving an engineer remote access without opening up your network
Every installation needs maintenance, and that maintenance rarely comes from your own organisation. The camera supplier, the company that built the access system, the party behind the climate installation - all of them need to get in from time to time. Often at short notice, often outside office hours, and almost always remotely.
The practical solution that emerges is nearly always the same: a VPN account for the supplier. It works, and that is precisely the problem.
Why a VPN is too broad
A VPN connection puts someone on the network. Not at one device, but on the network, with everything reachable from there. In practice that means:
- The access is permanent, including on the 365 days a year when no maintenance happens.
- Who logs in is unknown. The account belongs to the supplier, not to a person. Who used it, and whether that person still works there, is rarely possible to establish afterwards.
- There is no record. There is a login, a logout, and nothing in between.
- The device at the other end is invisible. An engineer's laptop has become part of your network, along with everything on it.
For a plant installation or a security network that is a disproportionately large opening for an operation that usually takes ten minutes.
What the alternative actually has to do
Remote access for maintenance has a handful of requirements that are easy enough to name:
- Per task, not permanent. The connection exists only while the work lasts, and closes by itself afterwards.
- To one device, not to the network. The engineer reaches the panel being worked on and nothing else - enforced technically, not agreed in an instruction.
- In a person's name. Not the supplier's account, but the individual carrying out the work.
- With approval in advance. Someone from your own organisation opens the connection, or at least approves it.
- With a record afterwards. Who, when, at which device, and what happened.
Put those five requirements next to a VPN account and the difference is immediately clear.
What that looks like in practice
The usual building block is an intermediate station: a jump host or bastion in its own zone, the only place from which the underlying network can be reached. The engineer arrives at that station, and the station decides what happens next.
What makes it valuable is not that it exists, but what is built around it:
- The session opens for a single destination, with a firewall rule that disappears again when it closes.
- Strong authentication in a person's name, with a second factor.
- Recording or logging of what happens, so that something can be reconstructed later.
- No transit traffic. The station is an endpoint, not a router. If it is compromised, that is bad enough without it also being a doorway.
Anyone doing those steps by hand keeps it up for a few weeks and then stops. The only version that lasts for years is one where opening and closing is done by software, on the basis of an approved task.
The safest option is still an isolated network
The sharpest answer to this question remains a network that is not connected to the internet at all. For some installations that is achievable, and where it is, it is the right choice.
For everything else: the point is not whether remote access will exist - it will, and if it does not, something worse appears, such as a modem a supplier quietly installs in a cabinet. The point is that the access which does exist is the access you designed.