Hackopedia documents 23 real-world Operational Technology (OT) and Critical Infrastructure cyber incidents that resulted in operational disruption, safety risk, or economic damage.
Each incident is analyzed using the same consistent, OT-focused framework:
What was attacked
The specific OT, ICS, safety, or supporting operational systems involved.
How initial access occurred
The real entry point — phishing, stolen credentials, exposed remote access, supply chain compromise, or misconfiguration.
Where trust existed
The implicit assumptions between users, devices, networks, vendors, or systems that attackers exploited.
How lateral movement happened
How attackers moved from IT into OT, from one plant to another, or from monitoring systems into control systems.
Why operations were impacted
The architectural reason production stopped, safety systems were threatened, or services were disrupted.
What architectural control would have stopped it
The specific prevention mechanism — invisibility, identity-defined access, segmentation, or decoupling — that would have blocked the attack before impact.
Each incident has its own dedicated page so you can compare patterns across industries, years, attack types, and failure modes, and understand why these were not isolated events — but predictable outcomes of shared design assumptions.
Every entry in Hackopedia carries a record status.
Confirmed. The account here is supported by primary sources that have not materially changed since publication: the victim's own disclosures, regulatory filings, government advisories, or published forensic findings.
Contested. A primary source we relied on has since changed, been withdrawn, or failed to confirm the account. A contested entry is not a retracted one. It means the public record moved and we are telling you where, rather than leaving our first version standing because it reads better.
Entries marked Contested carry a dated editor's note setting out what changed and what we now believe the record supports. We would rather run a catalog you can check than one that sounds certain.
Vector undisclosed. Where an entry names an initial access vector, that vector comes from public reporting. For ten of these twenty-three incidents the initial vector was never published, was never confirmed by the affected organization, or has since been contested. Those entries are marked below. We classify those incidents on their recorded failure point, which is what the public record establishes, rather than on a vector that was inferred.
Over the last decade, 23 high-profile cyberattacks against Operational Technology (OT) and Critical Infrastructure have caused blackouts, plant shutdowns, contaminated water scares, safety system failures, and billions of dollars in economic damage.
From the Ukraine power grid attacks to Triton, Oldsmar, Colonial Pipeline, JBS, Maersk, and beyond, these incidents are often described as inevitable, sophisticated, or the cost of doing business in a connected world. They weren’t.
Every one of these breaches followed a well-known, repeatable pattern:
Hackopedia exists to document those failures — and to show why they were preventable.
A recurring theme across these incidents is administrative convenience overriding operational safety. Identity systems shared between IT and OT. Remote access designed for office workers extended into plants. Broad trust granted to vendors, contractors, and third-party software.
In the Colonial Pipeline incident, a single compromised VPN credential on the IT side forced the shutdown of thousands of miles of pipeline — not because OT was encrypted, but because OT could no longer be trusted to remain isolated. In many cases, organizations shut down operations preemptively — not because OT was compromised, but because they had no way to guarantee it wouldn’t be next.
That is not resilience. That is architectural fragility.
The lesson from these 23 incidents is clear:
Prevention in OT must focus on eliminating the conditions that allow attacks to progress:
Systems must not be discoverable
Access must not be credential-based
Trust must not be implicit
Lateral movement must not be possible
In OT, availability is the primary security outcome.
Any architecture that cannot guarantee continued operation during an IT breach is fundamentally incomplete.