Summary
SCADA remote access covers at least four different needs, and most of the risk comes from giving all four the same access.
The on-call operator needs to see alarms and sometimes act on them. The SCADA vendor needs the server for a maintenance window. The engineer needs to reach one remote station. The manager needs a dashboard. Separate monitoring from control and operators from vendors, and give each person only what they need. Most people then need no path into the control network.
Who needs remote access to SCADA
Write the list before you choose a tool. At a typical water or electric utility, the list looks like this.
| Who | What they need | How often | Monitoring or control |
|---|---|---|---|
| On-call operator | Alarms, trends, sometimes acknowledge or start a pump | Every night and weekend | Both, mostly monitoring |
| Control engineer | Change logic or setpoints at one station | A few times a month | Control |
| SCADA software vendor | The SCADA server, for patching and support | A maintenance window | Control of one server |
| Integrator | The station they are commissioning | Project weeks | Control of a few devices |
| Manager, regulator reporting | Dashboards and reports | Daily | Monitoring only |
The list shows two things. Most people on it only need to see data. Each person who needs to change something needs a very small part of the system.
The difference between monitoring and control
Monitoring means values, trends and alarms. Control means anything that writes to the field or to the SCADA configuration: a setpoint, a pump start, an alarm acknowledgement or a new tag.
Monitoring and control carry very different risk. Monitoring can often be delivered with no path into the control network. The SCADA network pushes data out to a historian or reporting server outside it, and people read the data there. A manager's dashboard, a regulator report or a morning check of reservoir levels does not need a session on the SCADA server.
Control needs a path, so keep that path small. It should reach only the system that writes to the field, only for the person doing the work, only while they do it, and it should be recorded.
Sometimes monitoring needs the live SCADA client, for example when an on-call operator views the HMI screens. In that case, make the session view-only on the access path instead of relying on a role inside the application. For a web-based client, you can allow reads and block writes at the protocol level. The result depends on how the application uses HTTP, so test it with the real client before you rely on it.
How to handle operators and vendors
Operators are your staff. They are in your directory and do recurring work. The risk is an access path that is too broad or too easy to reuse: an always-on remote desktop to the SCADA workstation, a shared password, or a VPN that reaches every station. The 2021 compromise of a Florida water treatment plant involved remote access to the SCADA system, poor password security and an operating system out of support. Plant personnel noticed the increase in sodium hydroxide dosing and corrected it.
Vendors and integrators are not in your directory. They work occasionally and often use their own laptops and tools. The risk is access that stays open after the job and a path that reaches much more than the system they maintain. Give them a session that opens for the maintenance window, reaches one server or one station, and closes automatically.
Vendors also need an identity. You can keep them out of your corporate directory: Access Gate connects several directories at once. Your staff sign in with Active Directory or Entra ID. Vendors sign in with a second Active Directory or with the directory built into Access Gate. MFA is enforced at the gate for both groups.
Small utilities often have this case. The SCADA software vendor supports the system through a remote support tool installed on the SCADA server years ago. Nobody on staff knows when it runs or who has the password. Treat that tool as an open path until you confirm otherwise. Find the tool, find out who at the vendor can use it, and replace it with a recorded session to that server only, which you open when the vendor calls. The vendor works as before. You decide when the session happens and you can see what was done.
The same rule applies to integrators after a project. Close the VPN account created for commissioning a new pump station when the project ends.
Remote sites: lift stations, wells and substations
Lift stations, wells, reservoirs, substations, well pads and compressor stations report to the control room over telemetry. They usually use DNP3 or IEC 60870-5-104, often over cellular. This traffic is SCADA working as designed. Keep it as it is: the master polls the RTU, and nothing else talks to the RTU.
Problems start when the cellular modem at the site becomes a remote access path of its own. An integrator may ask for a management interface or a port forward reachable from the internet so they can reach the RTU directly. People should reach remote sites through the control centre, on a path you control, and not through the modem. We cover the telemetry protocols in securing DNP3.
What CISA recommends for SCADA remote access
CISA, FBI, EPA and DOE published a fact sheet of primary mitigations for OT in May 2025. Three of the five mitigations concern remote access directly: remove OT connections to the public internet, change default passwords, and secure remote access to OT networks. Where remote access is essential, the fact sheet recommends a private connection with a VPN, a strong password and phishing-resistant MFA, disabling dormant accounts, and least privilege for the specific asset and user role.
Most utilities have not yet applied the last recommendation. A VPN checks who is connecting. Least privilege per asset and role limits what they can reach once connected. You need both.
Access rules for each type of user
Apply these rules to each person on your list:
- Monitoring only: the user reads data outside the control network, or uses a view-only session. The user has no write path.
- Operator control: the user signs in with a named login and MFA and gets a recorded session to the SCADA client or the station they are responsible for.
- Vendor or integrator: the user signs in with a named login and MFA and gets a recorded session to the one server or station they maintain. The session opens for the maintenance window and closes automatically.
Trout Access Gate applies these rules from an on-premise appliance in front of the SCADA network. It keeps your VPN or 4G link and adds micro-segmentation of the LAN and a bastion. Users sign in through the browser against your identity provider. Each session goes through the gate to one authorised asset over one authorised protocol, and the user gets no IP address on your network. Access Gate inspects HTTP, SSH, RDP, VNC, Modbus TCP and OPC UA at the application layer, so you can, for example, allow HTTP GET and deny POST. Sessions have a time limit, and they are recorded and can be replayed. You can require a vendor to accept an access agreement before the session starts, and the acceptance is logged. Nothing runs in a cloud, so remote access does not depend on an external service.
The same rules apply to the panels and controllers: see secure remote access to an HMI and secure remote access to a PLC. For SCADA protection in general, see the SCADA security guide.
Five steps to take this week
- Write the list. Include every person and company with remote access to SCADA today, how they connect, and whether they need to see or to change things.
- Find the internet exposure. Look for remote desktop tools on SCADA workstations, cellular modems with open management interfaces, and port forwards. Remove them.
- Move monitoring off the control network wherever a copy of the data is enough.
- Limit vendor access to maintenance windows. Remove standing vendor accounts. Access opens for the job and closes after it.
- Disable dormant accounts and make sure every remaining account belongs to a named person with MFA.