OT Security Fundamentals — OT & Industrial Control Systems

TL;DR

In operational technology (OT), safety and availability come first and confidentiality last, so security controls must never put the physical process at risk.
Many OT systems run for decades, cannot be rebooted at will, and only run in configurations the vendor has certified, so "just patch it" is often not possible.
Most industrial protocols have no authentication: any device that can reach a controller can usually command it, which makes network design the first line of defense.
Defense in depth for OT combines segmentation, allow-listing, hardening, passive monitoring, backups of controller programs, physical security, and trained people with clear procedures.
Safety and security depend on each other: a security incident can become a safety incident, and a careless security measure can disable a safety function.

Why OT security is different

In a water treatment plant, a pump fills a tank. A sensor measures the level, a programmable logic controller (PLC) decides when to stop the pump, and an operator watches the whole process on a screen. If that PLC receives a wrong command, the result is not a leaked spreadsheet but an overflowing tank, a damaged pump or an unsafe chemical dose. That is the core of OT security: protecting the systems that monitor and control physical processes so that the process stays safe, available and correct. The building blocks are explained in Industrial Control Systems; this page is about defending them.

Other priorities: AIC instead of CIA

Office IT is usually described with the CIA triad: confidentiality, integrity and availability, roughly in that order of concern. OT practitioners often turn it around to AIC, and put safety above all three. A recipe or a setpoint is rarely secret; what matters is that the process keeps running (availability) and that every value and command is correct (integrity). NIST Special Publication (SP) 800-82 Rev. 3, a US government guide to OT security, says OT security has to address OT's "unique performance, reliability, and safety requirements" (as of 2026 Rev. 3 is final; a Rev. 4 draft was published in September 2026).

Aspect	Typical office IT	Typical OT
Top priority	Confidentiality of data	Safety of people and plant, then availability and integrity
Consequence of failure	Data loss, downtime, cost	Physical damage, injury, environmental harm, outages for many customers
Lifetime of a system	3–5 years	Often 15–20 years or more
Reboots and patches	Monthly, often automatic	Only in planned maintenance windows, sometimes once a year or less
Configuration changes	Owner decides	Often must stay within what the vendor has tested and certified
Timing	A delay of a second is an annoyance	A delay of milliseconds can trip a protection function or stop a machine

No reboot windows, vendor-certified configurations

A control server that runs a continuous process — a refinery, a substation, a furnace — cannot be restarted on a Tuesday afternoon because an update is waiting. Planned outages are scheduled months ahead, sometimes once a year. On top of that, many industrial vendors support their system only in a certified configuration: a specific operating system version, a specific set of patches, sometimes even a specific antivirus product. Installing an untested patch can void that support, or in rare cases stop the control software. Patching in OT is therefore a planned engineering activity, covered in Patching and Vulnerability Management in OT.

Insecure by design

Most industrial protocols were designed in the 1970s to 1990s for closed serial networks where every device was trusted. Classic Modbus, for example, has no field for a user name, password or signature: a controller executes any well-formed request from any device that can reach it. This is called insecure by design: the system works exactly as specified, and the specification simply has no security. There is no bug to patch. Secure variants exist (Modbus/TCP Security, DNP3 Secure Authentication, the IEC 62351 series, OPC UA with signing and encryption), but they are far from universal. See Industrial Protocols.

The practical consequence: in OT, who can reach a device over the network largely decides who can control it. That is why segmentation and strict firewall rules matter so much more here than in an office network.

Physical consequences

An attack on OT can open a breaker, overfill a tank or disable an alarm. Even a well-meant action can do damage: an aggressive network scan has been known to knock old controllers offline. Every security activity in OT is therefore judged by one question first: could this affect the process or safety?

Legacy systems

A legacy system is a system that is still in service but is based on technology that is outdated or no longer supported by its vendor. In OT these are everywhere, for good reasons: a control system is part of a physical installation that was engineered, tested and certified as a whole, and replacing it means stopping production and re-qualifying the plant.

Unsupported Windows: human-machine interfaces (HMIs) and engineering stations on Windows versions that no longer receive security updates, because the control software was never qualified for a newer version.
Embedded devices: PLCs, remote terminal units (RTUs) and protection relays with a real-time operating system and firmware that is rarely updated, little memory, and no room for security agents.
Old protocols and serial links: equipment that only speaks a serial protocol, connected to Ethernet through serial-to-Ethernet converters that themselves have to be managed.

You cannot make a legacy system modern, but you can surround it: isolate it in its own zone, allow only the traffic it needs, remove what it does not need (USB ports, unused services), monitor it, and plan its replacement. These are compensating controls; the end-of-life planning side is covered in Patching and Vulnerability Management in OT.

The OT attack surface

The attack surface of an OT environment is every way in. Incidents rarely start at a PLC; they usually start in IT, at the edge, or with a person, and move toward the process.

The IT/OT boundary: every connection between the office network and the control network — a historian that business users query, a file transfer, a shared Active Directory, a forgotten dual-homed computer with one network card in each network. The boundary itself is explained in What Is Operational Technology?
Remote access: vendor support connections, engineers working from home, remote-desktop tools installed "temporarily". Remote access has been the way in for several of the incidents in Threats and Notable Incidents; see Remote Access and Third Parties.
Internet exposure: HMIs, PLCs and routers reachable directly from the internet, often with default passwords. Removing these connections is the first of CISA's (the US Cybersecurity and Infrastructure Security Agency's) primary mitigations for OT (May 2025).
Removable media and transient devices: USB sticks and contractor laptops that move between networks. See removable media in Endpoint Security.
Supply chain: firmware, software updates, project files and the vendors' own networks. See supply chain attacks.
Engineering workstations: the computers that hold the programming software and project files for controllers. Whoever controls an engineering workstation can usually change controller logic, which makes it one of the most valuable targets in OT. It is described in The Purdue Model and OT Architecture.

Defense in depth for OT

Defense in depth — several independent layers of protection, so one failure does not lead to compromise — is the guiding principle of OT security. Because single layers in OT are often weak (no authentication, old operating systems), the layers around them carry the weight. The ISA/IEC 62443 series turns this into a structured approach with zones, conduits and security levels; see IEC 62443.

Segmentation

Divide the network into zones by function and criticality, and control every path between them. The basics are in Network Security Basics and Network Security in Depth. In OT this means at least: no direct traffic between the office network and the control network, an industrial demilitarized zone (DMZ) in between for shared services, and further separation inside OT (for example, the safety system separate from the basic control system). Industrial firewalls can inspect industrial protocols and allow, for example, only Modbus read requests.

# Illustrative, vendor-neutral rule set. A monitoring HMI in the
# control room may only READ values from one pump-station PLC.
# Documentation addresses (RFC 5737).

object hmi-monitor-01   host 192.0.2.21        # zone Supervisory
object plc-pumps-01     host 198.51.100.10     # zone Control
object ews-01           host 192.0.2.40        # engineering workstation

# Rule  Action  Source          Destination    Service    Protocol check
10      allow   hmi-monitor-01  plc-pumps-01   tcp/502    modbus function-code 1,2,3,4  unit-id 1   log
20      deny    hmi-monitor-01  plc-pumps-01   tcp/502    modbus any-other-function-code            log alert
30      deny    any             plc-pumps-01   any        -                                         log alert
40      deny    any             any            any        -                                         log

# Function codes 1-4 are Modbus reads: coils, discrete inputs,
# holding registers, input registers. Everything else is denied.
# Programming access from ews-01 is NOT allowed through this rule
# set; it goes through a separate, normally disabled rule that is
# enabled only for an approved change.

Note the last rule: deny by default, and log what is denied. Denied traffic toward a PLC is a strong signal that something is misconfigured or wrong. An HMI that operators use to control the process needs more than reads; industrial firewalls can then restrict which devices and which addresses may be changed, which is designed together with the process engineers.

Allow-listing

OT systems do the same thing every day, which makes "allow only what is known" practical. On hosts, application allowlisting lets only approved programs run on an HMI or engineering station — often more realistic than antivirus signatures on a system that cannot be updated often. On the network, the same idea is a firewall policy that lists exact source, destination, port and function code, as above.

Hardening

Hardening removes what is not needed: unused services and accounts, web interfaces on PLCs that nobody uses, USB ports, default passwords (CISA's second primary mitigation). Do it within the vendor's guidance — many vendors publish hardening guides for their control systems — and test on a non-production system first. Many PLCs also have a physical mode key or switch; keeping it in the RUN position, so the program cannot be changed remotely, is a simple and effective control where the hardware supports it.

Monitoring

Because so much in OT cannot be patched or hardened, detection carries extra weight. OT monitoring is mostly passive: a copy of the traffic is analyzed, and nothing is sent to the devices. Because OT traffic is so regular, a new connection, a new function code or a firmware download stands out. See Asset Inventory and Monitoring and, for the security operations side, Security Monitoring and the SOC.

Backups of programs and configurations

Recovering an OT system means more than restoring servers. Keep known-good copies of PLC programs, controller and relay configurations, HMI projects, firewall and switch configurations, and the installation media and license files for the engineering software. Store them offline as well, record which version is running where, and periodically compare the running program with the stored one: an unexpected difference is either an undocumented change or a compromise. General backup principles are in Backup and Recovery; version-controlled network configurations are discussed in Network Automation with Git.

Physical security

Substations, pump stations and field cabinets are often unmanned and spread over a large area. Someone with access to a cabinet can plug into a switch or turn a key. Locks, alarms on cabinet doors, camera coverage and visitor procedures are part of OT security; see Physical Security.

People and procedures

Most controls depend on people: operators who notice that something is off, engineers who follow the change process (see Change Enablement), vendors who use the approved remote-access path. Train OT staff in security and IT staff in OT, practice running the process manually, and agree in advance who may decide to disconnect a network. Clear ownership — who is responsible for the security of each system — avoids the classic gap where IT thinks OT owns it, and OT thinks IT does.

The safety-security interplay

Safety protects people and the environment from the plant; security protects the plant from people with bad intentions or careless actions. The safety-security interplay is the way the two influence each other, in both directions:

Security failures can cause safety hazards. A safety instrumented system that is reachable from the network can be manipulated or disabled; the Triton malware (2017) targeted exactly such a system. Safety engineering traditionally assumes random failures, not an intelligent adversary.
Security measures can create safety hazards. An account lockout on an operator station during an emergency, an antivirus scan that slows down an HMI, or a firewall that blocks an alarm message can all prevent operators from acting in time.
Safety requirements constrain security. Emergency stop buttons must work without logging in; some changes need a safety re-assessment before they can be made.

In practice this means safety and security engineers review designs and changes together, and that security risk assessments include "could this lead to a safety hazard?" as a question. IEC TR 63069:2019 is a technical report on applying the functional safety standard IEC 61508 and IEC 62443 together. The safety side is covered in Safety and Reliability.

Prioritizing findings with OT context

A vulnerability score such as CVSS (Common Vulnerability Scoring System) describes how bad a vulnerability is in general. In OT, its place in the architecture matters more: a medium vulnerability on an HMI that is reachable from the internet is more urgent than a critical one on a spare laptop that never connects to anything. The sketch below adds two pieces of OT context — where the asset can be reached from, and whether exploiting it could affect safety — to rank four hypothetical findings.

# Rank vulnerability findings with OT context, not by CVSS alone.
# The weights are illustrative: agree on your own with operations and safety.
EXPOSURE = {"internet": 2.0, "it-network": 1.5, "ot-only": 1.0, "isolated": 0.5}

findings = [
    {"id": "F1", "asset": "Engineering laptop (spare)", "cvss": 9.8,
     "reachable_from": "isolated", "safety_impact": False},
    {"id": "F2", "asset": "Pump station HMI", "cvss": 6.5,
     "reachable_from": "internet", "safety_impact": False},
    {"id": "F3", "asset": "Historian server", "cvss": 8.1,
     "reachable_from": "it-network", "safety_impact": False},
    {"id": "F4", "asset": "Boiler PLC", "cvss": 7.5,
     "reachable_from": "ot-only", "safety_impact": True},
]


def priority(finding):
    score = finding["cvss"] * EXPOSURE[finding["reachable_from"]]
    if finding["safety_impact"]:
        score *= 1.5
    return round(score, 1)


ranked = sorted(findings, key=priority, reverse=True)
print(f"{'ID':<4}{'Asset':<28}{'CVSS':>5}{'Priority':>10}")
for f in ranked:
    print(f"{f['id']:<4}{f['asset']:<28}{f['cvss']:>5}{priority(f):>10}")

ID  Asset                        CVSS  Priority
F2  Pump station HMI              6.5      13.0
F3  Historian server              8.1      12.1
F4  Boiler PLC                    7.5      11.2
F1  Engineering laptop (spare)    9.8       4.9

The internet-facing HMI comes first, even though its CVSS score is the lowest: the fix (removing the internet exposure) is also cheap and does not touch the process. The highest CVSS score ends last because nothing can reach that laptop. Real programs use richer inputs — whether an exploit is known to be used in the wild, whether a compensating control is in place, the consequence for the process — but the principle is the same. Note that the ranking only says what to look at first; how and when to fix it is still decided with the asset's owners.

Common mistakes

Trusting the air gap. Many "isolated" networks turn out to have a remote-access connection, a dual-homed server or a regular USB transfer. Verify isolation with an inventory of every connection instead of assuming it.
Treating OT as someone else's problem. IT security teams sometimes exclude OT from scope because it is fragile, and OT teams sometimes see security as an IT concern. The incidents that hurt most often started in IT.
Security that blocks the operator. Lockouts, session time-outs and forced logoffs on operator stations can stop operators at the worst moment. Design access control together with operations.
No offline backups of controller programs. Without a known-good copy, you can neither detect a modified program nor recover from one.