SSL-VPN vs. Zero Trust: Safer Remote Vendor Access for Industrial Systems

SSL-VPN: Flexible network access that depends on policy

An SSL-VPN, typically implemented with modern TLS encryption, creates an encrypted session between a remote user and a network gateway. After authentication, the gateway and surrounding network controls determine which routes, addresses, and services are available.

This model can fit industrial tools that expect direct IP connectivity. For example, engineering software may need to communicate with a controller through specific TCP or UDP ports and supporting services. A properly configured VPN can provide that path without changing the engineering application.

Broad access is not an inherent requirement of SSL-VPN technology. It is a configuration and architecture problem. A compromised vendor laptop or stolen credential can inherit only the permissions that the environment grants, whether those permissions are broad or narrowly scoped.

ZTNA: Resource access instead of implicit network trust

ZTNA is designed to grant access to specifically authorized resources rather than provide general network connectivity simply because a user authenticated. Policies may consider identity, authentication strength, device condition, assigned role, destination, and other context.

A contractor who needs one SCADA web interface may be allowed to reach that application without gaining the ability to scan the automation subnet or communicate directly with unrelated controllers. This reduces opportunities for lateral movement if an account or endpoint is compromised.

Industrial networks change the comparison

Many business applications fit identity-based, application-level access well. Industrial automation can be more complicated. PLCs, motor controllers, analyzers, and older communication devices may not support individual identities, multifactor authentication, device posture checks, or granular authorization.

Engineering tools can also rely on multiple ports, discovery services, or communication paths that must be tested across security boundaries. A ZTNA design that works well for a browser-based SCADA interface may not support a PLC programming workflow without additional architecture.

Use an engineering workstation as a controlled access point

A practical pattern is to connect the remote vendor to a designated engineering workstation or jump host rather than expose controllers directly. The workstation contains approved programming software, drivers, and configuration tools, and its network permissions are limited to the equipment required for the task.

This concentrates software management, monitoring, backups, and maintenance procedures around a known access point. It can also separate permission to reach the workstation from permission to reach the controller network.

A jump host is not automatically secure. If it has unrestricted access to every controller and server, compromising it may still expose the full environment. Use individual accounts, appropriate authentication, controlled sessions, and firewall rules that limit the workstation to required destinations. Where practical, keep vendor access disabled until an approved support window begins.

SSL-VPN and ZTNA: Compare real configurations

Modern VPN platforms can apply many Zero Trust principles. Some ZTNA products can provide broader network-level access for applications that require it. Compare the actual access path and enforced policies, not the labels.

Restrict remote access by purpose

These sessions can also need different authorization for viewing information, changing configuration, or performing work that could interrupt operations. The objective is not simply to identify who connected. It is to control what the connection permits.

MFA matters, but it is not enough

Multifactor authentication helps prevent a stolen password from being sufficient for remote entry. It does not correct excessive permissions, protect an already authenticated endpoint, or replace segmentation.

Plan for failure and emergency support

A facility should understand what happens when the internet connection fails, the VPN or ZTNA gateway is unavailable, an identity provider cannot be reached, a vendor cannot establish a session, or a security incident requires remote access to be disabled.

Local personnel should retain appropriate onsite operating and maintenance procedures. For critical systems, define how authorized emergency support will work when the normal remote-access path is unavailable. An alternate path must remain secured and controlled instead of becoming an unmonitored backdoor.

Monitoring and accountability belong in the design

Facilities should be able to determine who connected, when the session occurred, which resources were accessed, and when the session ended. Where supported and appropriate, session recording can add accountability.

Connection logs do not always show what changed inside a PLC or SCADA application. A complete maintenance record may also require controller program comparisons, configuration backups, application change logs, work notes, and verification after the session. Remote work should follow the same operational discipline as onsite maintenance.

Choose the architecture the facility can operate

A smaller municipal facility with a limited vendor group may be well served by a tightly configured SSL-VPN, MFA, a dedicated engineering workstation, and restrictive firewall policy. A larger organization with many vendors and facilities may benefit from centralized ZTNA policy and granular identity-based controls. A hybrid design can also be appropriate.

Primary guidance and further reading