Why do cybersecurity organizations refuse to identify control system cyber incidents?

This blog has been jointly written and reviewed by Dr. Darrell Eilts, chief information officer, Sewerage & Water Board of New Orleans and Scott Lynn, project manager at the Institute for Homeland Security at Sam Houston State University. As such, the blog addresses the critical subject of identifying control system cyber incidents from an engineering, network security and educational perspective. 

I have written about control system cyber incidents many times, but the confusion about what is a control system cyber incident remains. According to Professor Ross Anderson in his book, “Security Engineering: A Guide to Building Dependable Distributed Systems”, security engineering is about building systems to remain dependable in the face of malice, error or mischance. That is, cyber incidents include malicious and unintentional incidents. 

There have been very few disclosures of control system cyber incidents whether malicious or unintentional. The impetus for this blog is recent discussions from the insurance and medical device communities that assume that “unintentional” control system cyber incidents weren’t “actually” cyber incidents. This is a mistake. The problems caused by unintentional incidents can be just as serious as those caused by malicious incidents. That’s true, whether the unintentional incident is a technical failure (like the 737 Max crashes traceable to erroneous angle of attack sensor data feeding the flawed MCAS flight control system) or unexplainable operator actions (like the 2008 Florida outage that affected about three million people for almost eight hours).

Background

Cybersecurity policies require that cyber incidents be identified as such. Cyber incident response plans are initiated after incidents are identified as being cyber-related. To many people in the cyber risk and incident response areas, cyber incidents mean data breaches, not equipment damage or injuries/deaths. Tools such security information event and management (SIEM) systems were developed for network data breaches not for control system impacts.

There are numerous data breach reporting databases such as the Verizon data breach report. State, federal and international organizations have formal reporting requirements for identifying and reporting data breaches. Operational technology (OT) databases generally focus on ransomware that indirectly cause impacts on control systems, not damage or injuries. Control system cyber incidents that cause physical impacts are not data breaches and the cyber incident reporting and training communities do not address control system cyber incidents.

The organization responsible for identifying cyber incidents should have a working understanding of what constitutes anomalous conditions. However, that isn’t always the case. Even if you have domain expertise, you may not understand cyber impact vectors. This is particularly applicable to control system cybersecurity where control system engineers are generally not familiar with cybersecurity and network security personnel are not familiar with equipment operations.

As Dr. Eilts has observed in the water industry,

“Operations staff have the domain knowledge to recognize something is wrong, but they are not trained to think ‘cyber.’ The cybersecurity staff are trained to think ‘cyber,’ but they do not understand what normal process behavior looks like. That organizational separation means the people best positioned to detect the problem are structurally prevented from naming it.”

From my experience, this situation is common in many sectors.

What is a cyber incident?

Cyber incidents are defined as involving electronic communication between systems or between systems and people (displays) that can affect the IT CIA triad of Confidentiality, Integrity or Availability. The definition does not require a cyber incident to be malicious as Professor Anderson states. 

“Unintentional” cyber incidents are important

The are several reasons that unintentional control system cyber incidents are important:

• Unintentional cyber incidents can cause the same impacts as malicious incidents. 
• A malicious incident can appear to be an unintentional incident. In the Stuxnet attack on the Iranian nuclear centrifuges, for more than a year the Iranians thought the equipment malfunctions were equipment issues, not cyberattacks. 
• Unintentional cyber incidents can be used as templates for malicious attacks since you know these incidents have caused physical impacts. For example, if a process sensor failure caused a plant impact, an adversary studying that event now knows what to target and that there will be physical consequences.

Even in IT, cyber incidents that have caused major impacts such as the October 2024 CrowdStrike incident have sometimes not universally been identified as being a cyber incident because the CrowdStrike incident wasn’t malicious. 

Control system cyber incidents are real

My non-public control system cyber incident database is now nearing 20 million control system cyber incidents that have killed more than 30,000 people. These incidents are global and continue to occur. Sectors include non-nuclear power plants, nuclear power plants, electric transmission and distribution, water and wastewater, oil/gas/chemicals, pipelines, transportation (rail, vehicles, ships, planes), manufacturing, food and beverage, space and defense. A significant percentage of these incidents were malicious. A significant percentage of these incidents, including those that caused catastrophic damage, were NOT a result of IP networks being compromised so they would not be detected using IT or OT network monitoring systems. 

Control system cyber incidents can have significant financial impacts

There have been companies that have declared bankruptcy because of malicious and unintentional control system cyber incidents and others that have experienced multi-billion-dollar impacts or affected millions of customers. These incidents can have an impact on credit ratings, which is a board level consideration.

Insurance carriers are increasingly defining what qualifies as a "cyber event" for coverage purposes. If unintentional control system incidents are not classified as cyber, they may fall outside cyber insurance coverage. That is a board-level consequence.

Control system cyber incidents are not being identified or reported

Control system cyber incidents affect physics and therefore there are often physical reactions. That is trains crash, planes crash, lights go out, water supply is compromised, pipelines burst, robots “misbehave”, etc. You can’t hide the impacts, but people often can’t (or won’t) identify the incidents as being cyber-related. U.S. government reports from NTSB, NRC, DOE, EPA, TSA, etc. have not identified many control system incidents as being cyber-related nor have many internation government organizations either. Neither have industry organizations such as NERC. Moreover, government and industry cyber information sharing programs are about vulnerabilities not consequences. 

Get your subscription to Control's tri-weekly newsletter.

There are many possible reasons for the lack of identifying control system incidents as being cyber-related: 

• There have been seven U.S. cyber-related outages that affected at least 80,000 customers though none of these were identified as being cyber-related. Since 2018, the DOE Operating Experience (OE) 417 reports added a category – “Complete loss of monitoring or control capability at its staffed Bulk Electric System control center for 30 continuous minutes or more”. This category should be considered cyber – whether unintentional or malicious. There have been more than 200 of these incidents since 2018 – less than five were categorized by DOE as being cyber-related. A number of these incidents occurred in multiple states. Some occurred and ended at the same time. Some resulted in significant loss of power.
• NERC issued two Lessons Learned documents in 2025: “Loss of Monitoring and Control Due to a Communication Failure Between Control Centers” and “Loss of SCADA/EMS Monitoring and Control – GPS Clock Failure”. Neither document identified the incidents as being cyber-related despite both incidents experiencing loss of monitoring and control that affected the bulk electric system. In the GPS case, NERC stated: “Introducing incorrect time synchronization might inadvertently weaken cyber security defenses. Many security protocols and audit trails rely on precise time synchronization, and discrepancies can be exploited by malicious actors to obscure or manipulate activities”.
• People default to "equipment failure" because they don't see the cyber dimension embedded in modern devices. A glucose monitor looks like a simple patch on someone's arm, but it's running firmware, executing algorithms, and transmitting data wirelessly. Wednesday, Feb. 4, 2026, FDA classified Abbott Laboratories' recall of certain glucose monitoring sensors as the most serious after reports tied the devices to seven deaths. Abbott is recalling specific lots of FreeStyle Libre 3 and FreeStyle Libre 3 Plus sensors due to faulty readings, which show blood sugar levels lower than they actually are. As of Jan. 7, 2026, the company had reported seven deaths and 860 serious injuries associated with the issue, according to the FDA. Abbott said the sensors can provide incorrect glucose readings over extended periods. If users do not detect the errors, they may make dangerous treatment decisions, including eating excessive carbohydrates or skipping or delaying insulin doses, potentially leading to serious health risks. As Dr. Eilts points out, “Continuous glucose monitors are not simple mechanical devices. They rely on firmware, processing algorithms, and wireless communication to convert sensor readings into displayed values. (This also describes an industrial control system.) A fault anywhere in that chain would be a cyber incident.” Yet FDA has not identified the Abbott Laboratories and other similar cases as being cyber-related. Consequently, there was no cyber incident response program initiated, which impacted the ability to conduct a comprehensive root cause examination.
• NTSB has not identified control system incidents as being cyber-related. The first NTSB case I encountered was the June 1999 Bellingham, WA. Olympic Gasoline pipeline rupture incident. When I first heard about the incident it was described as occurring following maintenance on a water line when a backhoe nicked the gasoline pipeline (five years before the explosion). Consequently, I didn’t pay much attention to it. However, when I held the first KEMA Control System Cybersecurity Conference in July 2022, NTSB attended. When I asked why NTSB was there, I was told NTSB was finalizing the report on the Bellingham incident as the pipeline rupture was due to a combination of issues including SCADA. The 88-page NTSB report cited SCADA as the proximate cause of the incident but made no mention of cyber or a broadcast storm. However, in 2007 Marshall Abrams from MITRE and myself did a detailed study of the Bellingham incident to determine if following NIST SP800-53 could have prevented the incident as SCADA experienced a broadcast storm and there were issues with process sensor monitoring. The incident was very consequential as three people died, three people went to jail, and the incident led to the bankruptcy of the Olympic Pipeline Company. The report is on the NIST and MITRE websites and we gave a presentation on the incident at the 2008 RSA Cybersecurity Conference.
• Level 0 devices (e.g., process sensors) have no cyber forensics, nor is there cybersecurity training for these devices. Level 0 devices generally use non-routable protocols before the data goes through serial-to-Ethernet converters, the malicious or unintentional compromise occurs before the data becomes Ethernet packets. Procurement specifications for control system equipment rarely include cybersecurity requirements at the device level. This perpetuates the vulnerability cycle: organizations replace legacy equipment with new devices that have the same security gaps, and the pattern repeats across new installations and retrofits.
• Non-routable protocols have been excluded from many sectors’ cybersecurity programs.
• There has been minimal information sharing of control system cyber incidents between sectors, even though multiple sectors use the same control systems from the same vendors often for similar purposes and information, but the incident information is often not shared. I have many cases where the same control system cyber incidents occurred in multiple sectors as the same equipment was used for the same type of process.
• There are cases where confidentiality agreements with the control system suppliers have prevented the cyber incident information from being shared even with other users of the same equipment. I was at a conference where the vendors were expressing their frustration that they could not share the incident information from one customer with the rest of their customers. 
• There is reticence to identify control system incidents as being cyber-related, because that could trigger reporting requirements outside the immediate organization and sometimes even the company, which could negatively affect public perception, possibly cause regulatory issues, insurance and credit rating considerations, as well as possibly delay system restart.
• It is unclear if there is a fear in government and industry to publicly identify control system cyber incidents that could open organizations up to further exploitation by bad actors.
• There is no control system cybersecurity training to identify control system incidents as being cyber-related. In 2015, I gave a seminar at the International Atomic Energy Agency (IAEA) on how to identify control system incidents as being cyber-related by using three nuclear plant control system cyber incidents that had caused significant impacts yet there was reticence to address control system cyber incidents. 
• The lack of training for identifying control system cyber incidents in water occurred with the February 2021 Oldsmar, FL water system “cyberattack”. This was not a cyberattack but operator error. Yet, Oldsmar was the impetus for the EPA water industry cybersecurity requirements which don’t include control systems. Conversely an unintentional water system control system cyber incident that sent more than 100 people to the hospital was not identified as being cyber-related. 
• Another control system cybersecurity public disclosure issue is federal law enforcement withholding information about control system cyberattacks until formal indictments have been issued. January 2021, about a month before the Oldsmar incident, a water control system cyber incident occurred that was not disclosed until the indictment was issued more than two years later. A similar issue occurred Feb. 6, 2026, when an indictment was issued against a man accused of hacking into a public utility’s well and pump control system causing damage that occurred a year earlier. This is not just a water industry issue. A similar disclosure issue occurred in the food industry when a control system cyberattack was disclosed more than two years after the cyberattack.
• There have been thousands of cases in other sectors where control system incidents have not been identified as being cyber-related including manufacturing, medical devices and equipment, oil/gas, transportation (ships, rail, pipelines, automotive), and defense. 

Recommendations

• Establish control system cyber incident training programs to “train the trainers” using the few experts available. The experts are not network security nor network security incident response experts but control system experts capable of identifying control system incidents as being cyber-related. The ability to identify the millions of control system cyber incidents in my control system cyber incident database is an example of the needed expertise. This requires years of experience, fundamental understanding of good versus anomalous control system and equipment behavior, and a streak of stubbornness as history says “experts” will challenge their findings. 
• Participants in the training should include personnel from incident response, IT and OT cybersecurity, engineering, maintenance, procurement, legal, and risk management. Training should include control system incidents that were identified as being cyber-related as well as control system incidents that were not identified as being cyber-related to demonstrate similarities and differences. Additionally, a mechanism is needed to disseminate this information on control system cyber incidents throughout the organization as well as to relevant outside entities (this is where legal and risk management is needed). 
• Dr. Eilts has been very involved in cybersecurity management and organizational issues. As such his recommendations are to “work with industry, national laboratories, and universities to perform formal studies to address why organizations enable the culture gap between operations and network security to continue to exist. Until that culture gap changes, the same patterns will repeat. As an example, an NSF-funded research effort examining the decision-making behind incident classification, perhaps using frameworks like cumulative prospect theory and heuristic biases, could produce findings with real industry policy implications. The evidence suggests organizations weigh the perceived losses from classification (regulatory burden, reputational risk, operational delay) more heavily than the less visible gains of accurate identification, while anchoring on 'equipment failure' rather than confronting the cyber dimension. Without understanding the behavioral drivers, we only treat symptoms. Specifically, when operators see a process anomaly, their training and experience tell them to check the equipment first. The possibility of cyber manipulation isn't in their mental model. This isn't a failure of the individual; it's how they were trained. The anchoring on equipment failure as the default explanation is reinforced every time an incident is investigated without considering the cyber dimension."

Summary

Cybersecurity policies require that cyber incidents be identified as such. Cyber incident response plans are then initiated after incidents are identified as being cyber-related. To meet those goals, training is required to be able to identify control system incidents as being cyber-related and a mechanism to disseminate this information on control system cyber incidents throughout the organization as well as to relevant outside entities. Because of the culture gap between engineering and network security that contributes to not identifying control system cyber incidents, industry, national laboratories, and universities need to perform formal studies to address why organizations enable the culture gap and how to overcome those barriers. Another concern about control system cyber incident disclosure was identified after 9/11 - connecting the dots. This is made more difficult with the silos between sectors and federal law enforcement withholding information that a cyber incident has occurred until an indictment is issued which can be a year or more.