The Vendor Access Problem We See in Almost Every OT Workshop

How it surfaces in customer workshops

OT architecture workshops are the deepest customer work we do: a multi-hour whiteboard session with a manufacturer's IT, OT and security leads, mapping their Purdue model and their access paths with one of our OT architects. We run them regularly, and because they're structured the same way each time, patterns show up in them earlier than they show up anywhere else.

One has been consistent enough to write down, and CISA's updated Internet Exposure Reduction Guidance last month is a good reason to write it down now. Most of that guidance is about getting OT off the internet, but one of its items asks operators to determine whether integrators, vendors and service providers have remote access into their systems - through VPN credentials, cellular modems or anything else - and to verify each of those connections. That is a question we've watched a lot of teams work through in a session. At some point in most of them, usually after the segmentation discussion, someone asks how the OEM's engineer actually reaches a specific controller when a line goes down. The answer usually takes a few minutes and several people: there's a VPN account, a jump host, a box the vendor installed at commissioning, sometimes a cellular modem at a site with no WAN. The path gets drawn, and there's usually more than one of them, accumulated as machines were installed rather than designed together.

Across our most recent dozen workshops - discrete, process, food and beverage, pharma and chemicals - nine already had a named mechanism for third-party access into OT, and secure remote access is mature enough in manufacturing that most have had some form of it for years. Vendor access wasn't missing anywhere. What was missing, in almost every case, was vendor control: deciding who gets in, to what, for how long, and being able to stop it. That's a different problem from the one the industry is still mostly writing about. CISA's Insider Threat Mitigation Guide, updated this month, defines an insider as anyone with authorized access to facilities, networks or systems, employee or not. The operators we sit with already treat vendors that way. Their question is why the access they've built doesn't give them control over it.

How vendors get in today

Across the workshop notes, third-party access into the plant takes one of three shapes. Each one puts the operator's control somewhere the operator can't fully reach.

The OEM's own gateway. The equipment vendor ships a remote-service box with the machine, or installs one at commissioning, and it dials home so their engineers can support the line. It's the vendor's credential, the vendor's session and the vendor's off switch. The operator gets support and gives up all three. Replacing this arrangement is one of the more common reasons a workshop gets scheduled. Putting a VPN or firewall in front of the gateway adds an operational layer without adding control: the operator still can't bound the session to a window or end one in progress.

IT remote access into the plant. The vendor comes in the way an employee would - a VPN account and a jump host, usually with the enterprise privileged access management (PAM) platform handling the credential, recording the session and running the approval. Four of the twelve ran contractor access this way, and it's the most common answer among mature security teams. The PAM layer does its job; the problem is the jump host. The vendor lands on a workstation on the plant network and reaches the target from there, so control depends on that network being reachable, routable, owned by the team deploying the workstation, and with nothing else reachable from it. Those are significant assumptions.

An OT-native remote-access product. Usually adopted because the plant network forced the choice - overlapping address space across production lines, static-IP assets that can't be re-addressed - more than because anyone designed toward it. In those cases the network picked the tool.

Why the plant network shapes the answer

The natural response is to tighten what's already there - harden the jump host, firewall it from the cell, put MFA in front of the vendor gateway. The workshops tend to surface why that's harder than it sounds.

The plant network is rarely what the diagram says it is. The most common finding is a flat network that extends directly into IT, and in several sessions a recent penetration test at the plants is what put it on the agenda. The remedy on offer from equipment vendors is often more firewalls at more Purdue levels. Layer 3 is owned by IT at some plants and by the site at others. Production lines reuse address space and the assets can't be re-addressed. Some remote sites have no WAN at all.

Any control that lives on that network inherits those conditions. A jump host can't route to overlapping subnets, and there's no obvious place for it at a site IT doesn't own. The OEM gateway avoids all of that by bypassing the plant network entirely, which is why vendors like it and why operators can't see it.

This is where the two problems meet, and it's the point the workshops keep coming back to. The front door is usually fine: the vendor authenticates, the session is approved, maybe it's recorded. Then they land on a jump host on a segment where everything is reachable, and from that moment the controls at the door don't matter. The question is what's reachable after the vendor is inside, and on a flat plant network the answer is everything.

Where these sessions usually land is with control moved off the network and onto the session: the vendor doesn't land on the plant network and then get restricted, they reach one system, through a broker, as a known identity, for a defined window - and the segment behind that system is closed off separately. The recent federal guidance points the same direction. CISA's April 2026 joint guidance, Adapting Zero Trust Principles to Operational Technology, is explicit that IT zero trust doesn't transfer wholesale and that identity and access have to be designed around the plant's constraints. The January 2026 Secure Connectivity Principles for Operational Technology, led by NCSC-UK with CISA and FBI, describe one hardened access path reused across vendors, with session monitoring.

What operators describe as control

When a workshop gets to what the path should look like, the requirements are consistent enough across customers that they work as an evaluation lens for any approach, whatever is in place today. In roughly the order they come up:

1. The vendor reaches one system, not a segment. No landing zone on the plant network, no route from the target to anything else, nothing listening on the target - no RDP, SSH or VNC port exposed to get there.
2. The vendor is a known identity. They authenticate as themselves, against an identity the operator has vetted, not an account the vendor created.
3. Access exists only while the work does. Granted for a defined window, and the operator can end the session while it's running.
4. The vendor never holds the credential. Vaulted, injected into the session, rotated after use. This has become the first thing a security lead asks about.
5. Every session is recorded, at every site, including the ones reached over cellular because there's no WAN.

Segmentation isn't on that list, and that's deliberate on the operators' part. It removes the general path and it belongs on the roadmap, but vendor access tends to need fixing sooner than the plant can be segmented, so the two move on separate timelines.

That model is how Zscaler Privileged Remote Access is built: sessions brokered through the Zero Trust Exchange rather than routed to the plant, pixel-streamed to the vendor's browser with no listener exposed, bound to the vendor's identity, and recorded. There is no jump host and no landing zone - the session terminates at the one system it was approved for. Access is granted through a time-bound approval, and an administrator can monitor or terminate an approved session while it's live. Credentials are vaulted, injected into the session, and can rotate after each use; an existing PAM platform keeps doing that job. What the target can reach on its own segment is the other half, and Zero Trust Branch device segmentation closes that behind the session, on its own timeline. For remote sites with no WAN, the site connects over Zscaler Cellular so its assets are reachable through the same broker - the operator's cellular path, rather than the vendor-installed modem CISA's guidance asks operators to go find.

If you'd like to walk your own vendor access paths against this list, request an OT architecture workshop and we'll map them with your team.