A patch that a Windows admin would apply without a second thought can take down a chemical process, over-pressurize a pipeline, or stop a heart-lung machine mid-surgery if it lands on the wrong system. In IT, downtime is a business cost. In OT — operational technology, the systems that run physical processes — downtime and unsafe states can mean physical harm. That single distinction is why every instinct a good IT security professional has can be actively dangerous when pointed at a PLC.

TL;DR

  • OT (Operational Technology) security protects the systems that control physical processes — PLCs, RTUs, SCADA, DCS — where availability and safety outrank confidentiality, the exact opposite priority order from most IT security thinking.
  • The Purdue Model is still the reference architecture for ICS network segmentation, dividing plant-floor systems (OT) from business systems (IT) into hierarchical zones — but IT/OT convergence has eroded the air gap the model originally assumed.
  • This isn’t hypothetical: CISA highlighted a December 2025 Polish energy-sector OT incident where attackers reached systems through vulnerable internet-facing edge devices, deployed wiper malware, and damaged remote terminal units.
  • You cannot patch, scan, or reboot an OT system the way you would an IT system — many run 15+ year old software on hardware with no redundancy, where an unplanned restart is itself the incident.
  • IEC 62443 is the practical standard for OT security controls: zones, conduits, and security levels (SL 1–4) scaled to the actual threat a given system faces, not a blanket policy borrowed from IT.

Why This Matters to You

If you work in security at any organization that manufactures something, generates or distributes power or water, or runs physical logistics, IT and OT security are converging whether you planned for it or not — driven by predictive maintenance, remote monitoring, and cloud analytics that all want a data pipeline running straight from the plant floor to the cloud. Treating that connection with IT-style assumptions is exactly the gap recent attackers have been walking through.

Table of Contents

IT vs. OT: Why the Priorities Invert

IT security is generally taught around the CIA triad in order: Confidentiality first, then Integrity, then Availability. A breached database is bad regardless of whether anything was disrupted. OT security runs the same triad in reverse: Availability and safety first, because a process that stops unexpectedly can be a bigger incident than one where data leaked.

This inversion explains behavior that looks alarming from an IT lens but is standard OT practice:

  • Systems go years without patching, not from negligence but because a patch that hasn’t been validated against the exact process it controls can itself cause an unsafe state — and validation on production physical equipment is slow and expensive by design.
  • Active vulnerability scanning is often avoided entirely on live OT networks, because scan traffic has crashed fragile embedded devices that were never built to handle unexpected packets, turning a security assessment into the outage it was meant to prevent.
  • Legacy protocols with no authentication (Modbus, DNP3 in older deployments) remain common, because the devices speaking them were installed with 20–30 year expected service lives and replacing them means replacing physical plant equipment, not just software.

None of this means OT security is behind IT security out of laziness — it means the risk calculus is different, and importing IT assumptions wholesale is how well-intentioned security programs cause the exact incident they were trying to prevent.

The Purdue Model

The Purdue Enterprise Reference Architecture (commonly just “the Purdue Model”) is still the most widely used reference for structuring ICS networks, organizing systems into hierarchical levels:

Level 5 — Enterprise IT (corporate network, email, ERP)
Level 4 — Business/IT systems (site business planning)
   ─── DMZ (the critical boundary) ───
Level 3 — Site operations (production scheduling, historians)
Level 2 — Supervisory control (SCADA/HMI systems)
Level 1 — Basic control (PLCs, RTUs, controllers)
Level 0 — The physical process (sensors, actuators, valves)

The core idea: traffic between IT (levels 4–5) and OT (levels 0–3) should pass through a tightly controlled DMZ, never directly, and systems within OT should only talk to adjacent levels rather than everything talking to everything. This is exactly the architecture the Polish energy sector wiper attack exploited in reverse — the attackers gained initial access through vulnerable internet-facing edge devices, meaning devices that should never have had direct internet exposure at all were reachable from outside the intended boundary.

The model’s limitation, acknowledged by its own maintainers with the newer “Purdue 2.0” revision, is that it assumed a mostly air-gapped OT environment — an assumption that Industry 4.0’s push toward predictive maintenance, remote monitoring, and cloud analytics has substantially eroded. The model still describes the right segmentation; increasingly, real deployments don’t follow it as strictly as they claim to.

Real 2026 Incidents

This isn’t theoretical risk modeling — recent incidents illustrate the current threat reality:

Poland’s energy sector (December 2025). CISA, amplifying CERT Polska’s incident report, said malicious actors compromised OT/ICS systems in Poland’s energy sector, including renewable energy plants, a combined heat and power plant, and a manufacturing-sector company. The initial access path was vulnerable internet-facing edge devices. The follow-on activity included wiper malware, damage to remote terminal units (RTUs), destroyed HMI data, corrupted OT device firmware, and loss of view and control between facilities and distribution system operators.

Internet-facing PLC tampering reports. Public reporting has continued to describe attackers targeting exposed industrial controllers and engineering workflows rather than breaking through a perfectly segmented OT network. Treat those reports as a practical warning: if a controller, engineering workstation, HMI, or remote-access appliance is reachable from the internet, the Purdue diagram is already fiction.

Mexican municipal water utility (December 2025–February 2026). Investigators identified a compromise where an enterprise IT breach escalated into an attempted — and ultimately unsuccessful — OT environment intrusion at a Monterrey-area water and drainage utility: the attacker’s automated password-spray attempt against the OT-adjacent vNode SCADA interface failed entirely, and Dragos found no evidence the OT environment was ever breached. What makes the case notable regardless of that failed outcome is that the attacker used Claude as the primary technical driver — planning the intrusion, building tools, and independently identifying the SCADA platform as a high-value target during routine network reconnaissance — with GPT handling data processing, a preview of how AI-assisted tooling is starting to show up on the OT side of incidents, not just IT.

The common thread: internet-facing exposure of equipment that was never meant to be reachable from outside, not sophisticated zero-day exploitation.

Why You Can’t Patch Your Way Out

The IT instinct — “patch it, or at least isolate it until you can” — runs into real constraints in OT environments:

  • Vendor validation requirements. Many OT vendors require formal re-certification of a patched system before it can run in production, sometimes taking months, because a controller’s behavior is often certified as part of a larger safety system, not evaluated in isolation.
  • No maintenance windows for continuous processes. A chemical plant, power generation facility, or water treatment system often can’t simply “reboot after hours” — the process runs continuously, and an unplanned stop can itself be the safety incident.
  • Hardware with no failover. Unlike a redundant web server pool, a single PLC controlling a specific physical valve may have no live redundancy at all — taking it offline to patch, even briefly, can mean the physical process it controls has no controller.

The practical response isn’t “don’t patch OT” — it’s compensating controls: network segmentation that limits what an unpatched device can be reached by or communicate with, so the vulnerability’s exploitability is reduced even when the vulnerability itself can’t be immediately fixed.

IEC 62443: The Practical Standard

IEC 62443 is the closest thing OT security has to a practical, implementable standard, built around two core concepts:

  • Zones and conduits. Group assets with similar security requirements into a zone, and explicitly define and control the “conduits” — communication pathways — between zones, rather than assuming implicit trust between anything on the same physical network.
  • Security Levels (SL 1–4). Scale the required protection to the actual threat a zone faces — SL 1 for casual/coincidental exposure, up to SL 4 for a zone that needs to withstand a sophisticated, well-resourced (nation-state-capable) adversary — rather than applying a single blanket security posture to systems with wildly different actual risk.

As of 2026, IEC 62443 guidance has extended to explicitly cover Industrial IoT devices and cloud-based analytics platforms that interact with field-level equipment, acknowledging that a 2026 OT risk assessment can no longer stop at a static network diagram — it needs to account for every cloud and remote-access pathway that’s been added since the original architecture was designed.

MITRE ATT&CK for ICS

MITRE maintains a separate ATT&CK matrix specifically for ICS, distinct from the Enterprise matrix used elsewhere in this series, because OT attacker objectives (manipulate a physical process, deny availability) differ fundamentally from IT objectives (steal data, maintain access):

TacticTechniqueID
Initial AccessInternet Accessible DeviceT0883
Impair Process ControlModify ParameterT0836
ImpactLoss of AvailabilityT0826

What You Can Do Today

  1. Inventory every internet-facing OT asset today. The Poland incident started with vulnerable edge devices reachable from the internet — this is the single highest-leverage finding a review can produce, and it doesn’t require touching a live process to identify.
  2. Enforce the Purdue Model’s DMZ in practice, not just on paper. Verify there’s no direct path between Level 4/5 (IT/business) and Level 0–3 (OT) systems that bypasses the DMZ — a surprising number of “documented” segmented networks have an undocumented exception someone added for convenience years ago.
  3. Never run active vulnerability scanning against live OT networks without vendor sign-off and a maintenance window. Use passive network monitoring (traffic analysis without sending probe packets) for continuous visibility instead.
  4. Adopt IEC 62443 zones and conduits as your segmentation model, and assign Security Levels based on actual threat exposure per zone rather than treating the whole OT network uniformly.
  5. Treat engineering workstation software as a high-value target, not just the PLCs themselves. Securing the workstations that can push changes to controllers is as important as securing the controllers.
  6. Build an OT-specific incident response plan that doesn’t assume you can simply “take the system offline.” Know in advance what a safe degraded-operation mode looks like for each critical process, because in OT, containment itself can carry safety risk that it doesn’t in IT.
  7. Train IT security staff specifically on OT constraints before giving them OT network access. An IT-trained analyst running a routine port scan against a live SCADA network with good intentions has caused real outages — this is a training gap, not a malice problem, and it’s fixable with a half-day of OT-specific onboarding.

Sources