Industrial equipment usually comes with a vendor who needs to support it: to diagnose faults, apply updates and tune performance. That support increasingly happens remotely, which means vendors need a way into networks that are otherwise tightly controlled.
Vendor remote access is consistently cited among the top risks to OT environments, not because vendors are careless, but because the access tends to be standing, broad and poorly bounded. The goal is to make vendor connectivity exist only when it is needed and prove that it did.
01Key takeaways
- 01
Vendor remote access is a leading OT risk because it is often standing, broad and weakly bounded.
- 02
Standing access is the core problem: a path that exists all the time can be abused at any time.
- 03
Just-in-time access flips the default so connectivity exists only during an approved task.
- 04
Jump hosts help but can be bypassed, left exposed, or turned into a foothold of their own.
- 05
Time-boxed, physically controlled and logged windows make vendor access both safer and provable.
02Why vendor access is a top OT risk
Vendor access combines several risk factors at once: it reaches sensitive systems, it involves a third party whose security you do not control, and it is often configured for convenience because support needs to be fast.
OT security guidance repeatedly highlights remote and third-party access as a path through which incidents reach operational systems. The exposure is not the vendor; it is the standing, unbounded nature of the access they are usually given.
The danger is rarely the vendor's intent. It is a path that stays open long after the work is done.
03Standing access vs just-in-time
Standing access means a path exists continuously: a permanent account, an always-up VPN, a tunnel that nobody turns off. It is convenient and it is exactly what an attacker hopes to find.
- Standing access
- Connectivity that exists all the time, whether or not a task is in progress. Convenient, but available to be abused at any moment.
- Just-in-time access
- Connectivity that is created for a specific approved task and removed when the task ends, so the path does not exist between sessions.
Moving from standing to just-in-time access is the single biggest improvement most environments can make. If the path does not exist between sessions, it cannot be used between sessions.
04Jump hosts and their failure modes
A jump host is a controlled intermediary that vendors connect through, where sessions can be brokered, recorded and restricted. It is a sound pattern and worth using, but it is not a complete answer.
- A jump host that is always reachable is itself a standing path that can be attacked.
- Weak or shared credentials on the jump host undermine the control it is meant to provide.
- Insufficient session restrictions can let a vendor reach further than the task requires.
- A compromised jump host becomes a foothold with legitimate routes into OT.
- Emergency exceptions to the jump-host process tend to become permanent.
The jump host concentrates access, which is useful for control but also makes it a high-value target. It needs the same disconnect-by-default thinking as the systems behind it.
05Time-boxed, physically controlled windows
The strongest version of just-in-time access does not rely solely on software to create and remove the path; it makes the path physically absent between sessions.
An AIRGAPNET controlled connectivity device can keep the vendor access path physically disconnected by default and open it only for an approved, time-boxed session, then close it again. Because the control is driven out of band, the vendor cannot extend their own window and a foothold on the access network cannot hold the path open.
Combined with a jump host, this yields a layered model: the session is brokered and recorded, and the underlying path exists only during the approved window.
06Logging and evidence
Vendor access should be provable after the fact: who connected, when, for what task, and what the path allowed.
- Tie every access window to an approved ticket with a defined task and duration.
- Log connection and disconnection times against that approval.
- Record sessions through the jump host for accountability.
- Review windows to confirm none stayed open beyond their approved time.
07Vendor remote access checklist
- Have standing vendor paths been replaced with just-in-time access?
- Does every session go through a controlled, recorded intermediary?
- Is the underlying access path physically absent between sessions?
- Is the connection control out of band so it cannot be held open from the access network?
- Is every window tied to an approval with a defined task and duration?
- Can the team prove who connected, when, and for how long?
08Closing thought
Vendors will always need occasional access, and that is fine. The problem is the standing path that quietly remains between the times it is needed. Remove that path and reintroduce it only for approved, time-boxed, provable windows.
Broker the session, record it, and make the underlying connection exist only while the work is happening. Support stays possible; the open door does not stay open.
FAQFrequently asked questions
Why is vendor remote access such a big OT risk?
Vendor access reaches sensitive systems, involves a third party whose security you do not control, and is often configured as standing, broad access for convenience. The exposure comes from that standing, unbounded nature rather than from the vendor itself.
What is just-in-time vendor access?
Just-in-time access creates connectivity for a specific approved task and removes it when the task ends. Because the path does not exist between sessions, it cannot be used between sessions, unlike standing access.
Are jump hosts enough to control vendor access?
Jump hosts are a sound pattern for brokering and recording sessions, but they are not complete. An always-reachable jump host is a standing path, can be compromised into a foothold, and needs the same disconnect-by-default approach as the systems behind it.
How do time-boxed connection windows help?
They make the access path physically absent between sessions and present only during an approved window. Driving the control out of band means the vendor cannot extend their own window and a foothold cannot hold the path open.
What evidence should vendor access produce?
Every access window should tie to an approved ticket with a defined task and duration, with logged connection and disconnection times and recorded sessions, so access can be proven and reviewed afterward.
SRCSources of record
Occasional access, not an open door
Make vendor connectivity exist only while the work is happening.
Replace standing vendor paths with time-boxed, physically controlled windows that are brokered, logged and disconnected by default between sessions.