Everything you need to know about OT vendor access

A vendor engineer needs to reach one controller on one site. What they get is a VPN account, and with it a route into a flat network holding several hundred other devices they have no business touching.

Nobody designed it that way. It accumulated. The first vendor needed access, the VPN was already there, and the pattern repeated with every hardware supplier that followed. Six vendors later you have six standing routes into your operational network, and no record of what any of them did last Tuesday.

Why VPN access became the default, and why it stopped working

VPNs were built to put a trusted employee on a corporate network from a hotel room. That model rests on two assumptions. The person on the other end is inside your organisation, and the network they land on is one you want them to see.

Third party vendor access breaks both. The engineer works for a supplier, under a contract, on a schedule you do not control. And the network they land on holds your entire operational estate.

The practical failures follow quickly.

Access is network shaped, not device shaped. A VPN grants a route. Once the tunnel is up, reachability is decided by your internal routing and firewall rules, which are almost never written per vendor per device.

It stays on. Vendor accounts outlive the projects that created them. The commissioning contractor from 2023 is still in the directory.

You cannot see what happened. Connection logs record that a tunnel opened. They do not record that someone changed a setpoint on a charger.

It does not survive multi vendor sites. Overlapping private address ranges, competing client software, and vendors who quite reasonably refuse to install your VPN client on their laptops.

Lateral movement is unconstrained. One compromised vendor laptop with an active tunnel reaches everything the tunnel reaches. Segmentation is the only thing standing between a supplier's endpoint problem and your fleet, and flat OT networks have none.

What good vendor access looks like

Reframe the requirement. The vendor does not need to be on your network. They need to interact with one device, for a bounded period, in a way you record.

Four properties define the difference.

Least privileged access, scoped to the device

Each vendor reaches the specific devices they maintain and nothing adjacent. Not a subnet. Not a VLAN they share with someone else's hardware. The devices on their contract.

Sessions with a start and an end

Access is granted for a window and expires on its own. Business hours only, a maintenance window, or a single approved intervention. Revocation stops being a task somebody has to remember.

A record of actions, not just connections

Who connected, to which device, when, and what they did while they were there. Session recording turns vendor access from a trust arrangement into an auditable one, which is the form auditors and insurers ask for.

Nothing installed on either side

Clientless browser based access removes the software negotiation entirely. The vendor opens a browser and gets SSH, VNC or RDP to the device. No client on their laptop. No agent on the device, which matters because most industrial endpoints have no capacity to run one.

How Zero Trust delivers this at the connectivity layer

Zero Trust removes the assumption that anything inside your network is safe. Every device and every session is untrusted until verified. For IT estates this is settled practice. For OT it has been stuck, because the standard tooling depends on agents and industrial devices do not run agents.

IXT resolves that by moving enforcement into the network and cloud rather than onto the device.

The SIM identifies the device. IXT SecureNet keeps traffic off the public internet on a private APN. IXT Zero Trust checks every session before a connection opens. Three layers, three jobs.

Zero Trust connectivity through Zscaler

Devices initiate outbound connections to the Zero Trust Exchange. No inbound ports are exposed, so there is no listening service for a scanner to find. You cannot attack what you cannot see. Vendor sessions arrive through the same broker: Privileged Remote Access delivers browser based SSH, VNC and RDP, time limited, recorded and co-viewable if you want an engineer watching alongside. IXT is Zscaler's named partner for Zscaler Cellular.

Traffic visualisation and segmentation through Illumio

Real time traffic mapping across every connected device, automatic anomaly detection, and policy based segmentation applied to headless endpoints. Micro-segmentation contains a breach to a single device and prevents lateral movement across the fleet. The map also answers the question most OT teams struggle with: what is actually talking to what.

What this looks like on a real site

A European EV charging operator running eight hardware vendors needed each supplier to reach their own chargers. VPN was producing address conflicts between vendors, and granting network wide access to eight external parties was not something the security team would sign.

Each vendor now gets a browser session to their own units, time limited to business hours, session recorded, initiated from the Zero Trust Exchange. No client install. No IP conflicts. No network access beyond the specific device.

The same pattern applies wherever an external party maintains equipment you own:

• Utilities and grid infrastructure. Substation and metering hardware maintained by the manufacturer, under supervisory rules that require a supplier access record.
•  
• Industrial automation. PLC and drive vendors supporting equipment across multiple plants, where a single flat OT network connects production lines that should never reach each other.
•  
• Building and surveillance systems. Camera and access control integrators managing devices across a property portfolio, where the installer's remote tooling is the weakest link in the estate.

Where this meets NIS2

Supply chain security is named directly in the directive, and vendor remote access is where most operators find their gap. NIS2 places personal liability at board and C-suite level, which changes who asks the question.

IXT Zero Trust addresses NIS2 Article 21(2) technical controls: access control, network segmentation, incident detection, supply chain access, audit trail and continuous authentication. What stays with you: risk documentation, incident response plans, staff training and your supplier governance framework. IXT Zero Trust does not make you NIS2-compliant on its own, and any provider telling you otherwise is selling.

Verify these claims against your legal and compliance team's interpretation of the transposed national legislation in your jurisdiction before including them in tender responses or compliance documentation.

Frequently asked questions

Is a private APN sufficient for vendor access?

A private APN hides traffic but does not defend it. The devices remain on one flat network with each other. It solves exposure to the public internet and leaves lateral movement and vendor scoping untouched.

We already use Zscaler for our IT estate. Does that cover OT?

Not on its own, because Zscaler's standard path assumes an agent on the endpoint. IXT extends that same ZTNA to IoT and OT devices over cellular, reaching the hardware your existing deployment cannot.

What does the vendor have to install?

Nothing. Access runs in a browser. This removes the negotiation over installing your software on a third party's machine, which is where vendor access projects stall.

Does this replace our SIEM or SOC?

No. Zero Trust controls and records access. Detection, correlation and response remain functions of your security operation, fed by the audit trail this produces.

How many devices does this make sense at?

IXT qualifies Zero Trust deployments at around 500 devices, or earlier when a compliance deadline or a vendor access incident is driving the timeline. Below that, and with no regulatory pressure, start with connectivity and private networking.

What about devices we already have in the field?

Enforcement sits in the network and cloud, so there is no firmware change and no site visit to add it. Device type and protocol support need a technical assessment first, because not every industrial protocol is covered without one.

Where to start

Count your standing vendor accounts. Then check how many of them map to a device rather than a network, expire on their own, and produce a record of what was done. The distance between those two numbers is the size of the problem.

Ask us how it works for your deployment. Book a demo at ixt.io.