ICS and SCADA security: what makes it different

ICS and SCADA systems control physical processes. They run production lines, power grids, water treatment plants, oil and gas pipelines, and the building systems that keep a hospital operating. ICS is the umbrella term for industrial control systems. SCADA, supervisory control and data acquisition, is the type of ICS used to monitor and command equipment spread across a wide area from a central room. Underneath sit programmable logic controllers (PLCs), remote terminal units (RTUs), human-machine interfaces (HMIs), and sensors that read pressure, flow, and temperature and turn those readings into commands that open a valve or trip a breaker. These are the systems that move water, generate electricity, and keep a factory running.

An attack on them does not stay digital. A breach of a corporate file server leaks data. A breach of a control system can open a valve, stop a pump, overheat a process, or disable a safety interlock. The consequences are physical, they can endanger people, and they cannot be undone by restoring a backup. That is why securing ICS and SCADA differs from conventional IT security in a fundamental way, not just in degree. This guide explains what these systems are, why operational technology (OT) security follows different rules, the main threats, and the concrete steps to raise the security of a plant without stopping it. For the wider picture, start with our overview of operational technology and OT security.¹

What ICS and SCADA are, and where they run

An industrial control system is the layer of software and hardware that senses a physical condition and acts on it. A sensor reports that a tank is full, a PLC compares that to a setpoint, and the controller closes an inlet valve. SCADA adds a supervisory layer on top: it gathers data from many controllers across a large site or region, presents it to operators on HMI screens, and lets them issue commands. A water utility uses SCADA to watch dozens of pumping stations from one control room.

These systems sit underneath the services people depend on. In energy they run generation, transmission, and distribution. In water they run treatment, pumping, and distribution. In manufacturing they run assembly lines, robotic cells, and process control for chemicals and pharmaceuticals. They also run transport signaling and the plant inside large buildings. Many of these sectors are exactly the ones regulators class as essential, so their security is now a legal obligation, not only an engineering preference.

Why OT security differs fundamentally from IT

In conventional IT, the usual priority order is confidentiality first, then integrity, then availability. Protect the data, keep it accurate, and keep the service up. In OT the order is reversed. Availability and human safety come first, integrity of the process second, and confidentiality last. A system that controls a turbine cannot simply be switched off for an update during a shift. A wrong or delayed command does not corrupt a record, it can injure a person or break expensive equipment. That single change in priorities reshapes the entire approach to protection.¹

Three properties of OT make this harder. First, the systems live for decades, so a controller installed twenty years ago may still run a line today on an operating system the vendor stopped supporting long ago. Second, many industrial protocols, such as Modbus and DNP3, were designed for isolated, trusted networks, so they carry no authentication and no encryption and any device that can reach a controller is trusted to command it. Third, patching is rare and risky, because an update often means stopping production and an untested patch can destabilize a fragile process, so fixes are deferred far longer than any IT team would tolerate.

The practical consequence is that controls which are routine in an office can be harmful in a plant. Forcing a password reset mid-shift, rebooting a server to patch it, or quarantining a device that turns out to be a live controller can each interrupt a running process. Even testing is dangerous, because aggressive vulnerability scanning that is harmless to a web server can flood a fragile protocol and knock a PLC offline. The same action that counts as good hygiene in IT can be an outage, or worse, in OT.

The main threats to ICS and SCADA

The most common way an OT environment is harmed is not a targeted industrial attack at all. It is ordinary ransomware that starts on the IT side, in email or a corporate server, and spreads into OT because the two networks are connected without a real boundary. The attacker may never touch a controller. Operators still lose the SCADA servers, HMIs, and historian they rely on, so they shut the process down to stay safe. This IT-to-OT spillover is the dominant cause of industrial outages from cyber incidents, which makes segmentation the single highest-value control a plant can put in place.

Beyond spillover, four threats deserve specific attention. Targeted process attacks aim at the physical logic itself, changing setpoints or controller code to damage equipment or defeat a safety system, the category behind the most serious real-world OT incidents. Insiders, whether malicious or careless, already have access to systems that trust whoever can reach them. Unmanaged remote access is the most common entry point, where a maintenance VPN or a vendor's support tool reaches deep into the OT network with weak authentication. And the convergence of IT and OT is itself a threat, because every connection added for business reporting removes another layer of the isolation that once protected these systems by default.²

The Purdue model and network segmentation

Segmentation is the foundation of OT security, and the reference model for it is the Purdue model. It organizes an industrial environment into layers, from the physical process at the bottom up to enterprise IT at the top. Level 0 is the field devices, sensors and actuators. Level 1 is the controllers, the PLCs and RTUs. Level 2 is supervisory control, the SCADA servers and HMIs. Level 3 is site operations and the historian. A demilitarized zone (DMZ) sits between the plant and the business network, and Levels 4 and 5 are the corporate IT and enterprise systems above it.

The point of the model is that traffic should not jump straight from the corporate network into the controllers. Each boundary is a place to inspect, restrict, and monitor what crosses it. The OT DMZ is the critical layer: business systems that need production data talk to a server in the DMZ, and that server, not a user's laptop, is the only thing that talks down into the plant. IEC 62443 expresses the same idea in its vocabulary of zones and conduits. Either way, a foothold in one place must not become free movement everywhere.

Secure remote access and network monitoring

Remote access to OT is unavoidable. Vendors must support equipment they sold, and engineers must reach a site without driving to it. It is also the most abused path in, because the easy way to set it up, a flat VPN or an always-on support agent with a shared password, gives an outsider a direct route to the controllers. The fix is not to forbid remote access but to make every session deliberate, identified, and watched: access brokered through a hardened jump host in the DMZ, multi-factor authentication for every user, individual accounts instead of shared vendor logins, and access granted only for the duration of a task and disabled afterward.

Because OT systems cannot easily be hardened or patched, visibility becomes the compensating control. You cannot protect what you cannot see, and most plants start with an incomplete picture of what is even connected. The first job is an accurate asset inventory: every controller, HMI, and engineering workstation, with its firmware version and normal communication pattern. That inventory is the baseline everything else measures against.

Monitoring itself is built to be passive. Instead of probing devices, which risks crashing them, it taps a copy of the traffic and analyzes it out of band. Industrial traffic is highly repetitive, so deviations stand out clearly. A new device appearing, an engineering command from an unexpected host, or a controller suddenly reaching toward the internet are all strong signals. Feeding them into a monitored threat detection and response capability turns passive visibility into early warning, the difference between catching an intrusion in reconnaissance and discovering it after the process stops.

In IT you patch the system. In OT you cannot, so you build a wall around it and watch the gate.

IEC 62443, the standard for industrial security

The specialized framework for this work is IEC 62443, the leading international series of standards for the cybersecurity of industrial automation and control systems. Where general standards assume systems can be patched on a schedule and taken offline now and then, IEC 62443 starts from OT reality: equipment that lives for decades, downtime that is unacceptable, and safety that comes first. It is a series organized by audience, with parts for asset owners who run the security program, integrators who design the system, and manufacturers who build security into the devices.³

Two concepts carry most of the weight. Zones and conduits are the industrial form of segmentation described above. Security levels, written SL, express how strong the protection of a zone needs to be, from resistance to casual misuse up to resistance against a well-resourced, deliberate attacker, set in proportion to the risk of each zone. IEC 62443 does not replace ISO 27001; it complements it for the industrial part of the picture, and it is the most practical way to translate a broad legal obligation into concrete OT measures.

NIS2 obligations for essential entities

For many industrial and infrastructure operators, OT security is now a legal duty. The NIS2 Directive (EU) 2022/2555 covers sectors including energy, water, wastewater, manufacturing of critical products, and transport, and it classes the larger operators in those sectors as essential entities. NIS2 requires risk-based security measures, and it does not exempt the OT side of the business. Industrial control systems fall squarely within the scope of the risk management obligations.²

In practice NIS2 asks essential entities to manage risk across their networks and information systems, handle incidents, maintain business continuity, and report significant incidents to the national authority within tight deadlines. Management is accountable for these measures, not just the IT department. IEC 62443 is the natural way to meet the OT portion, because it already speaks in the zones, conduits, and security levels an industrial environment needs. For who is in scope and what is required, see our guide to NIS2 and the difference between NIS2 and DORA.

Steps to raise OT security

Because the systems themselves cannot easily be changed, security is built around them. The aim is to reduce what an attacker can reach and what they can do once inside, without touching the process that has to keep running. The following sequence works as a repeating program, not a one-off project.

1. 01
   Build an asset inventory

   Identify every device on the OT network, its firmware, and its normal communication. Most plants find devices they did not know were connected.
2. 02
   Segment the network

   Separate OT from corporate IT and the internet using the Purdue model and an OT DMZ, so an incident on the IT side cannot spread to the plant floor.
3. 03
   Control remote access

   Broker every session through a hardened jump host, require multi-factor authentication and individual accounts, and grant access only for the duration of a task.
4. 04
   Monitor passively

   Tap network traffic out of band, baseline normal behavior, and alert on deviations, feeding signals into threat detection and response.
5. 05
   Plan patching

   Apply updates in scheduled maintenance windows, with testing first, using compensating controls until a fix is safe to apply.
6. 06
   Prepare an OT response plan

   Adapt an incident response plan to physical consequences, with a clear path to safe shutdown and recovery.

How Raptoric helps

We assess OT environments with an understanding of the process, not with the instincts of an office network. Through offensive security we test ICS and SCADA carefully, working passively or in read-only modes where the equipment is fragile and validating any active step against its impact on production and safety. Through threat detection and response we help you build the monitoring and remote-access oversight that compensate for systems you cannot patch. The result is a plant that is harder to reach and easier to watch, without stopping the process. Book a scoping call.