Vendor Remote Access to OT Without a VPN

Your chargers come from one vendor. Your meters come from another. The controllers on the factory floor come from a third. Each vendor needs to reach its own equipment to push firmware, read logs, and fix faults. In most operations, all of them do it through the same VPN.

That arrangement made sense when a handful of engineers dialed into a single site. It stops making sense once you run thousands of connected devices across several countries, with a different vendor behind every device type. The VPN becomes the widest door in your estate, and the people walking through it do not work for you.

The short answer: replace network-wide VPN accounts with brokered sessions that give each vendor access to a single device, through a browser, for a limited time, with every session recorded. The rest of this article explains why the VPN model breaks for operational technology (OT) and IoT fleets, and how to make the switch vendor by vendor.

Why Vendor Access Became the Weak Point

Third parties are now a common way in. Verizon's 2024 Data Breach Investigations Report found that 15 percent of breaches involved a third party, including partner infrastructure and software supply chain issues. That was a 68 percent rise on the previous year.

IoT and OT make the exposure worse, for 3 reasons. The devices are headless. Most have no screen and no operating system able to run a security client, so protection has to live somewhere else. The vendors are many. 

One European charging operator works with 7 or 8 vendors of high-speed chargers, each with its own tools, its own support team, and its own preferred way in. And the consequences are physical. A compromised laptop on an office network leaks data. On an OT network, it stops a production line or takes a charging site offline.

Regulators have noticed. Article 21(2) of NIS2 lists supply chain security, including the security of relationships with direct suppliers and service providers, as a required measure. It sits next to access control policies and multi-factor or continuous authentication. NIS2 also holds management bodies accountable for approving and overseeing those measures. Vendor access is no longer IT housekeeping. It is a board question.

What Goes Wrong with a Shared VPN

A VPN answers one question: is this user allowed onto the network? Once the answer is yes, the vendor's laptop sits on the same network as your devices. In most OT setups, that grants far more reach than the job needs. The same 4 failure patterns show up again and again.

Broad network access

A vendor who needs to update 40 chargers gets a route to the whole subnet, and to neighboring ones too. If that laptop is compromised, the attacker inherits the same reach. Lateral movement does the rest.

Accounts that never expire

Credentials created for a single job stay active for years. Nobody owns the offboarding. Shared logins mean you cannot tell which engineer did what, or when.

Exposed ports

To make remote access work, someone opens inbound ports on a router or gateway. Those ports are visible to anyone scanning the internet, not only to your vendor.

Client sprawl and address conflicts

Every vendor wants its own VPN client and its own IP address plan. Overlapping ranges break connections. Teams add workarounds and exceptions until nobody understands the whole configuration.

None of this is exotic. It is the default outcome of a model built for employees on laptops, stretched to cover outside companies servicing devices that cannot defend themselves.

What Works Instead

The better model flips the question. Instead of letting a vendor onto the network and then trying to fence them in, you give them a single connection to a single application on a single device, for a single session. Nothing else is in reach. Security teams call this Zero Trust. For vendor access, it comes down to 5 controls.

No inbound ports

Devices and on-site connectors open outbound connections to a broker. Nothing listens on the internet, so there is nothing to scan. You cannot attack what you cannot see.

Access per device, not per network

The vendor sees the remote desktop, command line, or web interface of the equipment they support. They never get a route into the wider network.

Clientless browser access

The vendor opens a browser, signs in with multi-factor authentication, and lands on the device. No VPN client to install. No address plan to reconcile.

Time limits and approval

Sessions open inside an agreed window, or only after someone on your side approves them. Access expires by default instead of lingering by default.

Recording and audit trail

Every session is logged: who connected, to which device, when, and what they did. Your own engineer watches live when needed and ends the session if something looks wrong.

Here is what that looks like in practice. The charging operator mentioned above moved its vendors from VPN accounts to browser access. Each vendor reaches only its own chargers, for a set number of hours or days, with the session recorded. There is no client to install, and no vendor sees another vendor's equipment.

Together, these controls give auditors the evidence NIS2 asks for on supply chain security and access control. None of them require your vendors to change their own tools.

Where Connectivity Fits

Most vendor access projects start in the IT security team, and they assume the devices sit on a site network behind a firewall. A growing share of IoT does not. Chargers, meters, security cameras, and asset trackers connect over cellular, spread across hundreds of locations and several countries, with no local network at all.

For those fleets, the connectivity layer decides how much of the model you get to apply. Ask 3 questions. Does device traffic stay off the public internet? Is access policy enforced in the network, since the device cannot run an agent? And do you see which devices talk to what, so an unusual connection stands out?

A private APN (access point name) answers the first question and stops there. It hides traffic, but it does not defend it. It is still a flat network, so any device or vendor inside it reaches everything else inside it. If the answer to all 3 questions is no, your vendor access policy exists on paper only.

"If you have your own private APN and one of your vendors needs to connect through a VPN to troubleshoot a device at a remote site, you basically open the door for that third party, for that PC, from that network. That's one of the major problems we see today." Henning Solberg, CTO of IXT

A Practical Starting Point

You do not need to replace every vendor connection in one project. Start with an inventory. List every third party with remote access, what they connect to, how, and when anyone last reviewed their credentials. Most organizations find more active accounts than they expected.

Then pick the vendor with the widest access and move them first. Replace their VPN account with brokered, per-device sessions. Turn on recording. Set an expiry date. Track how long support tickets take before and after. Many vendor engineers find browser access faster than fighting with a client.

Repeat vendor by vendor, not site by site. Within a few cycles, the shared VPN becomes a fallback instead of the front door. After that, you switch it off.

FAQ

How do you give third-party vendors remote access to industrial devices without a VPN?

You route each vendor through a broker that grants a browser-based session to one specific device, protected by multi-factor authentication, limited in time, and recorded. The device opens only outbound connections, so no inbound ports face the internet.

Is a VPN enough for OT vendor access?

Not for most OT fleets. A VPN checks who connects, then places the vendor on your network. One compromised vendor laptop exposes every device that network reaches.

Does NIS2 require secure vendor access?

NIS2 Article 21(2) requires supply chain security, access control policies, and multi-factor or continuous authentication. Time-limited, recorded, per-device vendor sessions are one way to show auditors those controls are in place.

Does a private APN secure vendor access?

A private APN keeps traffic off the public internet, but it does not limit what a connected vendor reaches inside it. Per-device access policy and traffic visibility have to sit on top.

Solving Complications

Vendor access will not get simpler. Fleets grow, supplier lists grow, and regulators expect you to show control over every party that touches your equipment. For most IoT and OT fleets, a shared VPN cannot give you that. Per-device, time-limited, recorded access does.