Giving a Vendor Access to Your Internal Systems Without a VPN

An outside firm needs to look at one of your systems: the ERP vendor is chasing a bug, the camera company needs the NVR, the automation contractor has to open a PLC panel. In most organisations the answer is one of two things — a VPN account, or a server password sent over chat. Both get the job done. Both leave behind an access path you are no longer managing.

Three problems with VPN for vendor access

VPN is not a bad technology — it is the wrong tool for this job. It was designed for your own staff: it takes someone you trust and puts them inside your network. A third-party vendor is precisely the party who should not be inside it.

1. The scope is far too wide

Once the tunnel is up, the vendor is a client on your network. You can narrow it with firewall rules, but those rules work at the network layer: an address range, a port. There is no VPN rule that says "only this screen of this application". In practice the vendor sees many times more than the job needs.

2. It does not end by itself

An account opened for one job does not close when the job finishes — it closes if somebody remembers to close it. One of the most common audit findings anywhere is an active vendor account left over from a project two years ago. A standing credential is a standing risk.

3. It does not show what was done

VPN logs tell you who connected and when. They do not tell you which server they opened, which record they changed, or which file they copied. After an incident, "what did the vendor do that evening" is a question a VPN log cannot answer.

Why a shared password is worse

The usual alternative — handing over an administrator password — carries all three problems above and adds one more: you cannot tell people apart. How many people at the vendor know that password, which of them signed in, and is it still in the pocket of the engineer who left last month? None of those answers are yours to give.

The right model: one resource, time-boxed, recorded

What vendor access actually needs is not a network connection but brokered access to a single resource. It has four properties:

• The scope is a resource, not a network. The vendor is authorised for "that RDP host" or "that web panel", not for 10.0.5.0/24. The server next to it is neither reachable nor scannable.
• The grant carries a start and an end. Access given for Tuesday 14:00-17:00 ends at 17:00 on its own. Nobody has to remember to revoke it.
• The identity belongs to a person. Every engineer at the vendor signs in as themselves. With passkeys there is no password to share in the first place.
• The session is recorded. You can watch it live or replay it later. "What was done" becomes a record instead of a guess.

No inbound port required

The part that surprises people most is that this model opens no way into your network. A small broker (a connector) runs inside your network and makes an outbound connection. Access requests travel inward over that existing connection.

The practical result: no new forwarding rule, no open port, no new internet-facing service. Someone scanning your perimeter finds no new surface to defend, because there is none.

Where to start

1. Count the vendor access you already grant. How many outside firms hold a VPN account, how many still need one, and how many have an end date written down anywhere? This list is usually longer than expected.
2. Write down each one's real scope. The number of systems a vendor must touch to do their work is usually one or two. The access granted is usually the whole network.
3. Start with one vendor. Pick the firm that connects most often, move them to single-resource, time-boxed access, and watch it for a month. If the model holds, the rest follow the same path.

With Captivo Access

Captivo Access implements exactly this model: the vendor signs in with a passkey under their own identity, is authorised for a single application or host with a start and end time, loses access when the window closes, and has their session recorded. The connector inside your network only makes outbound connections, so no inbound endpoint appears on your firewall.

You can try the hosted free tier, or run it on your own server since it is open source — in which case the session recordings never leave your infrastructure. For the other side of network access, your own staff and devices, see 802.1X network access control.