The traditional power grid had thousands of controllable assets. The smart grid has millions. The security architecture that worked for thousands does not scale to millions,and the energy transition will not wait for the security community to catch up.
The defender’s dilemma in machine learning security
Post 4 in this series made the affirmative case for machine learning in OT environments , specifically, for anomaly detection on process telemetry, network traffic analysis, and predictive maintenance, all deployed as observational systems that inform human decision-making rather than drive automated control. That case stands. But it is incomplete without an examination of the adversarial dimension: what happens when a sophisticated adversary specifically targets the ML system that is supposed to detect them?
This is not an abstract research concern. Adversarial machine learning , the discipline of attacking ML systems by exploiting their mathematical properties , has been an active research field for over a decade, and the techniques it has produced are increasingly accessible to adversaries who are not themselves ML researchers. The adversaries targeting critical infrastructure , nation-state actors with significant technical resources and long operational timescales , are precisely the adversaries most likely to have the capability and the motivation to probe and exploit the ML-based detection systems that critical infrastructure operators are deploying.
The defender’s dilemma is this: deploying ML-based anomaly detection improves your ability to detect certain classes of attack. But it also creates a new attack surface , the model itself , that a sophisticated adversary can probe, characterise, and ultimately evade or exploit. An organisation that deploys OT anomaly detection without understanding the adversarial ML threat to that detection system has improved its security posture against unsophisticated adversaries while potentially creating new exposure against sophisticated ones.
This post examines the specific adversarial ML techniques relevant to ICS anomaly detection deployments, the architectural and operational controls that provide robustness against those techniques, and the governance requirements for deploying ML in safety-critical environments that must remain reliable under adversarial conditions.
Part 1: The adversarial ML threat landscape for ICS
Adversarial attacks on machine learning systems are conventionally classified into three categories based on the phase of the ML lifecycle they target: training-time attacks, inference-time attacks, and model extraction attacks. Each has distinct implications for OT anomaly detection deployments.
Training-time attacks: model poisoning
Model poisoning attacks target the training data used to build an ML model. By corrupting or manipulating training data, an adversary can cause the resulting model to behave incorrectly in ways of the adversary’s choosing , either by degrading the model’s overall performance or by introducing specific blind spots that allow the adversary’s subsequent attack techniques to evade detection.
In the context of OT anomaly detection, the training data is the historical process telemetry and network traffic that characterises normal operation of the control system environment. This data is collected over weeks or months before the anomaly detection model is trained. An adversary with access to the OT environment during this training period , whether through a persistent initial access achieved months before a planned attack, or through a supply chain compromise that predates the anomaly detection deployment , could deliberately introduce subtle anomalies into process behaviour that, over time, shift the model’s understanding of what constitutes “normal.”
The technique is subtle and operationally sophisticated. The adversary does not introduce dramatic anomalies that would be noticed by operators. They introduce small, repeated deviations from normal process behaviour , slightly elevated vibration readings, marginally atypical communication timing, intermittent low-amplitude setpoint oscillations , that individually appear to be process noise or sensor drift but collectively shift the model’s baseline in ways that will allow their subsequent attack behaviours to fall within the model’s learned definition of normal.
This technique has been demonstrated in academic research against SCADA anomaly detection systems, and it is particularly concerning in OT environments for two reasons. First, the long timescales of OT intrusions , the dwell times of nation-state actors in OT environments are measured in months and sometimes years , provide ample time for training data poisoning before a planned attack. Second, the limited labelled attack data available for OT anomaly detection means that models are typically trained almost entirely on normal data, making them inherently susceptible to manipulation of what “normal” means.
Inference-time attacks: evasion
Evasion attacks target a deployed model during inference , when it is actively making predictions on new data. The adversary crafts inputs that are misclassified by the model: in the context of anomaly detection, inputs that are anomalous (representing attack activity) but are classified as normal by the model.
For OT anomaly detection specifically, evasion attacks take two forms. The first is model-aware evasion: the adversary has knowledge of the model’s architecture, training data, or decision boundaries, and crafts process behaviour or network traffic that specifically avoids the model’s detection regions. This requires the adversary to have substantial knowledge of the deployed model , either through direct access to model files, through the model extraction techniques described below, or through a long probing period in which they observe which behaviours generate alerts and which do not.
The second is black-box evasion: the adversary does not have direct knowledge of the model but probes it through repeated queries, observing which inputs generate alerts and gradually learning the model’s decision boundary through this iterative probing. In an enterprise IT context, this technique is well-documented and defences against it , rate limiting of queries, input perturbation, ensemble methods , are increasingly standard. In an OT context, the adversary’s probing queries are not API calls to a web service. They are process behaviours: the adversary makes small changes to the process state and observes whether the detection system generates an alert. This probing can be conducted very slowly, at timescales that blend with normal process variation, making it difficult to detect.
Model extraction attacks
Model extraction attacks attempt to reconstruct a model’s parameters, architecture, or decision boundaries through repeated queries. In an enterprise ML context, this typically involves querying a model API and using the responses to train a surrogate model that approximates the original. In an OT context, model extraction is less about reconstructing model parameters and more about characterising the model’s detection behaviour: understanding which process states generate alerts and which do not, to enable subsequent evasion.
The relevance to OT is that the anomaly detection model’s alert behaviour is partially observable to an adversary who has established a foothold in the OT environment. By introducing controlled perturbations to process behaviour and observing whether alerts are generated , through the same monitoring interfaces that operators use , an adversary can gradually characterise the model’s detection envelope without ever accessing the model directly.
Part 2: Why OT anomaly detection models are particularly vulnerable
The adversarial ML vulnerability profile of OT anomaly detection is shaped by specific characteristics of OT environments and OT ML deployments that distinguish them from enterprise IT contexts where adversarial ML defences are more developed.
Unsupervised learning dominates OT anomaly detection. Most OT anomaly detection systems are built on unsupervised or semi-supervised learning approaches , autoencoders, isolation forests, clustering algorithms, statistical process control variants , because labelled attack data for OT environments is extremely scarce. Unsupervised anomaly detectors learn a representation of normal and flag deviations from it, without any training signal from known attack examples.
This architecture is intrinsically susceptible to poisoning attacks that manipulate the definition of normal. A supervised classifier trained on both normal and attack examples can, in principle, be more robust against poisoning of the normal class because the attack examples provide an anchor that limits how far the normal boundary can be shifted. An unsupervised detector has no such anchor. If the training data is corrupted so that certain attack behaviours appear in the normal class, the model will learn to treat them as normal with no mechanism to resist this.
Models are retrained on operational data, creating a persistent poisoning surface. Practical OT anomaly detection deployments require periodic model retraining as the operational environment changes , new equipment, process modifications, seasonal operating modes. Each retraining cycle exposes the model to the current operational data, which includes any manipulated behaviours that an adversary has introduced since the last training cycle. The retraining process that is necessary for the model to remain useful is also the mechanism through which a persistent adversary can progressively degrade the model’s detection capability.
The observation channel is limited, making evasion probing harder to detect. In enterprise IT, an adversary probing an ML system through repeated queries leaves a trail in access logs, network logs, and API request records. In OT, an adversary probing an anomaly detection system by manipulating process behaviour leaves a trail in process historian data. This trail is less structured than API logs, harder to correlate with probing intent, and harder to distinguish from legitimate process variation. The detection of adversarial probing in OT environments requires specifically designed monitoring for patterns of process variation that are consistent with systematic model probing , a monitoring capability that virtually no current OT security deployment includes.
Alert suppression is a known adversary goal. MITRE ATT&CK for ICS documents alert suppression and detection impairment as explicit adversary objectives , tactics that sophisticated adversaries pursue specifically to degrade the defender’s visibility before executing their primary attack. The ML anomaly detection system is a detection capability that an adversary targeting it for alert suppression would approach through exactly the evasion and poisoning techniques described here. The connection between adversarial ML and the documented adversary goal of detection impairment is direct and deserves explicit acknowledgement in the threat model for any OT anomaly detection deployment.
Part 3: Architectural controls for adversarial robustness
Understanding the adversarial ML threat is the prerequisite. The response to it is a combination of architectural controls , design choices that reduce the model’s susceptibility to adversarial manipulation , and operational controls , processes that detect and respond to adversarial manipulation attempts.
Ensemble detection , multiple independent models
The most practically effective architectural control against evasion attacks is ensemble detection: deploying multiple anomaly detection models with different architectures, different feature sets, and ideally different training data sources, and requiring that an anomaly be detected by multiple models before an alert is generated. An adversary who has characterised and evaded one model must repeat the characterisation and evasion effort for each model in the ensemble. The different feature representations used by different models , one model based on network traffic statistics, another on process physics, a third on temporal correlation patterns , present different attack surfaces that are difficult to evade simultaneously.
Ensemble methods also provide a practical mechanism for detecting model poisoning: if multiple independently trained models begin to diverge in their assessment of specific process conditions, the divergence is a signal that one or more models may have been affected by training data manipulation. Consistent divergence between ensemble members on specific input patterns , where one model classifies a condition as normal while others classify it as anomalous , should trigger investigation of both the condition and the model.
The operational cost of ensemble detection is higher model complexity, higher compute requirements for inference, and a more complex alert triage process. These costs are real but are justified for high-consequence OT environments where the adversary capability includes adversarial ML techniques.
Physics-informed constraints , anchoring models to process laws
A class of architectural control that is specific to OT anomaly detection is the integration of process physics constraints into the model architecture. Process physics , the conservation laws, thermodynamic relationships, fluid dynamics, and electrical engineering principles that govern industrial processes , provide constraints on what process states are physically possible. An anomaly detection model that incorporates these constraints cannot be fooled into classifying physically impossible process states as normal, regardless of how the training data has been manipulated.
In practice, physics-informed anomaly detection takes several forms. The simplest is hard constraint checking: process states that violate physical conservation laws (energy, mass, momentum) are flagged as anomalous regardless of what the statistical model says. A more sophisticated approach is physics-informed neural networks (PINNs), which incorporate physical governing equations as regularisation terms in the model training objective, constraining the model’s learned representations to be consistent with the process physics.
Physics-informed constraints are particularly valuable against poisoning attacks, because a poisoning attack that manipulates the statistical distribution of training data cannot violate the physical laws that the constraints enforce. An adversary seeking to cause the model to classify anomalous high-pressure conditions as normal cannot, through training data manipulation, change the fact that the process physics model will flag the pressure as inconsistent with the observed flow rate and temperature.
The implementation of physics-informed constraints requires process engineering input , the relevant physical relationships must be correctly specified for each process being monitored , which is both a dependency and an opportunity: involving process engineers in the design of the anomaly detection system produces models that are more operationally meaningful and more adversarially robust.
Cryptographic data provenance , protecting training data integrity
The training data poisoning attack requires that an adversary be able to manipulate the data that will be used to train or retrain the model. Protecting training data integrity through cryptographic provenance , signing historian data at the point of collection, verifying signatures before including data in training datasets , provides a mechanism for detecting manipulation of training data that occurs after collection.
The implementation requires that historian data be cryptographically signed at the collection point , the OT network sensor or the historian server , using a key that is managed separately from the systems that process the data for training. Any manipulation of the data after signing , by an adversary who has compromised the data processing pipeline but not the signing infrastructure , will produce signature verification failures that flag the manipulation.
This control does not protect against manipulation that occurs before the signing point , an adversary who has compromised the field devices providing sensor readings can provide false readings that are correctly signed as authentic OT data. But it does protect against manipulation of the data pipeline between collection and training, which is the attack surface for an adversary who has compromised IT-adjacent systems rather than the OT sensors themselves.
Adversarially robust training , building resistance into the model
A family of ML training techniques collectively described as adversarially robust training attempts to produce models that are inherently more resistant to evasion attacks by incorporating adversarial examples into the training process. The most established technique is adversarial training: generating adversarial examples , inputs crafted to evade the current model , and including them in the training dataset with correct labels, so that the model learns to classify them correctly.
Adversarially trained models are more resistant to known evasion techniques but typically show reduced accuracy on clean data and increased computational cost during training. For OT anomaly detection, where false positive rates are already a significant operational concern, the accuracy trade-off must be carefully evaluated. The appropriate application of adversarially robust training is to the highest-consequence detection functions , detection of safety-system-targeting attacks, detection of setpoint manipulation , where the cost of evasion is highest and justifies the accuracy trade-off.
Part 4: Operational controls for detecting adversarial manipulation
Architectural controls reduce the model’s susceptibility to adversarial manipulation. Operational controls detect adversarial manipulation that nevertheless occurs, enabling response before the adversary achieves their ultimate objective.
Monitoring for training data anomalies
The training data preparation pipeline should include monitoring for statistical anomalies that are consistent with poisoning attacks: systematic shifts in the distribution of specific process variables that are not explained by operational changes, correlation patterns between variables that deviate from expected process physics, or temporal clustering of anomalous readings that suggests deliberate introduction rather than random process variation.
This monitoring is most effective when it is conducted by analysts with process engineering knowledge who can distinguish between data anomalies caused by sensor drift, equipment degradation, or process changes and data anomalies consistent with deliberate manipulation. The statistical methods , change point detection, distribution shift monitoring, outlier analysis , must be applied by people who understand the process context, not mechanically by automated systems whose own detection could be subject to the same adversarial manipulation they are monitoring for.
Red team testing of the detection system
The anomaly detection system should be subject to regular red team testing that specifically attempts to evade its detection using the adversarial ML techniques described in Part 1. This testing serves two purposes: it validates the model’s robustness against the specific evasion techniques in the red team’s toolkit, and it identifies the model’s current detection boundaries so that changes in those boundaries , potentially caused by training data manipulation , can be detected through repeated testing over time.
Red team testing of OT ML systems requires specialised capability: the testers must understand both adversarial ML techniques and OT process dynamics well enough to craft evasion attempts that are operationally plausible. This is a rare combination of skills that most organisations will need to source from external specialist providers. The testing must be conducted in a test environment that mirrors the operational environment , not on the production detection system , to avoid introducing the adversarial inputs into the production training data.
Model drift monitoring
The deployed anomaly detection model’s performance should be monitored continuously for indicators of degradation that might reflect adversarial manipulation: increasing false positive rates that might indicate the model’s normal boundary has been shifted, decreasing sensitivity to specific anomaly types that might indicate targeted evasion, or systematic changes in alert patterns that correlate with changes in process behaviour that have no operational explanation.
Model drift monitoring requires baseline measurements of model performance , false positive rates, alert rates for specific anomaly categories, sensitivity to controlled test inputs , established at deployment and tracked over time. Significant deviations from baseline that cannot be explained by legitimate operational changes should trigger model revalidation: retraining from a clean dataset with verified provenance, followed by validation of the retrained model against the performance baseline.
Separation of the detection system from the monitored environment
A critical operational control that is both architectural and procedural is ensuring that the anomaly detection system cannot be influenced by the environment it is monitoring in ways that go beyond observing sensor data and network traffic. The detection system should not receive configuration inputs from OT network systems. Its model files should not be stored on systems accessible from the OT network. Its retraining pipeline should use data that has been cryptographically verified and transferred to an isolated training environment rather than consuming data directly from the OT historian through a live connection.
This separation limits the adversary’s ability to influence the detection system to the inputs it was designed to receive , process telemetry and network traffic , and forces any poisoning attack to operate through those inputs rather than through direct manipulation of model files, training pipelines, or configuration systems.
Part 5: Governance requirements for adversarially robust ML
The adversarial robustness requirements described above have governance implications that extend beyond the technical design of the detection system. An organisation that deploys OT anomaly detection without governance structures that maintain adversarial robustness over time will find that its initial robustness properties degrade as the model ages, as the operational environment changes, and as adversary techniques evolve.
Adversarial robustness as a model acceptance criterion
The model acceptance process , the validation that must be passed before a new or retrained model is deployed to the production OT environment , must include explicit adversarial robustness testing. The acceptance criteria should specify minimum performance against a defined set of adversarial evasion techniques and minimum resistance to training data poisoning scenarios. A model that performs well on clean test data but fails basic adversarial robustness tests should not be deployed.
This requires that the organisation maintain the capability to conduct adversarial robustness testing as part of its model validation process , either through internal capability or through a defined external testing provider with the necessary specialised skills.
Vendor accountability for adversarial robustness
Most OT anomaly detection deployments use commercial platforms , Dragos, Claroty, Nozomi, Fortiphyd Logic , rather than internally developed models. The adversarial robustness of these platforms depends on the vendors’ ML security practices, which are not uniformly documented or independently assessed. Procurement requirements for OT anomaly detection platforms should include adversarial robustness specifications: what evasion techniques has the vendor tested against, what training data provenance mechanisms does the platform implement, and how does the vendor’s ongoing research programme address emerging adversarial ML techniques?
Vendors whose adversarial robustness claims cannot be substantiated with specific testing results and documented architectural controls should be viewed with appropriate scepticism. The adversarial ML threat to OT detection systems is well-documented in academic literature, and a vendor who is not engaging with it is either unaware of the threat or is choosing not to address it.
Incident response for adversarial ML events
The incident response framework described in Post 7 must be extended to address adversarial ML events , specifically, the scenario where the anomaly detection system has been compromised through adversarial techniques and may not be generating accurate alerts during an active attack.
The most dangerous adversarial ML scenario is one where an adversary has successfully evaded the anomaly detection system and is conducting an active OT intrusion while the detection system is providing false assurance that the environment is clean. The IR framework must include procedures for responding to this scenario: indicators that should trigger suspicion of detection system compromise even in the absence of alerts, fallback detection mechanisms that do not rely on the potentially compromised ML system, and escalation procedures that ensure operations and safety functions are notified when detection system integrity is uncertain.
Part 6: The research frontier , what is coming and what it means for OT
The adversarial ML research community moves quickly, and the techniques that represent the frontier today will be accessible to sophisticated adversaries within a few years. Understanding where the research is heading helps OT security architects design systems that will remain robust as the threat evolves.
Generative adversarial techniques for OT evasion. Generative adversarial networks (GANs) have been demonstrated in research as a mechanism for generating realistic-looking process telemetry that evades anomaly detection systems. A GAN trained on legitimate process data can generate synthetic process states that are statistically indistinguishable from normal operation but represent physically anomalous conditions. As GAN techniques become more accessible and as publicly available OT datasets provide training material, this technique is likely to become more practically accessible to adversaries.
Federated learning poisoning. As OT anomaly detection vendors move toward federated learning approaches , where models are trained collaboratively across multiple operator deployments without sharing raw data , new poisoning attack surfaces emerge. An adversary who has compromised one participant in a federated learning consortium can contribute manipulated gradient updates that influence the shared model in ways that benefit their attack objectives against other participants. The federated learning model that is appealing for privacy and regulatory reasons creates a new attack surface that requires specific adversarial robustness measures.
Automated adversarial attack tooling. The democratisation of adversarial attack techniques through open-source libraries , Adversarial Robustness Toolbox (ART), Foolbox, CleverHans , means that conducting adversarial attacks no longer requires deep ML research expertise. An adversary with operational access to an OT environment and access to process telemetry data can use these libraries to systematically probe the anomaly detection system’s decision boundaries with modest technical expertise. The implication is that adversarial ML attacks against OT detection systems are becoming accessible to a broader range of adversaries than the nation-state actors who represent the current leading edge of this threat.
Conclusion: Building detection systems that are robust by design
The case for ML-based anomaly detection in OT environments is not weakened by the adversarial ML threat. It is complicated by it. A detection system that is deployed without considering its adversarial robustness is not merely imperfect , it may provide false confidence that is operationally worse than no detection system at all, because it changes the human behaviour around it. Operators who believe they have comprehensive ML-based detection in place may reduce their vigilance in ways that create exposure precisely when the detection system has been compromised.
The response is to build detection systems that are robust by design: ensemble architectures that resist evasion through diversity, physics-informed constraints that anchor models to reality, cryptographic provenance that protects training data integrity, and governance processes that maintain robustness over the system’s operational life. These are achievable requirements, not aspirational ones. The research base for each of them is mature enough to support practical implementation.
What is required is the organisational commitment to treat adversarial robustness as a first-class requirement for OT anomaly detection deployments , not a research curiosity, not a future consideration, but a design requirement that must be satisfied before the system is deployed into a critical infrastructure environment.
The adversary targeting your OT environment is already thinking about your detection system. The architecture must assume that and design accordingly.
Key references and further reading
- MITRE ATT&CK for ICS , Impair Process Control / Inhibit Response Function , attack.mitre.org/matrices/ics/ , The adversary objective categories that adversarial ML attacks against OT detection systems serve.
- Adversarial Robustness Toolbox (ART) , IBM Research open-source library for adversarial attack and defence, referenced in Part 6 as an increasingly accessible adversarial attack toolkit.
- NIST AI 100-2 , Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations. The NIST reference document for adversarial ML threat categorisation used in Part 1.
- Cárdenas et al. , Attacks Against Process Control Systems , Foundational academic paper on the security of SCADA anomaly detection systems, providing the research basis for the poisoning and evasion vulnerability analysis in Part 2.
- Physics-Informed Neural Networks (PINNs) , Raissi, Perdikaris, Karniadakis , The foundational paper on physics-informed ML, the basis for the architectural control described in Part 3.
- Fortiphyd Logic , Anomaly Detection for ICS , Vendor documentation covering OT-specific anomaly detection architecture with adversarial robustness considerations.
- ENISA , Securing Machine Learning Algorithms , European Union Agency for Cybersecurity report on ML security, including the adversarial ML threat categories relevant to critical infrastructure.
- IEEE S&P / CCS / USENIX Security , The primary academic venues where adversarial ML research is published; monitoring recent proceedings is the most effective way to track the research frontier described in Part 6.
This post is part of an ongoing series on security architecture for critical infrastructure and energy systems. The next post examines zero trust architecture in hybrid OT/IT environments , the principles that survive translation from enterprise IT and the hard limits that no vendor will tell you about.
About the author: Infrastructure Architect with 14 years of experience spanning enterprise architecture, operational technology environments, and regulated digital infrastructure. Currently leading infrastructure architecture for a major energy operator. Holds CISSP certification. Previously Technical Director at a digital health startup. Views expressed are personal.