What 50 OT Incidents Say When You Only Count What You Can Prove
Last Thursday, I presented at the ICS Cybersecurity Conference in Nashville. Most OT security talks pick one incident and take it apart: one plant, one attacker, one timeline. That's useful, but a single case can tell you almost anything you want it to.
So I did something different. I treated the 23 incidents in our first Hackopedia volume as one dataset, spanning water, energy, manufacturing, ports, and pipelines, and asked a simple question. When OT operations stop, what keeps showing up?
The data pointed to lateral movement. An attacker gets a foothold somewhere ordinary, usually the business network, and the distance between that foothold and the systems that run the physical process turns out to be far shorter than anyone thought.
Raising the bar for Volume 2
That talk was the last outing for that dataset in its old form. I’m now building Hackopedia Volume 2, which expands from 23 incidents to 50. It also raises the barrier to entry for proof.
Volume 1 did what most of the industry does. Where a victim never disclosed how an attacker got in, the incident was classified on the most likely failure point. That's a reasonable instinct, but it isn't evidence. For Volume 2, every claim has to trace to a primary source: a regulatory filing, sworn testimony, a government advisory, a court record, or the victim's own dated statement. Anything resting on press reports, unnamed sources, or a single vendor's view is labeled as reported, not verified. Where the record is silent, I say so instead of filling the gap.
That also includes correcting the earlier work. Several Volume 1 entries stated access methods that no source supports, and Volume 2 says so on the page.
The goal is for Hackopedia to inform and teach, built only on what is verifiable rather than what is suspected.
The early numbers (draft, still in progress)
Of the 50 Volume 2 entries, 45 are real intrusions with a real victim. The other five are a research honeypot, an undeployed malware toolkit, a malware sample with no victim, and two incidents whose basic facts are still contested.
Across those 45, counting only what a primary source confirms:
- Lateral movement: 16 of 45 (19 counting cases only reported)
- Exposed and unpatched systems: 11 of 45 (21 with reported cases)
- Credentials: 8 of 45 (15 with reported cases)
These numbers are lower than the ones I showed on stage, and that's the point. When you count only what's proven, the percentages drop. The ordering doesn't: lateral movement still leads.
Two more findings stood out:
- The record is mostly silent on how they got in. In 25 of the 45, no primary source has ever said how the attacker got in.
- Most of the damage came from the business side. In 21 of the 45, operations stopped or slowed because the business network went down or was cut off as a precaution, not because anyone touched the plant.
Lateral movement, and the fear of it
Put those together, and the pattern is hard to miss. In 30 of the 45 incidents, either lateral movement is documented, or operations stopped because the business network failed or was cut off out of fear that the intruder would spread.
Colonial Pipeline is the clearest example. The ransom note was found on the business network. The company's own control center stopped a 5,500-mile fuel pipeline in about fifteen minutes. The reason given under oath was to ensure the malware did not spread to the systems that run the pipeline. No compromise of those systems was ever shown.
That pattern repeats across the 50. Nucor halted production at multiple sites "in an abundance of caution." Jaguar Land Rover shut down its global systems, and UK vehicle production stopped for about five weeks. Maersk put the effect of NotPetya on its profitability at USD 250 to 300 million.
In each case, the costly part wasn't an attacker operating the plant. It was the operator having no way to prove the plant was safe while the business network was compromised, and stopping everything to be sure.
That changes where the money should go. The question isn't only whether an attacker can reach your control systems. It's whether you can show they can't, quickly enough to keep running while you deal with the business side.
Volume 2 is still in draft, and the numbers may move as I finish verifying the last entries. When it's done, every entry will show its sources, what's verified, what's only reported, and what nobody knows.
If you were in the room on Thursday, thank you for the questions. If you have a primary source I’m missing, I'd love to see it.
FAQs
What do 50 OT cyber incidents reveal about the biggest operational security risks?
The early Hackopedia Volume 2 analysis shows that lateral movement is the most frequently verified recurring pattern. Of 45 real-world intrusions with identifiable victims, lateral movement is confirmed in 16 incidents and reported in 19 when less-certain cases are included. The findings suggest that the ability of attackers to move from compromised business systems toward operational environments remains a major OT cybersecurity risk.
Why is lateral movement such a serious problem in OT environments?
Lateral movement allows an attacker who compromises one part of a network, often the corporate IT environment, to move toward other systems. In OT environments, that can create uncertainty about whether control systems are safe. Even when attackers never reach the plant floor, operators may shut down production or disconnect systems because they cannot quickly prove that the OT environment has not been compromised.
How often is the initial attack vector actually known in OT incidents?
In the current Hackopedia Volume 2 dataset, the initial access method is not confirmed by a primary source in 25 of 45 real-world intrusions. This means that more than half of the incidents do not have a publicly verified explanation for how the attacker originally entered the environment.
How often do IT cyberattacks cause OT shutdowns without directly compromising control systems?
The early dataset shows that in 21 of 45 incidents, operations stopped or slowed because the business network failed or was intentionally disconnected as a precaution. In these cases, operational disruption occurred even though there was no confirmed compromise of the industrial control systems themselves.
What happened during the Colonial Pipeline cyberattack?
The ransomware was discovered on Colonial Pipeline's business network. The company shut down pipeline operations to reduce the risk that the malware could spread to systems responsible for operating the pipeline. No compromise of those operational systems was publicly demonstrated, making the incident a major example of how fear of lateral movement can cause physical operations to stop.
Why does Hackopedia Volume 2 use stricter sourcing than Volume 1?
Volume 2 requires claims to be supported by primary sources such as regulatory filings, sworn testimony, government advisories, court records, or dated statements from the affected organization. Claims based only on media reports, unnamed sources, or vendor analysis are labeled as reported rather than verified.
Why are some findings in Hackopedia Volume 2 lower than earlier estimates?
The numbers are lower because the methodology now counts only what can be supported by primary-source evidence. When uncertain or widely repeated claims are removed, the totals decrease. However, the overall pattern remains similar, with lateral movement still ranking as the leading verified issue.
What do these OT incidents suggest about network segmentation?
They suggest that organizations need a way to clearly separate business networks from operational systems and limit lateral movement between them. Effective segmentation can reduce the risk that an IT compromise spreads into OT and can also help operators demonstrate that critical systems remain isolated during an incident.
Why can an IT breach stop physical operations even when OT is not compromised?
Modern industrial operations often depend on business systems for logistics, scheduling, inventory, communications, and other functions. Organizations may also intentionally disconnect systems when they cannot determine whether an attacker could move from IT into OT. As a result, an IT incident can create operational downtime without a direct attack on industrial control systems.
What is the main lesson from the 50 OT incidents?
The central lesson is that organizations need to be able to prove that compromised business systems cannot reach critical operational systems. Preventing and containing lateral movement can reduce both the risk of an OT compromise and the pressure to shut down operations during an IT security incident.
How To Reduce OT Shutdown Risk From Lateral Movement
1. Separate business and operational networks
Create clear security boundaries between corporate IT systems and industrial control environments. Avoid architectures that allow broad or unnecessary communication between the two networks.
2. Identify every permitted IT-to-OT connection
Document which users, applications, devices, and systems actually need to communicate with OT assets. Remove connections that exist only because of legacy configurations or administrative convenience.
3. Apply least-privilege access between segments
Allow only the specific communications required for operations. A user or device that can access one system should not automatically gain visibility or connectivity to other parts of the environment.
4. Microsegment critical OT assets
Divide the OT environment into smaller security zones so that compromise of one device or segment does not provide a path to the rest of the network. Prioritize systems whose disruption could stop production or affect safety.
5. Restrict lateral movement from compromised IT systems
Design segmentation policies so that malware or an attacker operating on the business network cannot discover, scan, or directly connect to protected OT assets.
6. Test whether OT can remain isolated during an IT incident
Run incident-response exercises that assume the corporate network has been compromised. Determine whether OT systems can continue operating safely while IT systems are disconnected, investigated, or restored.
7. Verify isolation before an incident occurs
Do not wait for a ransomware event to determine whether network boundaries work. Test segmentation and access controls regularly so the organization can demonstrate which systems are reachable and which are not.
8. Document evidence for incident-response decisions
Maintain architecture diagrams, access policies, test results, and network-control records that help responders quickly determine whether an attacker could have reached OT systems.
9. Use primary-source evidence when analyzing past incidents
When evaluating OT attacks, separate confirmed facts from reported or inferred attack paths. Regulatory filings, government advisories, sworn testimony, court records, and statements from the victim organization provide a stronger basis for security decisions.
10. Design for continued operations during IT compromise
The goal is not only to prevent attackers from reaching OT. It is also to give operators enough confidence in the separation between IT and OT that production does not have to stop simply because the business network has been compromised.
American Water’s cyber incident shows why water utilities need stronger OT isolation to stop IT breaches from threatening critical infrastructure operations and availability.
Explore the complete analysis of 23 OT attacks that defeated firewalls, VPNs, and air gaps.
.svg)
.svg)
