Vendor remote access to SCADA and OT systems: rules and controls

Reference article · 5 min read

Most utilities and public works departments depend on outside integrators to keep control systems running. The firm that built the SCADA system writes the PLC logic, patches the historian, and answers the phone when a lift station alarms at two in the morning. To make that work, agencies issue a VPN account and leave it on. The account often outlives the project, the technician it was created for, and sometimes the vendor relationship itself.

That standing tunnel is the shortest path from a compromised vendor laptop to a pump station, a chemical feed controller, or a traffic cabinet. It is always on, so a stolen credential is useful at any hour. It is usually shared under the firm's name, so nobody can say which person changed a setpoint. It is rarely recorded, so the account of what happened is whatever the vendor writes in a service ticket. The fix is not to cut vendors off. It is to change the shape of the access: from a connection that is always available to a session that is requested, approved, time-boxed, recorded, and closed.

Broker the session, do not extend the network

A support VPN lands the vendor on a network segment and lets them reach anything routable from there: engineering workstations, the historian, HMI servers, and often the controllers behind them. Replace it with supervised access to one device for one window, through a broker that sits between the vendor and the control network.

• The vendor authenticates to the broker as a named individual with phishing-resistant multifactor.
• The broker connects to the named target using credentials the vendor never holds. Vendor-supplied passwords on controllers and HMI accounts get retired and vaulted.
• The session is time-boxed and closes on its own. Renewal requires a new request.
• The session is recorded, and the recording is retained under your records schedule.
• File transfer, clipboard, and drive mapping are off by default, enabled per session when a firmware image or project file has to move.

This pattern runs through operational technology security guidance, including NIST publications on OT security and the IEC 62443 series. Specifics change between revisions, so confirm the current text before citing it in policy.

Require approval at the console

The person who knows whether it is safe to touch a backwash sequence right now is the operator on shift, not the IT help desk.

• A request names the technician, the target asset, the work order, and the expected duration.
• An operator or supervisor approves from the control room before the session opens. Nothing opens on a schedule alone.
• The approval is logged with the approver's identity and kept with the recording.
• The operator can end the session at any point without calling anyone.

Decide in advance which assets need a second approval or may never be touched remotely. Many agencies draw that line at anything that moves the physical process: chemical feed, valve and gate actuation, breaker operations, and firmware loads.

Keep the OT path off the corporate path

Vendor access to SCADA should not ride the same infrastructure as vendor access to billing. If the corporate identity provider is compromised, the OT path should not fall with it.

• Use a separate identity store, or at minimum separate accounts and multifactor enrollments for OT.
• Place the broker in its own zone, deny by default in both directions, with no route from a vendor session into the corporate network.
• Do not allow vendor cellular modems, cloud-managed gateways, or manufacturer support tunnels unless they terminate at your broker. Packaged skids often arrive configured to phone home.
• Inventory those paths first. The common discovery in an OT assessment is a remote access method nobody in IT knew about.

What to specify in the maintenance agreement

Contract language keeps the control in place after the integrator changes staff.

• Named individuals. Each technician is identified, screened per your policy, and removed promptly when they leave the account.
• No shared or embedded credentials. The vendor does not store, reuse, or embed agency credentials in its tools or documentation.
• Agency-owned access method. All remote work uses the agency broker. Vendor VPNs and third-party support tools require written approval.
• Recording and audit. The agency may record sessions and audit vendor activity.
• Notification. The vendor reports a compromise of its support environment or technician devices within a defined period, not only when agency data is confirmed exposed.
• Endpoint terms. State whether the vendor may use its own laptop or must work from an agency-issued virtual desktop.
• Flow-down. The same terms reach subcontractors and manufacturers doing warranty support, often the unmanaged path.

Have counsel review the terms and check sector obligations. Public power entities with bulk electric system assets face remote access requirements under the NERC CIP standards, and community water systems have federal risk assessment and planning duties. Applicability varies and changes, so verify with the regulator or counsel.

Emergency access without a standing back door

Emergency need is why most standing accounts exist. Design the break-glass path on purpose instead.

1. Keep a written procedure naming who can authorize emergency access, including after hours.
2. Store break-glass credentials in a vault that requires check-out and alerts on use.
3. Apply the same recording and time-box to emergency sessions. Speed comes from skipping paperwork, not from skipping the log.
4. Review every emergency use at the next operations meeting. Frequent use means the normal path is too slow.

How to start

Pull every external account with a path to the control network, match each one to a current contract and a named person with operations in the room, and close what does not match. Then run a brokered pilot with one vendor at one facility and fix the friction before expanding.

HQT works with state and local agencies on cybersecurity and systems engineering for operational environments, including remote access architecture and vendor access terms in service agreements.

Frequently asked questions