Why Vendor Access to OT Is a Critical Security Gap

Third-party vendors maintain, update, and troubleshoot the industrial control systems that run power grids, water treatment plants, manufacturing lines, and pipeline operations. These vendors need access to SCADA servers, HMI panels, engineering workstations, and historian databases – often remotely, often urgently, and often from networks the organization does not control.

The operational need is clear. The security problem is equally clear: vendor access is now the primary attack vector into OT environments.

Dragos tracked 119 ransomware groups targeting industrial organizations in 2025, a 64% increase from 2024. These groups did not exploit obscure ICS protocols. They authenticated into VPN portals with stolen credentials, then used RDP and SMB to move laterally toward SCADA systems. Claroty found that 82% of verified OT intrusions used internet-facing remote access tools as the initial entry point. The SANS 2025 ICS/OT Security Survey reported that 50% of OT breaches originated from unauthorized external access.

The pattern is consistent: attackers do not breach the data diode or exploit the PLC directly. They walk in through the front door – the vendor VPN – using valid credentials purchased from initial access brokers.

This article explains how to provide secure vendor access to OT systems without VPN or open inbound ports, using a Zero Trust architecture that enforces identity verification, least-privilege access, and session control at the application layer.

What Makes Vendor Access to OT Different from Standard IT Remote Access?

Vendor access to OT systems presents challenges that standard IT remote access solutions were not designed to handle. Understanding these differences is essential before selecting an architecture.

OT-Specific Vendor Access Challenges

Challenge	IT Remote Access	OT Vendor Access
Protocol diversity	Primarily HTTP/S and web apps	RDP to HMI, SSH to SCADA servers, proprietary protocols, SMB for configuration files
Network isolation requirements	Standard firewall segmentation	Purdue Model level separation, IEC 62443 zone/conduit enforcement, air-gap or DMZ requirements
Availability priority	Business continuity	Safety and physical process continuity – downtime can cause physical damage
Endpoint constraints	Managed corporate devices	Vendor laptops, unmanaged devices, cannot install agents on legacy OT endpoints
Access urgency	Planned maintenance windows	Emergency troubleshooting at 3 AM when a turbine trips or a valve fails
Credential management	Centralized Active Directory	Shared vendor accounts, local credentials on legacy systems, no AD integration for OT devices
Audit requirements	Access logging	Full session recording with video playback for compliance and forensic review

These differences explain why general-purpose VPN and ZTNA solutions designed for IT environments consistently fail when applied to OT vendor access scenarios.

Why VPNs Fail OT Vendor Access Security Requirements

Most organizations still grant OT vendor access through site-to-site VPNs or remote access VPN concentrators. This approach introduces five structural security weaknesses that cannot be resolved through VPN configuration changes.

Structural Weakness 1: Excessive Network Access

A VPN connection places the vendor’s device on the OT network segment. Once connected, the vendor can reach any system on that segment – not just the specific PLC or HMI they need to maintain. There is no application-layer access control limiting the vendor to a specific machine, protocol, or operation.

Structural Weakness 2: Inbound Port Exposure

VPN concentrators require inbound ports open on the firewall. These ports are discoverable by network scanning tools. Shodan and Censys index thousands of exposed VPN endpoints on industrial networks. Every open inbound port is an entry point that attackers can target with credential stuffing, vulnerability exploitation, or zero-day attacks.

Structural Weakness 3: Credential Reuse and Sharing

Vendor VPN accounts are frequently shared among multiple technicians within the vendor organization. Credentials are stored in ticket systems, sent via email, or kept in spreadsheets. When a vendor employee leaves, the credentials remain active. Dragos confirmed that in 2025, ransomware affiliates routinely purchased valid VPN credentials from infostealers and initial access brokers to authenticate legitimately into OT boundary networks.

Structural Weakness 4: No Session Visibility

A VPN connection is an encrypted tunnel. Once established, the organization has no visibility into what the vendor does inside the tunnel. There is no session recording, no command audit, no file transfer tracking. If the vendor’s device is compromised, the attacker operates inside the same tunnel with the same access.

Structural Weakness 5: Persistent Access

VPN access is typically always-on or activated with standing credentials. Vendors retain access between maintenance sessions. Access is rarely time-limited or automatically revoked after a specific task.

Organizations that have assessed their vendor access security posture consistently find these five weaknesses present – regardless of the VPN vendor or configuration.

What Does Secure Vendor Access to OT Systems Require?

Eliminating VPN-based vendor access requires an architecture that meets seven requirements simultaneously. No single point product addresses all seven. The requirements must be evaluated as a complete set.

Seven Requirements for Secure OT Vendor Access

#	Requirement	What It Means	Why It Matters
1	Zero inbound ports	No firewall ports open for incoming vendor connections	Eliminates the attack surface that scanning tools and credential attacks target
2	Application-level access	Vendor connects to a specific application (RDP to one HMI, SSH to one SCADA server) – not to a network segment	Prevents lateral movement even if vendor credentials are compromised
3	Identity verification per session	Every vendor access session requires individual authentication with MFA – no shared accounts	Creates accountability and prevents credential sharing across vendor technicians
4	Time-limited access	Access expires automatically after a defined window – no standing permissions	Eliminates persistent access that remains active between maintenance events
5	Session recording	Full video recording of RDP, SSH, and application sessions with searchable audit	Provides forensic evidence and compliance documentation for every vendor interaction
6	File transfer control	Any files transferred between the vendor and OT systems pass through CDR scanning and policy enforcement	Prevents malicious content from entering OT zones through vendor file uploads
7	Clientless access	Vendor connects through a browser portal – no agent or VPN client installation required	Eliminates dependency on vendor device management and accelerates emergency access

How Zero Trust Architecture Solves OT Vendor Access

Zero Trust architecture addresses all seven requirements through a fundamentally different connection model. Instead of creating a network tunnel that places the vendor on the OT network, Zero Trust creates an application-level connection that grants access only to the specific resource the vendor needs – after identity verification and policy evaluation.

The Reverse Access Model: Eliminating Inbound Ports

The most critical architectural difference is the elimination of inbound firewall ports. In a reverse access architecture, the access controller deployed inside the OT network initiates an outbound HTTPS connection (port 443) to an access gateway in the DMZ. The vendor connects to the gateway. The controller pulls the authenticated request inbound over the already-established outbound connection.

The result: zero inbound ports on the OT network firewall. The OT network is invisible to external scanning. There is no VPN endpoint to attack, no port to discover, and no service to exploit.

This model aligns with NIST SP 800-207 Zero Trust Architecture principles and NIST SP 800-82 Rev 3 recommendations for OT network access control.

How the Connection Flow Works

The vendor access flow in a Zero Trust reverse access architecture follows this sequence:

Step 1 – Vendor authenticates through a clientless browser portal. The vendor provides individual credentials (not shared) and completes MFA verification. Device posture is checked – OS version, patch status, endpoint protection.

Step 2 – Policy evaluation. The access controller evaluates the request against the vendor’s assigned policy: which specific application, which OT system, which time window, which operations are permitted. If the vendor is authorized to RDP to HMI-07 between 10:00–12:00 on Tuesday, only that specific connection is permitted.

Step 3 – Application-level connection. The controller creates a connection to the specific OT application (RDP, SSH, HTTP, or SMB) and routes the vendor session through it. The vendor interacts with the target system. They cannot see or reach any other system on the OT network.

Step 4 – Session recording and audit. The entire session is recorded – video for RDP, command log for SSH, file transfer log for SMB. The recording is stored with metadata (vendor identity, target system, timestamp, duration, operations performed).

Step 5 – Automatic termination. When the time window expires or the vendor disconnects, the session terminates. Access is removed. No standing credentials remain.

Organizations implementing Zero Trust supplier access eliminate the structural weaknesses of VPN by design, not by configuration.

Step-by-Step: Implementing Secure Vendor Access for OT

The following implementation guide covers the practical steps to deploy Zero Trust vendor access for OT environments. The sequence is designed for organizations transitioning from VPN-based vendor access.

Phase 1: Inventory and Classify Vendor Access (Week 1–2)

Before deploying any technology, document every vendor that currently accesses your OT environment.

For each vendor, record: vendor name, specific OT systems accessed (by hostname or IP), protocols used (RDP, SSH, SMB, HTTP, proprietary), frequency of access (daily, weekly, on-demand, emergency), current access method (VPN, jump server, direct), number of individual technicians, and current credential management method.

Classify vendors into three tiers based on the criticality of the systems they access:

Tier	Systems Accessed	Access Frequency	Migration Priority
Tier 1 – Critical	SCADA servers, DCS, safety systems, PLCs controlling physical processes	On-demand / emergency	First – highest risk, highest impact
Tier 2 – Important	Historian servers, HMI panels, engineering workstations, network infrastructure	Scheduled maintenance	Second – significant exposure
Tier 3 – Standard	IT systems in the OT DMZ, monitoring dashboards, reporting tools	Regular scheduled access	Third – lower risk, higher volume

Phase 2: Deploy Zero Trust Access Infrastructure (Week 3–4)

Deploy the access gateway in the DMZ and the access controller inside the OT network. The connection between them uses outbound HTTPS only – no inbound ports are opened.

Configure integration with the organization’s identity provider (Active Directory, Azure AD, or SAML/OIDC-compliant IdP) for vendor identity management. Create individual vendor accounts – one per technician, not per vendor organization.

Define access policies for each vendor-system combination: which vendor user can access which OT application, using which protocol, during which time window, with which MFA requirement.

Phase 3: Migrate Tier 1 Vendors (Week 5–6)

Begin migration with Tier 1 vendors (critical OT systems). For each vendor, configure the specific application access (RDP to the specific HMI, SSH to the specific SCADA server), enable session recording, set time-limited access windows, and enforce MFA per session.

Run both VPN and Zero Trust access in parallel during the transition period. Verify that the vendor can complete their maintenance tasks through the new access method before decommissioning the VPN connection.

Phase 4: Migrate Remaining Vendors and Decommission VPN (Week 7–10)

Migrate Tier 2 and Tier 3 vendors using the same process. After all vendors are migrated, close the inbound VPN ports on the OT firewall.

Verify closure by running an external scan (Shodan, Censys, Nmap) against your OT network perimeter. The scan should return zero discoverable services.

Phase 5: Operationalize and Enforce (Ongoing)

Establish processes for vendor onboarding (new vendor account creation with defined access policies), vendor offboarding (automatic account deactivation), emergency access (pre-defined break-glass procedures with multi-person authorization), and audit review (periodic review of session recordings and access logs).

Organizations that have replaced multiple OT security vendors with a single platform report significant reduction in operational complexity – fewer consoles, unified logging, and a single policy engine for all vendor access types.

How truePass Addresses OT Vendor Access Requirements

TerraZone’s truePass platform addresses all seven OT vendor access requirements through a single deployment.

The platform operates on three integrated layers that work together to provide complete vendor access control for OT environments.

Layer 1 – Reverse Access infrastructure. The patented Reverse Access technology eliminates all inbound firewall ports. The access gateway sits in the DMZ; the access controller sits inside the OT network. Communication uses outbound HTTPS (port 443, TLS 1.2/1.3) only. OT systems remain invisible to external scanning. This layer enforces the zero-inbound-port requirement at the architecture level – not through configuration rules that can be misconfigured.

Layer 2 – SMB Proxy with CDR integration. For vendor file transfers (firmware uploads, configuration backups, log downloads), the SMB Proxy mediates access to OT file shares. Kerberos/NTLM authentication, SMB Signing for message integrity, SMB Encryption for end-to-end traffic protection, and Content Disarm and Reconstruction scanning ensure that files crossing from vendor environments into OT zones are sanitized before reaching production systems.

Layer 3 – Zero Trust application access. Vendor RDP sessions to HMI and engineering workstations enforce per-session MFA, per-machine access policies, clipboard/printer/port redirection controls, and real-time session recording. Vendor SSH access to SCADA servers enforces the same identity-based controls. HTTP application access defines target URL, IP:port, and authorized users from Active Directory.

truePass provides third-party and vendor access controls that enforce time-limited, role-based permissions to specific OT applications without exposing the broader network.

Every vendor session generates a complete audit trail – Syslog export to any SIEM, full session recording with video playback for RDP and command log for SSH, and compliance reports that document who accessed what, when, for how long, and which operations were performed.

For organizations that also need to address employee and internal secure remote access to OT systems, the same truePass infrastructure handles both use cases through a single policy engine – eliminating the need for separate solutions.

Compliance Mapping: Vendor Access Controls to OT Security Standards

Secure vendor access to OT systems directly addresses requirements in four major OT security frameworks. The table below maps the seven vendor access requirements to specific standard clauses.

Requirement	NIST SP 800-82 Rev 3	IEC 62443	NERC CIP	TSA Security Directive
Zero inbound ports	§5.1 Network segmentation	FR1: Access control enforcement	CIP-005-7: Electronic security perimeters	SD-02D: Network segmentation
Application-level access	§6.2 Access control for ICS	SR 1.1: Human user identification	CIP-007-6: System security management	SD-02D: Access management
Identity verification per session	§5.3 Authentication mechanisms	SR 1.7: Strength of password authentication	CIP-004-7: Personnel and training	SD-02D: MFA for remote access
Time-limited access	§6.3 Least privilege enforcement	SR 2.1: Authorization enforcement	CIP-004-7: Access revocation	SD-02D: Access control
Session recording	§6.5 Audit and accountability	SR 6.1: Audit log accessibility	CIP-007-6: Security event monitoring	SD-02D: Logging and monitoring
File transfer control	§5.2 Data flow enforcement	SR 3.5: Input validation	CIP-010-4: Configuration management	SD-02D: Data integrity
Clientless access	§6.2 Remote access management	SR 1.13: Access via untrusted networks	CIP-005-7: Remote access management	SD-02D: Remote access

Frequently Asked Questions

What is secure vendor access to OT and why does it matter?

Secure vendor access to OT is an access control architecture that grants third-party vendors authenticated, time-limited, application-level access to specific OT systems – without placing the vendor on the OT network and without opening inbound firewall ports. It matters because vendor access is the primary attack vector into OT environments: Claroty found that 82% of verified OT intrusions used internet-facing remote access as the initial entry point, and Dragos confirmed that ransomware affiliates routinely use stolen VPN credentials to enter OT boundary networks.

Can vendors still access OT systems in emergencies without VPN?

Yes. A Zero Trust architecture supports emergency access through pre-defined break-glass procedures. Emergency roles can be activated with multi-person authorization, granting the vendor immediate access to the specific OT system requiring urgent maintenance. Every second of the emergency session is automatically recorded and flagged for mandatory post-incident review. Emergency access is actually faster than VPN provisioning because the vendor authenticates through a browser portal – no client installation, no VPN tunnel negotiation, no network configuration on the vendor’s device.

Does Zero Trust vendor access work with legacy OT systems that cannot run agents?

Yes. The architecture is agentless on the OT endpoint side. The access controller mediates the connection between the vendor and the OT system using standard protocols (RDP, SSH, HTTP, SMB). The OT endpoint does not need any software installed. This is specifically designed for environments where PLCs, HMIs, and RTUs cannot support agent installation due to resource constraints, vendor certification requirements, or operational risk.

How does this approach handle vendors who need to transfer files to OT systems?

File transfers are mediated through the SMB Proxy layer, which enforces authentication, SMB Signing, SMB Encryption, file type restrictions, and optional CDR scanning. The vendor uploads files through a controlled channel that applies policy enforcement before the file reaches the OT storage. The same audit trail records file name, size, type, source, destination, and sanitization result.

What happens when a vendor contract ends?

Vendor accounts are deprovisioned through the same identity management system. Access is revoked immediately. Because there are no standing VPN credentials, no local accounts on OT systems, and no persistent tunnels, there is nothing for a former vendor to use after deprovisioning. Time-limited access policies ensure that even if deprovisioning is delayed, vendor access has already expired.

Conclusion

Vendor access to OT systems is a necessary operational requirement. The security risk comes not from the access itself, but from the architecture used to deliver it. VPN-based vendor access introduces structural weaknesses – inbound port exposure, excessive network access, shared credentials, no session visibility, and persistent connections – that attackers systematically exploit.

Zero Trust architecture eliminates these weaknesses by replacing network-level tunnels with application-level connections, enforcing identity verification per session, limiting access to specific systems and time windows, recording every interaction, and eliminating inbound ports entirely through reverse access technology.

The implementation path is straightforward: inventory vendor access, deploy Zero Trust access infrastructure, migrate vendors by tier, decommission VPN, and operationalize ongoing vendor lifecycle management.

Organizations operating critical infrastructure – energy, water, manufacturing, transportation, oil and gas – cannot afford vendor access to remain the weakest link in their OT security architecture. The technology exists. The migration path is proven. The question is how quickly your organization moves from VPN-based vendor access to Zero Trust.