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").
The practical components of this model are:
| 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 optimised, the fundamental question must be answered: who currently has access to your OT systems? Many operators discover during this exercise that the number of active third-party accounts is two to three times what management expected. Access was granted incrementally, over many years, without systematic tracking or review.
- Build a register of every third party with any form of OT access — name, company, systems they can access, purpose, and date access was last reviewed
- For each entry, confirm the business relationship is still active — expired contracts with live access are one of the most common findings
- Identify every account that is shared (used by more than one person) and replace it with individual accounts before the next maintenance window
- Check when each account last authenticated — accounts with no activity in 90 days should be suspended pending review
- Establish a formal offboarding process: when a vendor relationship ends, access is revoked on a defined timeline, not "eventually"
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.