IT Assumptions in an OT World: What Recent Water-Sector Attacks Suggest About Our Workforce Gaps

Introduction: When Cyber Compromise Reaches the Physical Process

Malicious cyber activity affecting the water and wastewater sector has demonstrated, over more than a decade and across multiple countries, that a digital compromise can alter a physical process rather than remain confined to data loss or service interruption. Stuxnet and the 2015 and 2016 attacks on the Ukrainian power grid (Falliere et al., 2011; Lee et al., 2016) established this possibility well before these focused incidents. In several documented water-sector cases since 2021, control interfaces that govern treatment chemistry, distribution pressure, and pump operations were compromised or manipulated, in most instances through confirmed adversary access, and utility personnel were required to intervene manually to keep operations safe. Federal agencies have supported the response to these cases, a pattern that has repeated across roughly five to six years rather than appearing as an isolated event.

This pattern raises a question that is directly relevant to how cybersecurity professionals are educated and prepared. Traditional cybersecurity competency, built around network defense, access control, and incident response, remains a necessary foundation for protecting any digital system, including information technology (IT) systems and operational technology (OT) systems alike. This focus does not claim that traditional competency is wrong or insufficient in general, but that OT environments add requirements that a purely IT-oriented preparation does not routinely cover. These include process safety, physical consequence, controller architecture, industrial protocols, engineering change control, and continuous-operation constraints. For those responsible for preparing the cybersecurity workforce, particularly in designing academic curricula, this has a direct implication: personnel not exposed to these additional requirements may make design, configuration, or maintenance decisions without fully understanding how they affect physical operations. This commentary examines what recent water-sector incidents document, what those incidents reasonably suggest about workforce preparation, and what remains an open question rather than a proven cause. It also considers what educational institutions, industry, vendors and system integrators, regulators, and government agencies can do in response. The examination begins with the incidents themselves, because the incidents, and the limits of what they establish, are what ground everything that follows.

The Wake-Up Call: What Recent Water-Sector Incidents Actually Show

Four incidents illustrate the pattern, and each is presented here with the same evidentiary care: what was documented, and what remains uncertain. In 2021, an operator at a water treatment facility in Oldsmar, Florida, observed an unauthorized-looking change to the chemical dosing set point for sodium hydroxide, and reversed it before it affected the water supply (Cybersecurity and Infrastructure Security Agency [CISA] et al., 2021). This case requires a caveat that is easy to omit and important to include. Oldsmar was widely reported at the time as a cyberattack, but the attribution has since become considerably less certain. The Federal Bureau of Investigation (FBI) later told a reporter that "through the course of the investigation the FBI was not able to confirm that a targeted cyber intrusion of Oldsmar initiated this incident" (Vasquez, 2023, para. 5). A former city manager subsequently described the episode as a "non-event" likely caused by employee error (Vasquez, 2023, para. 6). The FBI's investigative file on the incident has since been made publicly available through the FBI Vault (FBI, n.d.); however, the event's attribution remains unresolved in the public record. Oldsmar is retained here, with this qualification, because it remains a widely referenced case in the water-sector cybersecurity literature and because acknowledging unresolved attribution is more defensible than treating an unconfirmed narrative as settled fact.

In late 2023 and into 2024, a series of intrusions affected programmable logic controllers (PLCs) manufactured by Unitronics at water and wastewater utilities in multiple states; the controllers had been placed on the public internet with default vendor credentials still in place, and adversaries altered controller displays and, in some cases, disrupted pumping operations (CISA et al., 2023). This incident carries firmer attribution and documentation than Oldsmar and is the basis for the detailed sequence traced.

Two distinct federal records document further activity in 2026, and they should not be treated as a single event. The first is an advisory, originally issued in April 2026 and updated since, describing Iranian-affiliated actors exploiting internet-exposed PLCs across multiple critical infrastructure sectors, not water alone (FBI et al., 2026). The second is a separate joint public service announcement, issued in July 2026, addressing malicious activity specifically against internet-facing Rockwell Automation MicroLogix controllers at water and wastewater utilities in at least seven states. Affected utilities reported loss of pressure, flooding, and loss of view or function of connected equipment; in one case, investigators found modified controller project files through discrepancies in the underlying control logic (FBI & Environmental Protection Agency [EPA], 2026). Notably, that announcement also noted that similarities in network configurations supplied by third-party vendors and integrators may have allowed the same weakness to recur across multiple, otherwise unrelated utilities.

Their recurrence across multiple years indicates a systemic condition rather than a series of unconnected events. Federal agencies responded to each case, reinforcing that reading, even though the Oldsmar case in particular should be read with the attribution caveat above in mind. What the documented incidents establish with confidence is narrower than a full causal story: exposed or misconfigured control-system access, unauthorized or unconfirmed interaction with that access, and, in the firmly attributed cases, a resulting operational effect. This commentary addresses what caused each specific exposure, including whether and to what degree workforce preparation was a factor, as a question the evidence can inform but not, on its own, fully answer. Explaining why these exposures recur at all requires distinguishing operational technology from enterprise information technology in more specific terms.

OT Is Not Simply IT in an Industrial Environment

Operational technology environments and enterprise information technology environments are both built on digital systems, but the systems serve different purposes and tolerate different kinds of risk. Enterprise information technology systems primarily support data processing, communication, and business operations, and a security failure typically results in data exposure or service interruption. Operational technology systems govern continuous physical processes, including water treatment chemistry, distribution pressure, and pump operations, and a security failure can directly alter those processes.

Some practices are poor regardless of environment, and it is worth being honest about this rather than implying otherwise. Default administrative credentials, unmanaged internet exposure, and weak authentication are not sound enterprise practices; they are deficient practices in any computing environment. None of the incidents described in the previous section should be read as evidence that operational technology environments need a different set of basic hygiene rules. The more instructive distinction is not between good enterprise practice and bad operational technology habits. It is between a set of security fundamentals that both environments share, including access control, network monitoring, vulnerability management, and incident response, and a set of additional validation requirements that apply specifically because an operational technology system governs a physical process. The same security decision that is straightforward to implement on an enterprise network may have to be checked against process continuity, safety instrumented functions, controller behavior, legacy equipment limitations, and engineering change-control procedures before it can be applied to a control system. The National Institute of Standards and Technology's Special Publication 800-82 (Stouffer et al., 2023), the federal government's principal technical guidance on operational technology security, makes this point directly, describing operational technology security as sharing the underlying objectives of enterprise information technology security while requiring distinct performance, reliability, and safety considerations that most enterprise guidance does not address. Routine patching and rebooting illustrate the point: an enterprise system can generally absorb these actions on a fixed schedule. At the same time, many operational technology components must operate continuously for years. They cannot be taken offline without interrupting treatment or distribution, so the same maintenance practice requires additional validation in the second setting even though it is not deficient in either one.

This distinction does not diminish the value of traditional cybersecurity expertise, and it does not excuse poor basic hygiene in either environment. It clarifies where sound, well-implemented enterprise practice still requires additional validation once applied to a system that governs a physical process. Personnel trained only to enterprise-network assumptions may not recognize when a decision needs that additional check.

When Enterprise-IT Assumptions Meet Physical Processes

The distinction described in the previous section becomes concrete when traced through a single, firmly documented incident. The Unitronics-related intrusions that affected water utilities in 2023 and 2024 followed a pattern that recurs across many operational technology compromises (CISA et al., 2023). Remote access to the affected PLCs was configured to support monitoring and maintenance, an arrangement commonly used to administer enterprise servers remotely. The controllers were connected to the public internet and retained default vendor credentials, a configuration that federal advisories identify as a deficient practice on any network, enterprise or industrial (CISA et al., 2023). What made the consequence different in this setting is that the same devices directly operated physical equipment. Once the controllers were reachable, the exposure removed the separation between an external adversary and the pumps and valves those controllers governed, a consequence an equivalent misconfiguration on a purely data-handling server would not have produced. Adversaries scanning for internet-exposed Unitronics controllers located the devices, authenticated using the default credentials, and altered controller displays and operational settings. Utility personnel were then required to take systems offline and revert to manual operation to confirm that treatment and distribution processes remained safe (CISA, 2023).

It is worth being specific about what this sequence does and does not establish, since the distinction matters for how seriously the argument that follows should be taken. The documented facts are the configuration, the exposure, the unauthorized access, the manipulation, and the operational effect; public incident records support each link directly. That an operational technology compromise of this kind can produce a physical consequence is a well-supported technical conclusion, not specific to this incident. That greater operational technology-specific competence, among the personnel who configure and maintain these systems, would plausibly reduce the frequency of this kind of exposure is a reasonable inference from the pattern. That insufficient workforce preparation specifically caused this configuration, rather than vendor or system-integrator defaults, resource or staffing constraints, inherited legacy architecture, or a gap in organizational change-control governance, is a hypothesis this commentary cannot verify from public records alone. Incident advisories document what was exposed and exploited, not the training history of the personnel who set the configuration. The July 2026 water-sector public service announcement discussed above is instructive here, since it points toward a contributing factor beyond any individual utility's workforce. It found similar network configurations, provided by third-party vendors and integrators, recurring across multiple affected organizations, which suggests that vendor and integrator practice, not only utility-side training, also shapes how often this exposure pattern appears (FBI & EPA, 2026). Workforce preparation is treated in this commentary as one plausible and addressable contributing factor within that broader set, not as the sole or confirmed cause of any specific incident, and the recommendation that follows, strengthening operational technology-specific education, is offered on that more limited and more defensible basis.

The Workforce Capability Gap

Recognizing industrial risk before a decision is finalized depends on personnel who possess specific competencies, and the pattern described by the practitioner quoted below, together with the credentialing comparison in the next section, raises the possibility that some entry-level cybersecurity graduates do not yet possess them. That pattern is illustrative rather than measured statistics, and it is offered here as one line of evidence among several, not as a comprehensive claim about the entire cybersecurity education system. Cybersecurity graduates are commonly well prepared in traditional information technology security, including network defense, access control, vulnerability management, and incident response. These competencies are necessary to protect enterprise systems, and their absence is a serious deficiency. On their own, however, they do not necessarily prepare a graduate to recognize when a configuration decision affects a controller governing a physical process rather than a server governing a business application.

A practitioner serving as an OT Cyber Manager, who works directly with control systems, described this gap in direct terms: "Most cybersecurity graduates come out of school with a decent understanding of traditional IT security, but very little exposure to how those same concepts apply in an operational environment" (OT Cyber Manager, personal communication, 2026). The practitioner attributed the gap to the structure of academic programs rather than to any deficiency in the students themselves, and identified specific areas of unfamiliarity, including control-system architecture, industrial protocols, legacy equipment constraints, and the physical processes the technology is designed to control. Coordination among engineers, maintenance teams, operators, and information technology staff was described as equally essential, since a technically sound cybersecurity decision can still introduce operational risk if it does not account for process continuity.

These observations, drawn from someone who works inside the environment, point to specific, addressable gaps in preparation rather than a broad indictment of current cybersecurity education. Hands-on exposure to PLCs, human-machine interfaces, industrial network traffic, and segmentation strategies suited to control-system communication patterns would address much of what was described above. Familiarity with frameworks developed specifically for industrial environments, including ISA/IEC 62443 (International Society of Automation, n.d.), NIST Special Publication 800-82 (Stouffer et al., 2023), and the MITRE ATT&CK for ICS matrix (MITRE, n.d.-a), would give students a structured way to reason about industrial risk rather than applying enterprise frameworks to a system they do not fit. Even in the absence of a dedicated laboratory, documented incidents such as Stuxnet (Falliere et al., 2011), the attacks on the Ukrainian power grid (Lee et al., 2016), TRITON (MITRE, n.d.-b), and the Oldsmar (CISA et al., 2021) and Unitronics-related (CISA et al., 2023) water-sector intrusions provide case material that illustrates how these gaps translate into real exposure. These preparation gaps are not limited to classroom instruction; they also shape how the cybersecurity field defines, measures, and credentials competency in the first place.

From Credentialed to Operationally Competent

Credentialing pathways help explain why this gap persists into the workforce. Entry-level certifications that many graduates pursue, such as CompTIA Security+ (CompTIA, n.d.-c) and CompTIA Network+ (CompTIA, n.d.-b), organize their objectives around confidentiality, integrity, and availability within enterprise networks: access control, encryption, secure configuration, network architecture, and digital forensics. Intermediate and advanced credentials, including CompTIA CySA+ (CompTIA, n.d.-a) and the ISC2 CISSP (ISC2, 2024), extend this foundation into threat detection, risk management, and security operations, again framed around enterprise systems and data. These are legitimate and necessary competencies, and nothing in this commentary suggests otherwise.

Industrial-specific credentials are organized around different priorities. The Global Industrial Cyber Security Professional certification (GIAC, n.d.), for example, addresses industrial control system architecture, safety instrumented systems, and process-control network design as its central subject matter, rather than as one topic among many. ISA/IEC 62443 (International Society of Automation, n.d.) organizes its guidance around zones and conduits within an industrial network, matching each segment to its operational function rather than a generic enterprise topology. NIST Special Publication 800-82 (Stouffer et al., 2023) addresses the industrial environment directly, including the constraints associated with legacy equipment and continuous operation. The ISC2 CISSP exam outline, for instance, explicitly names industrial control systems as one system type to consider within its Security Architecture and Engineering domain (ISC2, 2024), suggesting that general-purpose credentialing has more awareness of operational technology than a claim of zero coverage would imply. What that entry does not provide is the depth found in industry-specific credentials and frameworks: sustained treatment of controller architecture, industrial protocol behavior, process safety, engineering change control, and the continuous-operation constraints that shape how a security decision must be implemented in the field. The more defensible question, then, is not whether general credentials mention operational technology at all. Rather, the gap between the depth they provide and what an operational role requires substantiates the workforce gap described earlier as a structural feature of how the field defines and measures competency, not evidence that operational technology is absent from the curriculum entirely.

This structural gap, encouragingly, does not require replacing existing credentialing pathways or creating an entirely separate degree. It requires incorporating industrial content into existing curricula so operational competence is built alongside, rather than instead of, traditional credentialing. That distinction does not stay contained within individual classrooms or campuses; its consequences extend to critical infrastructure and national resilience.

Why the Gap Becomes a Critical-Infrastructure and National-Security Problem

The pathway from a single compromise to a national-security concern is best made explicit, not left implied. First, an operational technology compromise disrupts a water treatment or distribution process. That disruption degrades the affected utility's service through loss of pressure, contamination risk, or a forced shift to manual operation. The degraded service then affects the sectors that depend on that utility: water and wastewater utilities support healthcare facilities, fire suppression, food and beverage production, energy generation, manufacturing, transportation, government operations, and military installations, and they contribute directly to environmental protection, emergency response, and the continuity of regional economic activity. Those dependent-sector effects translate into public health, economic, or continuity consequences for the surrounding community. At sufficient scale or frequency, the accumulated consequences become a matter of critical-infrastructure resilience rather than of any single utility's operations. The incidents described earlier show that this is not a theoretical chain. Utilities that were forced into manual operation, or that issued boil-water advisories, imposed consequences on the communities, institutions, and facilities that rely on them, well beyond the utility's own operations staff (CISA, 2026).

At a small scale, a workforce competency gap, or any of the other contributing conditions discussed above, is an organizational problem addressed through hiring, training, vendor management, or a single governance revision. At the scale reflected in incidents affecting utilities across several states within a single year, those same conditions become a critical-infrastructure and national-security concern. Federal agencies responded to each of the incidents described earlier, indicating that the current combination of utility, vendor, and workforce practices is not consistently preventing these conditions from arising in the first place. This does not mean operational technology competency alone would eliminate the risk adversaries pose to critical infrastructure. Adversary capability, resourcing, and intent lie outside the control of any single utility, vendor, or institution, and, as noted above, vendor and integrator practice also appears to be a significant contributing condition in the incidents examined here. This means workforce preparation is one addressable lever among several, alongside vendor and integrator accountability, asset-management and change-control governance, and resourcing for OT-aware staffing.

What Education, Industry, Regulators, and Government Should Do

Educational institutions, industry and its vendors and system integrators, regulators, and government agencies each shape a different part of the problem described above, and coordinated action across all four can reduce the risk in ways that no single group can achieve alone.

Educational institutions are positioned to address the workforce-preparation dimension of this gap directly. Existing cybersecurity curricula can incorporate control-system architecture, industrial protocols, legacy equipment constraints, and the physical processes the technology supports, without creating a separate degree program. The hands-on exposure and framework familiarity described above are most effective when reinforced through partnerships with utilities, manufacturers, and system integrators, which situate that experience within an operational context rather than a simulated one. For administrators responsible for cybersecurity curriculum, this is an achievable revision rather than a wholesale redesign, and institutions that make these additions now will be prepared for demand that will likely continue to grow as more incidents draw attention to the sector.

Industry organizations, including the vendors and system integrators who design and deploy control-system products, influence how systems are configured and maintained after graduates enter the workforce, and the 2026 water-sector public service announcement discussed earlier suggests their role deserves explicit attention rather than an assumption that exposure begins and ends with utility-side staff. That announcement found similar vendor- or integrator-provided network configurations recurring across multiple affected organizations. This points toward standardized default configurations, deployment templates, or support practices as a condition worth addressing directly, alongside utility-side training, rather than as a secondary concern. Incorporating operational-technology-specific considerations into design and deployment decisions, including process continuity and legacy equipment constraints, addresses the same exposure conditions described earlier at the point where systems are actually built and configured. Internships, apprenticeships, and structured training opportunities extend that exposure to personnel already in the field, not just new graduates.

Regulators shape how cybersecurity requirements are applied across the sector. Guidance that recognizes the operational constraints of these systems, rather than applying enterprise-oriented requirements uniformly, would more accurately reflect the environment it is intended to protect. Regulators are also positioned to encourage direct collaboration between educational institutions and utility operators so that curriculum development remains grounded in current operational needs.

Government agencies support research, provide guidance, and coordinate response when incidents occur, and each of the incidents described earlier required exactly that kind of federal involvement. Extending that role to include sustained funding for workforce development and curriculum modernization would address the underlying gap rather than only the aftermath of individual incidents. Each of these four groups shapes a different part of the same problem, and progress in one area does not substitute for progress in the others. The conclusion returns to the commentary's central argument: cybersecurity competence must match the system it protects.

Conclusion: Cybersecurity Competence Must Match the System Being Protected

The incidents examined in this commentary, spanning approximately five to six years and affecting water utilities in multiple states, demonstrate that a cybersecurity compromise can alter a physical process rather than remain confined to information systems, a possibility Stuxnet and the Ukrainian power-grid attacks had already established well before the water sector became a documented target. In the firmly attributed cases, the exposure adversaries reached traced back to a control-system configuration inconsistent with operational technology-specific security requirements or recommendations, whether that configuration originated in utility-side decisions, vendor or integrator defaults, or some combination of the two. The Oldsmar case, by contrast, illustrates why attribution should not be assumed even when an incident becomes widely cited. None of this is evidence that traditional cybersecurity expertise is inadequate. It is evidence that operational technology environments require additional validation in safety, industrial protocols, controller architecture, and engineering constraints that a purely enterprise-oriented practice does not routinely provide. Workforce preparation is one addressable part of a broader set of conditions that also includes vendor and integrator practice, governance, and resourcing.

Closing the workforce dimension of this gap is achievable without abandoning existing credentialing pathways or cybersecurity fundamentals. It requires incorporating industrial content into curricula that already exist, encouraging closer collaboration between educational institutions and utility operators, holding vendors and system integrators accountable for the configurations they deploy, and recognizing, at the regulatory and federal level, that operational technology environments operate under different constraints than the enterprise systems that current guidance was originally written to address. The increasing attention to operational technology security across recent federal advisories reflects a field beginning to recognize this need, even though the pace of change in workforce preparation has not yet matched the pace at which these incidents are occurring. For cybersecurity education specifically, that gap between attention and action is where the most immediate progress remains to be made.

Cybersecurity competence should match the systems it protects. For systems that govern physical processes supporting public health, economic activity, and essential services, that standard requires more than traditional information technology preparation alone. The water-sector incidents examined suggest what can happen when that standard is not met, and they point to specific, addressable measures to meet it.

About the Author

Contributor-approved headshot.

Eric Burnett, MS, CEH

Eric Burnett, MS, CEH is Associate Dean of Education at the California Institute of Applied Technology (CIAT), where his work centers on cybersecurity education, curriculum development, and workforce preparation. He holds an undergraduate degree in Information Technology, majoring in Business Systems and minoring in Networking, and a master’s degree in Information Systems Management. He is completing a doctorate in Information Technology with a dissertation focus on Cybersecurity Education.

Burnett brings nearly two decades of IT leadership and cybersecurity experience spanning risk management, penetration testing and vulnerability management, IT governance, infrastructure, and networking, with professional experience across FinTech, supply chain, and payments. Before transitioning to academia, he served in the United States Air Force. His ITAICS commentary examines the intersection of cybersecurity workforce preparation, operational technology, and critical-infrastructure resilience.

Cybersecurity Education Workforce Preparation Operational Technology Critical Infrastructure

References