Remote access that does not become a permanent open door
Almost every remote access arrangement was set up quickly during an outage and never revisited.
Vendors and integrators need occasional access to control systems they support, and the alternative — flying an engineer to site for every issue — is slow and expensive. Remote access is a legitimate operational requirement.
The problem is how it is usually established: at three in the morning during a failure, by whoever can make it work, with the intention of tidying it up afterwards.
The characteristics of a controlled arrangement
- Access is initiated and enabled by the site, not by the remote party.
- It is enabled for a session and disabled afterwards, rather than standing open.
- It terminates at a jump host in the intermediate zone, never directly at a control system.
- Individual named accounts, never shared vendor credentials.
- Multi-factor authentication.
- The session is logged, and ideally recorded.
- Someone on site knows the session is happening and what is being done.
- A written agreement covering what the vendor may access and what they may change.
The difference between a controlled arrangement and an uncontrolled one is who decides when the door is open.
Activity records on support workstations can complement access logs when accountability requirements are clear. Further details are available in the linked article.
Security decisions should also be checked against NIST guidance on operational technology security.
The supervised session model
The strongest practical control is that remote sessions are supervised: a site engineer is present, watching, for the duration.
This is sometimes impractical for long diagnostic sessions and it is achievable for anything involving changes. It also has a side benefit that is easy to underrate — the site engineer learns how the vendor diagnoses the problem, which reduces the need for the next session.
Recording what was done
A remote session that changes configuration is a change, and should be recorded as one: what was altered, by whom, when, and why.
The common failure is that vendor changes bypass the site's change process entirely, because the vendor is not part of it. The result is a system whose configuration history has gaps corresponding to every support call.
Making the site engineer responsible for raising the change record, based on what they observed during the supervised session, closes that gap.
Standing connections
Some arrangements involve permanent connectivity: a vendor monitoring platform, a cloud-connected asset management service, a maintenance system with a continuous link.
These carry different considerations from session-based access. The questions worth answering explicitly are what data leaves the site, whether the connection is capable of writing as well as reading, what happens if the remote end is compromised, and whether the link can be severed quickly if needed.
The last is worth testing rather than assuming. An arrangement that cannot be disconnected without vendor cooperation is not under site control.
Auditing what exists now
Most sites do not know how many remote access paths into their control environment currently exist.
An audit — reviewing firewall rules, VPN accounts, cellular modems on field equipment, vendor-supplied appliances, and any remote desktop tools installed on engineering workstations — reliably finds more than expected.
Cellular modems on skid-mounted equipment are the recurring surprise: a vendor-supplied package arrives with its own connectivity, and nobody in the control systems group knew it was there.
Contracts and expectations
Vendor support contracts frequently assume remote access without specifying its terms, which means the arrangement is negotiated informally at the moment of need.
Establishing it in the contract — the method, the controls, the notification requirement, the logging — is far easier before the support relationship begins than during a failure.
Emergency access
The controls above are designed for planned sessions. There will be occasions when access is needed immediately and the normal route is unavailable.
A defined emergency procedure — who can authorise, what the fallback method is, what must be recorded afterwards, and a mandatory review — is what prevents the emergency from becoming the standing arrangement.
Without one, the first genuine emergency produces an improvised connection that remains in place for years.
Deciding what a vendor may change
Access controls determine who can connect. A separate question, frequently unaddressed, is what they may do once connected.
Read-only diagnostic access is a different proposition from the ability to modify configuration, and many support tasks require only the first. Where the platform supports differentiated permissions, granting the minimum required for the task in hand is straightforward and rarely done.
Time-limited enablement in practice
The principle that access is enabled per session requires a mechanism that makes enabling and disabling easy, or the practical outcome will be that it is enabled once and left.
Approaches that work include a physical key switch, a firewall rule enabled by a request process with automatic expiry, and a jump host that is powered on for the session. The common property is that the default state is closed and returning to it requires no action.
After the session
Closing a support session should include verifying that the access is disabled, recording what was done, raising any change records, and confirming that the system is in the expected state.
A short checklist covering those four items prevents the common situation where a session ends when the problem is resolved and nothing else is completed.
Recording the business justification
Each remote access path should have a documented reason for existing, a named sponsor and a review date.
Paths without those accumulate, and the periodic review has no basis for removing anything because nobody can say whether it is still needed.
An annual review that removes access no longer justified is straightforward when the justification was recorded and impossible when it was not.
Third parties beyond the control vendor
Remote access reviews typically consider the control system vendor and overlook the others: the analyser supplier, the drive manufacturer, the fire and gas system provider, the metering contractor.
Each may have its own arrangement, established separately, sometimes with its own connectivity hardware.
A complete inventory has to cover every party with any access to any system on or connected to the control network, which is usually a longer list than the control systems group expects.