Securing Remote PLC Access Beyond the VPN

A virtual private network can protect traffic between a remote engineer and a plant network. It does not, by itself, make remote PLC access safe. A secure design must also control who connects, which assets they can reach, what changes they may make, when access is allowed, and how the plant can recover if a session fails.

This distinction matters because an encrypted tunnel can carry both legitimate maintenance traffic and harmful commands. The engineering objective is therefore not “install a VPN.” It is to create a controlled remote-maintenance path with several independent safeguards.

Start With the Operational Use Case

Define the work before selecting technology. Remote troubleshooting, viewing trends, uploading a program, changing firmware, and commanding equipment are different risk classes. Each needs its own approval, access scope, and recovery plan.

For many plants, the safest default is read-only observation. A technician can inspect alarms, controller status, and historian data without gaining a route for program changes. Write access should be opened only for an approved task and closed when the work ends.

Document the target assets, expected protocols, support organization, working hours, and person authorized to stop the session. This gives network and control teams a shared basis for firewall rules and operating procedures.

Place a Broker Between the Internet and the Cell

A remote laptop should not connect directly to a controller subnet. Terminate the VPN in a managed boundary zone, then require the user to pass through a hardened jump host or remote-access gateway. The gateway becomes the point for authentication, authorization, recording, malware controls, and session termination.

Segment the path so the remote user can reach only the devices required for the job. A vendor servicing one packaging line should not inherit access to every PLC, HMI, drive, and engineering workstation in the site. Use explicit allow rules for source, destination, service, and time window. Deny lateral movement by default.

The plant's communication and networking components should support the segmentation and diagnostic visibility required by the design. Product capability still needs to be checked against the site's architecture, firmware policy, and environmental requirements.

Treat Identity as a Separate Control

Shared vendor accounts make investigations difficult and weaken accountability. Give each person a named identity. Require multifactor authentication for remote entry, and avoid factors that depend on the same compromised device whenever practical.

Authorization should be role-based and temporary. A user may be permitted to open the engineering workstation but not alter firewall rules. Another may view an HMI but not download a PLC project. Privileged access should expire automatically after the approved maintenance window.

Remove dormant accounts promptly. Review vendor access after contract changes, personnel changes, and major outages. A technically sound gateway can still become a persistent back door if identity lifecycle work is neglected.

Protect the Engineering Workstation

The jump host is part of the control system. Maintain an approved software baseline, application allowlisting where feasible, endpoint protection compatible with the engineering tools, and controlled removable-media handling. Do not use it for email or general web browsing.

Keep project files under version control or another governed backup process. Before a change, record the current controller program, firmware, communication configuration, and known-good restore procedure. Confirm that the offline project matches the running controller. A secure connection does not prevent an engineer from downloading the wrong revision.

Where screen sharing is sufficient, keep programming software and project files inside the plant boundary. This reduces the need to transfer sensitive control files to unmanaged endpoints.

Separate Maintenance From Machine Operation

Remote access must not bypass local safety responsibilities. A VPN is not a safety channel, and internet latency is not suitable evidence for a protective function. Local personnel should establish the equipment state, apply required energy-control procedures, and confirm the affected area before remote changes begin.

Use a written handoff: identify the machine, place it in the agreed mode, confirm permissives, announce the test, and define who can authorize motion. For changes that could cause movement or alter interlocks, require a competent person at the machine with an independent means to stop the test.

Do not expose safety controllers or safety configuration tools merely because standard PLC maintenance is needed. Give safety-related work a separate, stricter workflow.

Log Enough to Reconstruct the Session

Collect gateway authentication events, session start and end times, source information, destinations, configuration changes, and relevant controller or engineering-workstation logs. Synchronize clocks so events can be correlated.

Logs are useful only if someone reviews them. Alert on repeated failed logins, access outside approved windows, new destinations, unusual data transfer, and attempts to use prohibited services. Retain records according to the plant's incident-response and regulatory needs.

Design for Failure and Revocation

Test what happens if the internet link drops during an upload, a remote desktop session freezes, or the support engineer loses power. Controller logic and local supervision should leave the process in a defined state. Avoid designs that require a continuous remote connection to maintain safe operation.

Provide a fast way for plant staff to revoke access without disrupting unrelated control traffic. This may be a gateway disable function, firewall rule, account action, or physical network isolation point. Verify the method during commissioning rather than waiting for an incident.

Back up the gateway configuration and document how to rebuild it. Include remote access in disaster-recovery exercises and in management-of-change reviews.

A Practical Commissioning Checklist

• Confirm the approved task, target assets, time window, and responsible local person.
• Verify named accounts, multifactor authentication, and least-privilege roles.
• Test that prohibited subnets, ports, and devices are unreachable.
• Confirm the jump host baseline and the current PLC project backup.
• Exercise session recording, alerts, timeout, and emergency revocation.
• Simulate connection loss and verify the process remains in a defined state.
• Close temporary permissions and review logs after the work.

Use Guidance as an Architecture Baseline

NIST SP 800-82 Revision 3 provides current guidance for operational technology security, including architectures, remote access, risk management, and controls adapted to operational constraints. Use it as a framework, then apply the site's process hazards, vendor requirements, and applicable regulations.

For related design practices, the PLC ProTech Knowledge library covers industrial networking, commissioning, diagnostics, and control-system maintenance.

Bottom Line

A VPN is one layer in a remote-access system. The stronger design combines encrypted transport with a brokered path, named identities, least privilege, segmentation, governed engineering tools, local operational control, logging, and rehearsed recovery. When those layers are verified together, remote PLC maintenance becomes a controlled engineering activity rather than an open-ended network connection.