The air gap is dead. Remote monitoring, vendor diagnostics, and software updates are now standard parts of industrial operations. Automation vendors need to connect to commission equipment. Systems integrators need access to troubleshoot. Original equipment manufacturers offer remote monitoring as a standard feature of their service contracts. Without the ability for third parties to connect remotely, maintenance and support costs would increase dramatically and response times would be unacceptable.
The problem is not remote access itself — it is how it is being done. A shared VPN account sent over email, never changed since it was first created, accessible from anywhere in the world, with full network-level access once connected: this is not a hypothetical scenario. It is the current state at a significant proportion of industrial facilities. Remote access has become the most common attack vector against OT environments precisely because it is so widely available and so poorly governed.
Why the Old Playbook Has Failed
The traditional approach to OT remote access was built on two assumptions: that the list of people who needed remote access was small and stable, and that network-level VPN access was acceptable because OT networks were otherwise well-isolated. Both assumptions are now wrong.
Explosion of connected parties. The number of vendors, integrators, and support staff with some form of remote access to OT systems has grown substantially over the past decade. A mid-size manufacturing facility might have five or ten active OEM service contracts, each with remote access capability. Over five years, access is granted and rarely systematically revoked when contracts end, staff turn over, or access is no longer needed.
VPN vulnerabilities. The firewalls and VPN concentrators that protect OT network perimeters have themselves become targets. In 2024, CISA, the NCSC, and allied agencies published joint guidance noting that threat actors were actively exploiting unpatched vulnerabilities in perimeter devices — specifically VPN gateways — as their preferred initial access method. The very device that was supposed to protect the network became the entry point.
AI-powered credential theft. Phishing campaigns that target OT vendors and integrators are now highly personalised. AI tools can scrape LinkedIn, company websites, and public documentation to craft messages that reference real colleagues, real system names, and real project details. Credential theft from a vendor's employee is often the first step in an OT supply chain attack.
A common scenario: A small automation vendor provides remote support to twenty industrial clients. One vendor employee has their laptop compromised via a phishing email. The attacker now has VPN credentials to twenty separate OT environments. The clients have no way of knowing because they trusted the vendor's access as if it were their own.
The Zero Trust Principle: Identity First
The NCSC, CISA, and allied security agencies have published clear guidance on what future-proof OT remote access looks like. The core principle is "identity-first": every connection must involve a verifiable user identity, a verified device state, and explicitly authorised access to a specific resource — not general network access.
Zero Trust for OT remote access does not mean "trust nothing and allow nothing." It means shifting from implicit trust ("you have a VPN account, so you can connect") to explicit, continuous verification ("you are this specific person, on this specific device, at this specific time, and you are authorised to access only this specific system").
In practice, this means individual named accounts instead of shared credentials, phishing-resistant MFA instead of passwords alone, a jump server or PAM solution that proxies and records every session, and just-in-time access that exists only during the approved window. The vendor reaches only the specific protocol they need for the specific device they are there to work on — not the full OT network. Every session is logged. That's the model. The table below shows what each component replaces and what it provides.
| Component | What It Replaces | What It Provides |
|---|---|---|
| Individual named accounts | Shared generic credentials | Accountability — every action is attributed to a specific person |
| Phishing-resistant MFA | Password-only authentication | Credential theft alone is not sufficient to gain access |
| Jump server / PAM solution | Direct VPN into OT network | All sessions are proxied, recorded, and can be terminated centrally |
| Just-in-time access | Standing always-on access | Access exists only during the approved maintenance window |
| Protocol allow-listing | Full network access | Vendor can only use the specific protocol needed for their role |
| Least-privilege asset access | Access to the full OT network | Vendor can only reach the specific device they are there to work on |
| Session recording | No audit trail | Complete record of every action taken; basis for forensics after an incident |
The Architecture: What a Secure Vendor Access Model Looks Like
Practical Controls That Every Operator Can Implement
Kill the Shared Credentials
Every vendor, integrator, and OEM support engineer who accesses your OT systems should have an individual, named account. Shared accounts ("vendor_generic", "plc_admin", "support1") prevent attribution, survive staff turnover indefinitely, and cannot be reliably revoked without affecting others who share them. This is the first and most important change to make.
Deploy a Jump Server or PAM Solution
A jump server (also called a bastion host or privileged access workstation) is a hardened server that sits between the external access point and the OT network. All vendor sessions must go through it. The jump server enforces authentication, limits what protocols can be used, records all sessions, and provides a single point where access can be revoked instantly. For OT-specific environments, dedicated solutions like Claroty xDome SRA, Cyolo, Xage Fabric, and Secomea SiteManager provide zero-trust remote access designed for industrial protocols and environments.
Just-in-Time Access
Standing access — an account that can connect any time, indefinitely — is a risk that exists continuously. Just-in-time access means a vendor must request access for a specific window (e.g., Tuesday 09:00–13:00) and access is automatically revoked when the window closes. If the maintenance is incomplete, the vendor requests an extension. This eliminates the risk of forgotten standing access and forces a regular review of who actually needs to connect.
Protocol Allow-Listing
A PLC vendor connecting to update firmware needs RDP or a vendor-specific protocol to that one device. They do not need SSH access to the historian, Modbus write access to other PLCs, or access to the engineering workstation's file shares. Protocol allow-listing at the jump server or firewall level enforces this: the connection is permitted to use only the specific protocol required for the defined task, to the specific device identified in the request.
Contractual Requirements for Vendors
NIS2 Article 21(d) requires organisations to manage supply chain cybersecurity. This means third parties who access your OT systems should be contractually required to maintain minimum security standards: named individual accounts (no sharing), MFA enabled, security awareness training for staff with OT system access, and incident notification obligations if their own systems are compromised.
Many operators assume their large vendors (ABB, Siemens, Rockwell, Honeywell) have adequate security controls because of their size. Vendor size and security posture do not always correlate. Third-party risk assessment should be based on evidence, not assumption.
Managing the Inventory of Third-Party Access
Before any technical controls can be improved, you need to answer a basic question: who actually has access to your OT systems right now? I say "right now" deliberately — not who was approved in the last access review, but who holds active credentials at this moment. Most operators discover that the number is two to three times what management expected. Access gets granted incrementally over years, nobody tracks it systematically, and accounts accumulate like sediment.
Start by building a register of every third party with any form of OT access — name, company, which systems they can reach, what the business purpose was, and when access was last reviewed. Then check each entry: is the business relationship still active? Expired contracts with live credentials are one of the most common things I see in these audits, and they're almost never noticed until someone goes looking. Find every shared account — anything used by more than one person — and replace it with individual accounts before the next maintenance window. Check last authentication dates: anything with no activity in 90 days should be suspended pending confirmation. And establish a real offboarding process, one with a defined timeline, not a policy that says access will be revoked "when the contract ends."
What the Access Review Should Cover
| Review Question | Frequency | Action if Answer is "No" or "Unknown" |
|---|---|---|
| Is this vendor relationship still active? | Quarterly | Suspend access pending confirmation; revoke if inactive |
| Are the individual named users still employed by the vendor? | Quarterly | Revoke accounts for departed individuals immediately |
| Has this account authenticated in the last 90 days? | Monthly automated check | Flag for review; suspend if no business justification |
| Is this account's access scope still appropriate? | Annually / on contract renewal | Reduce access to current minimum requirement |
| Does the vendor have contractual cybersecurity obligations? | On contract review | Include minimum security requirements in next contract revision |
Securing Maintenance Without Stopping It
The most common objection to tighter vendor access controls is operational: "If we add more steps to vendor access, maintenance will slow down and we will miss maintenance windows." This concern is legitimate and should be taken seriously in the design of the access model.
The solution is not to choose between security and operational efficiency — it is to design the access workflow with operational constraints explicitly accounted for. Pre-approved maintenance windows for regular vendors can be established in advance: the access request for the quarterly ABB service visit is approved as part of the maintenance planning cycle, not as an emergency exception the morning of the visit. Emergency access procedures — faster approval, documented justification required — are separate from routine access and are designed to be faster specifically because they are used rarely.
The goal is a defensible architecture for remote access: one that means only the right people, at the right time, with the right tools, can reach your most critical assets — and where every session is visible and auditable.