Remote Access Architecture for Industrial Environments

The pandemic permanently changed expectations around remote access to industrial environments. What was once reserved for emergency situations - vendor support connecting to a PLC, engineers accessing SCADA systems from home - has become routine operational practice. This shift creates significant security challenges. Traditional remote access approaches, particularly network-level VPNs that grant broad access once authenticated, create unacceptable risk for environments where compromise can have physical consequences. Yet the operational benefits of remote access are real: faster incident response, access to specialist expertise regardless of location, and more efficient operations across geographically distributed sites. The challenge is implementing remote access architecture that enables these benefits while maintaining security appropriate for critical infrastructure.

The Problem with Traditional VPN

Traditional site-to-site or client-to-site VPNs authenticate users and then provide network-level access to the destination environment. Once connected, users can reach any system their network credentials permit, often with minimal logging of their activities. This approach has several problems for OT environments. Network-level access is too broad - a vendor supporting a specific system gains access to the entire network segment. Authentication happens once at connection time, with no continuous validation that the session remains legitimate. Credentials can be stolen or sessions hijacked without detection. VPN concentrators themselves become high-value targets; compromising the VPN infrastructure grants access to everything behind it. The Colonial Pipeline incident, while not purely a VPN compromise, illustrated how remote access vulnerabilities can cascade into operational impacts. Attackers leveraged compromised credentials to access the IT environment, and the company shut down operations because they could not be confident the OT environment was not also compromised. This scenario - loss of confidence leading to operational shutdown - represents a significant risk that traditional VPN architectures do not adequately address.

Jump Server Architecture

Jump servers (also called bastion hosts) provide an intermediate access point that mediates connections between external users and internal systems. Rather than connecting directly to target systems, users connect to a jump server in the DMZ and then initiate sessions to specific systems from there. This architecture provides several security benefits: connections terminate at a controlled point, all sessions can be logged and recorded, and users never have direct network access to OT systems. A well-designed jump server architecture implements session recording that captures all user activity, provides evidence for incident investigation, and deters malicious behaviour. Access to specific systems is controlled through application-level permissions rather than network-level connectivity. Sessions can be time-limited and require explicit approval. The jump server itself should be hardened, regularly patched, and monitored for signs of compromise. For OT environments, jump servers should be positioned in the Level 3.5 DMZ, providing access to Level 3 systems without enabling direct connectivity to lower levels. Engineers requiring access to Level 2 systems should connect through additional jump infrastructure within the OT network, maintaining defence in depth.

Zero Trust Network Access Approaches

Zero Trust Network Access (ZTNA) extends jump server concepts with more sophisticated access control and continuous session validation. Rather than authenticating once at connection time, ZTNA solutions continuously evaluate session risk based on user identity, device posture, location, and behaviour patterns. Access is granted to specific applications rather than network segments. ZTNA solutions typically use outbound connections from protected environments, eliminating the need for inbound firewall rules and reducing attack surface. The access broker validates each request against policy before establishing connectivity, ensuring that users only reach resources they are explicitly authorised to access. For OT environments, ZTNA offers compelling benefits but also implementation challenges. Many OT applications use protocols that ZTNA solutions may not natively support. The continuous evaluation that makes ZTNA powerful requires agents or proxies that may not be deployable on legacy OT systems. Organisations implementing ZTNA for OT access should carefully evaluate vendor capabilities against their specific application and protocol requirements.

Managing Vendor Access

Vendor access deserves particular attention because vendors often have privileged access to critical systems but are outside the organisation's direct control. Vendor personnel change, vendor security practices vary, and vendors typically support multiple customers, making them attractive targets for attackers seeking access to many organisations. Best practices for vendor access include requiring vendors to use organisation-provided remote access infrastructure rather than their own tools, implementing time-limited access that requires explicit approval for each session, recording all vendor sessions for later review, and restricting vendor access to specific systems rather than broad network segments. Contractual provisions should require vendors to notify the organisation of security incidents that might affect their access credentials or systems. Regular access reviews should verify that vendor access remains necessary and appropriate. For high-risk systems, consider requiring vendor personnel to be escorted virtually by internal staff during sessions.