SCADA security. The complete guide.
What it is, what actually reaches control systems, how to secure SCADA without patching or downtime, which standards apply, and what changes by sector.
Last updated:
SCADA security: the complete guide, as a 38-page PDF.
Written for the people who keep water, power, pipelines and plants running without an OT security team behind them. Every chapter opens with a two-sentence answer you can quote in a meeting; the last page is a fifteen-question checklist to take to your next operations meeting.
What is inside
What SCADA is and why it is different, the six paths that reach controllers with the public case behind each, six controls that touch no controller, the four ways sites control access today, standards as evidence, a chapter per sector, and a plan for your first year.
See it on one site
One appliance per site, plugged into the existing network, with the first flow under control in a day. Bring the checklist; we will walk it with you.
SCADA security is the set of controls that keep a supervisory control and data acquisition system, the HMIs, historians, RTUs and PLCs that run a plant, a grid or a water system, doing only what its operators intend. It is different from IT security in three ways: the equipment cannot be patched or rebooted on a schedule, the protocols it speaks carry no authentication, and the cost of a wrong action is physical. The practical answer is to control what reaches the controllers rather than to change the controllers: know every device, put a checkpoint in front of each one, give every person a named session, and keep a record. That can be done in hours with one on-premise appliance, without touching the SCADA itself.
Three things make it different from IT security.
A SCADA system is the supervisory layer of an industrial process: an HMI where the operator watches and acts, a historian that stores the values, and a fleet of RTUs and PLCs in the field that read sensors and drive pumps, valves and breakers. It is usually spread over distance, a plant and its lift stations, a pipeline and its compressor stations, a grid and its substations, which is why it has more remote connections than any other layer of the plant.
It cannot be patched on a schedule. A controller that runs a process is changed during a planned outage, sometimes once a year, sometimes never. Vulnerabilities stay open for the life of the device. Its protocols carry no authentication. Modbus, DNP3, and most of what the field speaks will execute any well-formed command from any source on the network. And a wrong action is physical. A setpoint changed on a water plant is not data loss; it is chemical dosing.
So SCADA security cannot be endpoint security with different logos. The equipment will not run an agent and will not take an update. What it can accept is a network in front of it that decides who and what gets through. Every control in this guide is that idea applied to one problem.
Reach, not sophistication.
The published incidents share a shape: someone reached the control network through a path nobody controlled, and the protocols did the rest. The threat is how far one credential travels, not how clever the attacker is. Six paths, in the order they usually turn up in an assessment.
Remote access on a flat network
A shared VPN credential, an integrator's laptop, a cellular modem on a panel. Once inside, the user can reach every PLC on the segment. This is the entry point in most published water and manufacturing incidents.
Controllers that cannot be patched
A PLC or HMI on the CISA Known Exploited Vulnerabilities list will not be rebooted this quarter. The vulnerability stays; the only variable is who can reach the device.
Protocols with no authentication
Modbus, DNP3 and most industrial protocols execute any well-formed command from any source. Anything on the network can write to the process.
Exposed HMIs and engineering stations
Windows machines that cannot run an agent, reachable from the office network or, in the worst cases, from the internet. They are the path from a phishing email to a setpoint.
Vendors and integrators
The people who reach the SCADA most often are not employees, have no account in the directory, and connect from far away. Their access is the least controlled and the most needed.
No record of what was done
When something changes, the question is who, when and from where. Most SCADA networks cannot answer it, so every incident becomes a forensic project.
For the vulnerabilities themselves, the ones CISA publishes weekly with an ICSA identifier, and the five triage questions that beat the CVSS score, see SCADA and ICS vulnerabilities: the advisories, decoded.
Six controls, in this order, without touching a controller.
Each one is a compensating control in the IEC 62443 and NIST 800-82 sense: the device cannot meet the requirement itself, so the network in front of it does. Each one goes in one flow at a time, with no outage window.
- 01
Know every device
An inventory built from the traffic itself, not from a spreadsheet: every PLC, RTU, HMI and historian, what it talks to and on which protocol. Legacy devices included, since nothing is installed on them.
Asset inventory - 02
Put a checkpoint in front of each controller
Segment the SCADA network by asset rather than by cable: a proxy in the path decides what reaches each device. No VLAN redesign, no re-addressing, no outage window.
OT network segmentation without rewiring - 03
Broker every remote session
Operators and vendors connect to the gate, not to the network. A named login, one asset, one task, the whole session recorded. The VPN into the control segment goes away.
Vendor remote access to OT without a VPN - 04
Put MFA in front of what cannot do MFA
The controller cannot ask for a second factor. The gate in front of it can, for every human session, on equipment that installs nothing.
- 05
Filter the protocol, not only the port
Allow reads and deny writes, per function code, per register, per user. A vendor can look at a sensor without being able to command the actuator next to it.
Securing Modbus - 06
Keep the record on site
Every session, every command, on the appliance and in your SIEM. It is the evidence an auditor asks for and the answer to the question every incident starts with.
From nothing to a checkpoint per controller.
| Approach | What it protects | What it needs | What it misses |
|---|---|---|---|
| Do nothing (flat network) | Nothing | Nothing | Everything; one credential reaches every controller |
| VPN plus perimeter firewall | The perimeter | VPN clients, firewall rules, a change window | Anyone inside the tunnel; no per-asset control, no session record |
| Monitoring platform | Visibility and alerts | Sensors per segment, a platform, integrations for enforcement | Enforcement itself: the alert fires after the write |
| In-path proxy (Access Gate) | Each controller, each session | One appliance per site, plugged into the existing switch | Deep threat research; pair it with a monitoring platform if you have one |
Five regimes, one set of controls.
They ask for the same things in different words: know your assets, control and log access, keep third parties on a short leash, and be able to prove it. The six controls above produce that evidence as a by-product.
IEC 62443
The industrial standard. Zones and conduits, security levels, and the requirement that access between zones is controlled and logged. Segmentation by asset is the direct implementation.
IEC 62443 zones and conduitsNIST SP 800-82
The US guide to OT security. Its architecture chapter is the Purdue model with a DMZ; its controls map to inventory, access control, and monitoring.
The Purdue modelNERC CIP
Electric utilities. CIP-005 requires an intermediate system for interactive remote access; CIP-003-9 covers vendor remote access at low-impact sites; CIP-015 adds internal network monitoring.
NERC CIP complianceEPA, AWIA and state water rules
Water and wastewater. AWIA risk and resilience assessments cover electronic control systems; New York's DEC and DOH rules add specific access-control and reporting duties from January 2027.
Water and wastewaterNIS2
EU essential and important entities. Article 21 requires access control, supply-chain security and incident handling; SCADA access by third parties sits squarely inside it.
NIS2 for OTSame controls, different sites.
Water and wastewater
Small systems, no OT security staff, remote lift stations, on-call operators and integrators dialling in. The pattern that works is one appliance at the plant and a brokered path for every remote session.
SCADA security for water systemsOil and gas
Distributed SCADA across pipelines, compressor stations and wellheads, reached over links you do not own. The control is at each site, not in a central firewall.
SCADA security for oil and gas pipelinesElectric
Substations, control centres and the NERC CIP obligations that come with them. The intermediate system for remote access is the same gate.
NERC CIPManufacturing
CNC machines, PLCs and HMIs on the shop floor, vendors who need in weekly, and a production line that does not stop for a change window.
ManufacturingStill SCADA, or DCS, or just PLCs? The hierarchy, and what changes for security at each layer, is in PLC vs SCADA vs DCS and ICS vs SCADA security.
SCADA security, answered.
SCADA security is the set of controls that keep a supervisory control and data acquisition system, its HMIs, historians, RTUs and PLCs, doing only what its operators intend. Because the equipment cannot be patched on a schedule and its protocols carry no authentication, the practical form of SCADA security is controlling what reaches the controllers: an inventory, a checkpoint in front of each device, a named and recorded session for every person, and a record kept on site.
Remote access onto a flat network. A shared VPN credential, a vendor's laptop or a cellular modem gives one user reach to every controller on the segment, and the protocols behind it execute any command. Most published water and manufacturing incidents started there, not with a sophisticated exploit.
By controlling the path to the device rather than the device. Put an appliance in front of the SCADA network, steer each flow through it one at a time, and let it decide who reaches which controller, with which protocol commands, and record the session. The PLC and HMI install nothing and are never rebooted. This is the compensating control that IEC 62443 and NIST 800-82 both accept for equipment that cannot meet a requirement as written.
ICS is the broad term for industrial control systems: SCADA, DCS, PLCs and safety systems together. SCADA is the supervisory layer, usually spread over a wide area, that collects data and sends commands to the field. SCADA security is therefore ICS security applied to the layer with the most remote connections and the least physical control over the endpoints.
Yes, in almost every water system, pipeline, grid and plant. The equipment is often ten to thirty years old, which is exactly why it cannot be secured by patching and has to be secured by controlling access to it.
Six, in order: build a live inventory from the traffic; segment by asset with a checkpoint in front of each controller; broker every remote session through a gate instead of a VPN; put MFA in front of devices that cannot do it themselves; filter industrial protocols by command, not only by port; and keep a record of every session on site. Do them in that order, one flow at a time, with no outage window.
The gate is the first service you run, not the last.
Secure OT, zero disruption, and a base to build on.
Access Gate puts compute on the wire, next to your assets. Once the gate is in, the same box hosts the services that pull OT in securely: remote access, protocol gateways, DNS and time, historian, update server. No second appliance, no cloud.