Why remote access is high risk
Almost every plant eventually needs an integrator or equipment maker to connect during a fault. The usual shortcuts are the dangerous part: a permanent VPN account, a shared password, a vendor laptop plugged straight into the control network, a remote-support tool left running. Each one creates a path that nobody monitors and that outlives the job it was set up for.
Principles
- No inbound path from the internet to the control network. Remote users connect to a controlled entry point in a DMZ, not to the devices.
- Named identity and multifactor authentication for every person. No shared accounts.
- Least privilege: the session reaches only the target device and only the protocol the job needs, for example one port on one controller.
- Time limits: access is approved for a window and expires automatically.
- Recording: sessions are logged, ideally with screen recording stored where the user cannot alter it.
- Approval: someone on the plant side authorizes each session.
A common architecture
The vendor connects to a broker or privileged-access service in the DMZ. After authentication it opens a session on a hardened jump host, and the jump host is allowed to reach only the approved target through firewall rules. The vendor never receives a routable path into the OT network, and a split-tunnel VPN that bridges the vendor’s laptop and the plant is avoided.
A session, step by step
- The vendor requests access, stating the device, the task and the time needed.
- The plant owner approves it and the window is enabled.
- The vendor connects through the entry point with multifactor authentication.
- The work is carried out and recorded; changes are noted.
- Access is disabled at the end of the window, or automatically on expiry.
- Someone reviews the recording and updates the configuration backup.
The vendor remote access session checklist turns these steps into a one-page procedure you can hand to the vendor.
Legacy devices
Older PLCs and HMIs cannot authenticate users strongly or encrypt their protocols, so the protection has to wrap around them. Keep engineering ports reachable only from the jump host or an engineering workstation, prefer read-only or monitor access when the task allows, and take a fresh backup before anyone changes a program.
Plan for emergencies
A fault at night will tempt people to bypass the process. Write a break-glass procedure that is quick but still logged, with a named approver and a mandatory review afterwards, so the exception does not become the habit.
Check it works
Test revocation, not only access: confirm that an expired session really cannot reconnect. Review accounts and recordings regularly, and treat any remote tool you did not install as a finding. This sits within the wider approach of zero trust for OT and the zone-and-conduit model in IEC 62443.