The SANS Institute has recorded its largest single-year jump in ICS/OT cyber incidents, with roughly one in three industrial organizations reporting an operational technology security incident in the past year. For those of us who have spent years defending plants, utilities, and manufacturing floors, this isn't a surprising datapoint — it's a confirmation of what IR teams have been seeing on the ground: OT environments have moved from the periphery of attacker interest to the center of it.
This is not a niche problem for energy utilities anymore. Manufacturing, water treatment, transportation, pharmaceuticals, and food production are all in scope. If your organization operates physical processes — anything with PLCs, SCADA systems, HMIs, historians, or distributed control systems — the statistical likelihood that you'll face an OT security incident has never been higher. The time to build or mature an OT security program is before the incident, not during the outage.
Why the Jump Is Happening: Structural Weaknesses Attackers Are Exploiting
The SANS finding reflects several converging trends that defenders must understand:
1. IT/OT convergence without security convergence. Organizations have connected OT networks to enterprise IT for remote monitoring, predictive maintenance, ERP integration, and cloud analytics — but security architectures haven't kept pace. Every new connection between the business network and the plant floor is a potential pivot path. Ransomware that starts in IT increasingly reaches OT, either through direct lateral movement or through operational shutdown decisions made out of caution.
2. Exposed remote access. The post-2020 explosion of remote vendor access, remote engineering workstations, and IIoT connectivity created persistent pathways into environments that were historically air-gapped. VPN concentrators, remote desktop gateways, and vendor-managed remote support tools are now among the most common initial access vectors into OT environments.
3. Legacy systems that cannot be patched. OT environments routinely run Windows XP/7-era HMIs, unpatched engineering workstations, and PLCs with firmware that hasn't been updated in a decade. Patch windows are measured in months or years, not days, because availability and safety trump everything. Attackers know this.
4. Insecure-by-design protocols. Modbus, DNP3, OPC Classic, EtherNet/IP, and PROFINET were designed without authentication or encryption. Any attacker with network-level access to the control LAN can read process values, issue commands, and manipulate physical processes without exploiting a single software vulnerability.
5. Adversary capability maturation. Nation-state actors continue to pre-position in critical infrastructure, and criminal groups have learned that OT disruption creates enormous pressure to pay ransoms. The barrier to entry for OT-capable attacks has dropped as tooling and knowledge have proliferated.
The Defensive Reality: OT Incidents Are Different
An OT incident is not an IT incident with different assets. The differences matter operationally:
- Safety is the primary concern. A manipulated PLC can cause physical damage, environmental release, or loss of life. Containment actions that are routine in IT — pulling network cables, shutting down hosts, blocking ports — can themselves create safety hazards in OT.
- Visibility is poor. Most OT environments lack endpoint agents, network monitoring, and centralized logging. Many organizations cannot answer basic questions during an incident: What devices are on this network? What firmware are they running? Who talked to this PLC in the last 72 hours?
- Forensics are fragile. PLCs and RTUs don't have traditional forensic artifacts. Memory is volatile, logging is minimal, and rebooting a device to preserve evidence may stop a physical process.
- Recovery timelines are long. Re-imaging an engineering workstation, restoring PLC logic from known-good backups, and validating process integrity takes weeks, not hours.
Executive Takeaways
Because this is a survey-level finding rather than a single exploit or CVE, the right response is programmatic. Based on what actually works in OT environments we've defended and remediated, here are the priorities:
1. Establish OT network visibility before anything else. You cannot defend what you cannot see. Deploy passive, OT-aware network monitoring (protocol-aware sensors that understand Modbus, DNP3, S7, EtherNet/IP) at the IT/OT boundary and on critical control LANs. Passive monitoring is safe for fragile OT environments — no active scanning against PLCs, ever. Build and maintain an authoritative asset inventory including firmware versions, and validate it continuously rather than annually.
2. Enforce real segmentation, not diagram segmentation. Most organizations have a Purdue model drawing that does not match reality. Audit actual traffic flows between IT and OT. Enforce a true DMZ between Levels 3 and 4, broker all remote access through monitored jump hosts with MFA, and eliminate any direct internet exposure of OT assets — run continuous external discovery (e.g., Shodan monitoring) for your IP ranges and industrial protocol banners.
3. Govern remote access ruthlessly. Inventory every vendor remote access path. Kill standing access; require just-in-time, time-bound, MFA-authenticated sessions recorded through a jump server. Vendor VPNs that bypass your controls are one of the most reliable OT incident predictors we see in IR engagements.
4. Build compensating controls where patching isn't possible. For systems that can't be patched, use virtual patching via OT-aware firewalls/IPS, application allowlisting on HMIs and engineering workstations (allowlisting works exceptionally well on static OT hosts), USB device control, and strict network micro-segmentation around the most critical controllers.
5. Protect and test your backups — including PLC logic. Ransomware-driven OT incidents are survivable if you can restore. Maintain offline, immutable backups of HMI images, engineering workstation images, historian configurations, and — critically — current, validated PLC and DCS logic. Test restoration on a schedule. We've seen organizations discover mid-incident that their "backups" of ladder logic were three years stale.
6. Create an OT-specific incident response plan and exercise it. Your IT IR plan will fail in OT. Define who has authority to disconnect process networks, what the safety implications of containment actions are, how to coordinate with plant operations and engineering, and when to involve regulators, cyber insurance, and external DFIR support. Tabletop this at least annually with operations personnel in the room — not just IT and security.
Remediation Priorities: A Phased Approach
Immediate (30 days):
- Run external exposure discovery for your public IP space; remediate any internet-exposed OT protocols or remote access services.
- Audit and disable standing vendor remote access; require MFA on all remaining paths.
- Verify backups exist and are offline for OT-critical systems, including PLC logic.
Near term (90 days):
- Deploy passive OT network monitoring at the IT/OT boundary.
- Complete or refresh the OT asset inventory with firmware/version detail.
- Enforce jump-host brokering for all cross-boundary access.
Strategic (6–12 months):
- Implement an OT DMZ with unidirectional or tightly brokered data flows where feasible.
- Deploy application allowlisting on fixed-function OT hosts.
- Integrate OT telemetry into your SOC's detection stack — OT alerts that live in a silo nobody watches are worse than none at all.
- Conduct a joint IT/OT purple team exercise to validate detection coverage against realistic attack paths (IT initial access → pivot → OT impact).
Align the program to the NIST Cybersecurity Framework with the IEC 62443 series for OT-specific controls, and map detection coverage to MITRE ATT&CK for ICS so your SOC knows exactly which techniques it can and cannot see.
The Bottom Line
The SANS data confirms that OT security has crossed the threshold from emerging discipline to operational necessity. One in three organizations taking a hit means the question is no longer whether industrial environments are targeted — it's whether your environment is instrumented, segmented, and prepared enough to detect an intrusion before it becomes a process incident. The organizations that fare best in OT incidents are not the ones with the most tools; they're the ones with visibility, tested backups, rehearsed response plans, and disciplined control over remote access. Start there.
Related Resources
Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.