Can AI Learn What Normal Looks Like in an Industrial Network?

Learning “Normal” Before Detecting “Abnormal”

Industrial networks are often described as predictable.

A programmable logic controller may communicate with the same HMI every few milliseconds, while an engineering workstation connects only to a defined group of controllers and a historian continuously collects the same process variables. Remote maintenance may also follow tightly controlled paths and occur only during scheduled windows. Compared with conventional enterprise networks, where users regularly change applications, browse different websites, connect from multiple locations, and generate highly variable traffic, this makes Operational Technology appear particularly well suited to behavioural analysis.

That predictability raises an obvious question: if an industrial environment behaves consistently, can artificial intelligence simply learn what normal looks like and alert whenever something changes? In principle, yes, but the challenge lies in understanding why a deviation has occurred. A new connection to a PLC might indicate lateral movement, but it could just as easily come from a newly commissioned engineering workstation. A sudden increase in write operations may suggest unauthorised manipulation, while also being entirely legitimate during planned maintenance. Likewise, a controller entering a different operating mode could indicate malicious activity or simply reflect a normal production transition.

This is the central challenge for AI-driven OT security. The objective is not merely to identify behaviour that is statistically unusual, but to determine whether that behaviour makes sense for the assets, identities, protocols, process state, production conditions, and operational context involved. NIST SP 800-82 Rev. 3 notes that OT traffic is generally more deterministic than conventional IT traffic and recommends understanding normal network states, typical data flows, and device-to-device communications as part of network monitoring. That predictability creates a strong opportunity for machine learning, but operational context is what ultimately determines whether a detected deviation becomes a useful security signal or just another source of alert noise.

What Does “Normal” Actually Mean in OT?

A behavioural baseline is sometimes imagined as an average.

For example:

PLC-01 normally receives 500 requests per minute.

Anything significantly above or below that number might then be considered anomalous.

Real industrial behaviour is more complex.

Normal behaviour can include relationships between assets, communication protocols, command types, timing, production phases, identities, maintenance schedules, network zones, and process conditions.

For example, an engineering workstation may normally:

• Communicate with PLC-01, PLC-02, and PLC-03
• Use an approved industrial protocol
• Perform mostly read operations during production
• Conduct configuration activity during maintenance windows
• Be accessed by a defined group of engineering accounts
• Communicate through an expected network path
• Upload controller logic only when an approved change is taking place

The baseline is therefore not simply:

ENG-WS-01 communicates with PLC-01.

It is closer to:

ENG-WS-01 normally communicates with PLC-01 using these protocols, for these operations, at these times, under these process conditions, and as part of these authorised engineering activities.

That difference matters.

The more operational context the model understands, the more useful a deviation can become.

Why OT Can Be Easier — and Harder — for Behavioural Analysis

OT has characteristics that make anomaly detection attractive.

Many industrial communications are highly repetitive. PLCs continuously exchange information with HMIs, remote I/O, historians, supervisory systems, and other controllers. Network relationships may remain stable for months or years.

A model may therefore be able to learn patterns such as:

• Which devices normally communicate
• Which industrial protocols they use
• Which commands are common
• How frequently communication occurs
• Typical message sizes or request patterns
• Which systems normally initiate connections
• Expected operating modes
• Common process-state transitions
• Which engineering assets interact with specific controllers

This can make genuinely new behaviour stand out.

However, OT also contains legitimate exceptions that can look extremely suspicious.

• Production lines start and stop.
• Plants switch recipes.
• Equipment is commissioned.
• Firmware is upgraded.
• Engineers troubleshoot faults.
• Vendors perform remote maintenance.
• Controllers are replaced.
• Network architectures change.
• Emergency operating procedures may produce activity that has never appeared during the model’s learning period.

This creates a paradox.

OT behaviour may be more predictable than IT behaviour, but deviations can have much greater operational meaning — and a much greater chance of being caused by legitimate engineering activity.

What Can an AI Behavioural Model Learn?

An effective OT behavioural model should not rely on one type of anomaly.

Several dimensions can be analysed together.

Asset-to-Asset Relationships

One of the strongest baselines in an industrial environment is simply understanding who normally communicates with whom.

Consider:

PLC-01 normally communicates with:

• HMI-01
• HIST-01
• ENG-WS-02

If a finance workstation suddenly begins communicating with PLC-01, the relationship itself is unusual even before the content of the traffic is examined.

A model can learn a communication graph representing expected relationships between assets.

The detection becomes:

New source → critical PLC

rather than merely:

Network connection observed.

However, a new relationship is not automatically malicious. A replacement engineering workstation, newly deployed monitoring platform, or temporary maintenance system could create exactly the same anomaly.

Asset context must therefore be added before the activity is escalated.

Protocol and Command Behaviour

Knowing that two devices communicate is only part of the picture; the model can also learn how that communication normally takes place. An HMI, for example, may continuously read process values from a PLC while performing write operations only rarely, whereas an engineering workstation may legitimately perform both reads and writes but carry out logic downloads only during maintenance. These differences create distinct behavioural expectations for each asset relationship, making it possible to identify activity that is technically valid but unusual for the way those systems normally interact.

Normal:

HMI-01 → PLC-01 → repeated read operations

Potentially unusual:

HMI-01 → PLC-01 → configuration write

More unusual:

UNKNOWN-WS → PLC-01 → program modification

The industrial protocol itself may be entirely legitimate, yet the activity can still be anomalous when the observed operation does not match the expected relationship between the assets involved. This distinction is particularly important in OT, where malicious activity can rely on valid industrial protocols and authorised engineering capabilities rather than obviously malicious tools. As a result, a command may be technically valid while the context in which it is issued makes the behaviour suspicious.

Timing and Frequency

Industrial systems frequently operate according to predictable timing.

A controller may be polled every second. A historian may collect a particular value every ten seconds. A maintenance script may execute once per day.

Machine learning can establish expected frequency and timing patterns and identify deviations such as:

•  Sudden increases in command frequency
• Repeated connection attempts
• Activity at unusual hours
• Communication that becomes unexpectedly periodic
• Loss of an expected communication pattern
• New burst activity against several controllers
• Commands appearing in an unusual sequence

The absence of expected behaviour can also matter.

If a safety monitoring system normally exchanges data continuously with a controller and suddenly stops, the security signal may be the communication that did not happen.

Anomaly Does Not Mean Attack

This distinction is fundamental.

Suppose the model has learned that ENG-WS-02 normally performs read operations against PLC-07 during production.

At 02:17, it observes:

ENG-WS-02 → PLC-07 → program download

The activity is unusual.

But consider two possible contexts.

 Scenario A: Legitimate Maintenance

• Approved maintenance window: active
• Engineer: authorised
• Change request: approved
• Engineering workstation: expected
• Target PLC: documented
• Production state: maintenance
• Logic version after change: approved

The behaviour is anomalous relative to normal production, but operationally legitimate.

Scenario B: Security Concern

• Approved maintenance window: none
• Account: unusual
• Remote session: active
• Engineering workstation: expected
• Target PLC: critical
• Production state: active
• Logic version after change: unknown

The network behaviour may look almost identical.

The security meaning is completely different.

This is why an AI system should not simply ask:

Is this unusual?

It should also ask:

Is this unusual for the current operational context?

From Statistical Anomaly to Security-Relevant Anomaly

A raw anomaly score has limited value to a SOC.

Imagine an AI model reports:

Anomaly score: 0.94

That tells the analyst that the observation differs significantly from the model’s learned behaviour.

It does not explain whether the anomaly matters.

A stronger detection pipeline should enrich the anomaly with additional context.

For example:

Observed behaviour: New workstation communicating with PLC-07
Protocol: Industrial control protocol
Operation: Write command
Asset criticality: High
Production state: Active production
Source role: Corporate workstation
Previous relationship: None observed
Approved change: None
Recent activity: VPN authentication followed by access to an OT jump server

The individual anomaly has now become part of a security story.

A useful conceptual model could be expressed as:

Detection confidence = behavioural deviation × contextual mismatch × asset importance × supporting evidence

The calculation does not need to be a literal mathematical formula.

The purpose is to illustrate an important principle: statistical rarity should be only one component of OT detection.

Behaviour Happens in Sequences

Some of the most important industrial attacks may not produce one obviously malicious event.

Instead, they create a sequence of individually plausible actions.

Consider:

1. A vendor account authenticates remotely.
2. The login occurs outside its normal maintenance period.
3. A jump server is accessed.
4. An engineering workstation is reached.
5. Industrial programming software is launched.
6. A previously uncommon PLC is contacted.
7. Several read operations occur.
8. A configuration write follows.
9. The controller enters a different state.

Individually, many of these events could be legitimate.

The sequence is much more unusual.

Behavioural analysis therefore becomes more useful when the system can learn not only individual events but relationships between events.

Instead of detecting:

PLC write detected.

The objective becomes:

An unusual remote-access sequence resulted in unexpected engineering activity against a production controller.

This gives an analyst something that can actually be investigated.

The False-Positive Problem

Behavioural detection has an obvious weakness.

Industrial environments change.

If every deviation becomes a high-severity incident, analysts and engineers will quickly lose confidence in the system.

Common sources of legitimate anomalies include:

• Planned maintenance
• Emergency maintenance
• Production startup and shutdown
• Product or recipe changes
• Controller replacement
• Firmware upgrades
• New engineering workstations
• Temporary vendor access
• Network redesign
• Failover events
• Backup and recovery operations
• Commissioning
• Disaster-recovery exercises

An anomaly-detection system that ignores these conditions may correctly identify unusual behaviour while being operationally wrong about its significance.

For example:

New PLC communication detected.

may be technically accurate.

But if the PLC was commissioned that morning, the alert provides little value.

Reducing false positives therefore requires more than adjusting an anomaly threshold.

The system needs context explaining why the environment changed.

Baselines Should Understand Operating Modes

A single industrial environment may have several legitimate versions of normal.

Consider a manufacturing process with four states:

• Startup
• Active production
• Product changeover
• Maintenance

Network and process behaviour can differ significantly across these operating states. During active production, for example, PLC logic changes may be highly unusual, while the same activity could be entirely expected during scheduled maintenance. Startup conditions may also produce different communication volumes and process values from those seen during steady-state production, and product changeovers can introduce legitimate configuration or recipe changes. A single baseline applied across all of these states could therefore misclassify normal operational activity as suspicious. A more effective approach is to establish behavioural baselines according to the current operating state, recognising that what is normal during production may not be normal during maintenance. This type of contextual baseline is particularly important in industrial cybersecurity because the physical process provides operational information that conventional network analysis alone may not capture.

Model Drift: What Happens When Normal Changes?

A behavioural model is trained or calibrated using historical observations.

But industrial environments do not remain static forever.

• A plant may install new equipment.
• A production line may increase throughput.
• A controller may be replaced.
• A vendor may change its remote-support infrastructure.
• A new protocol may be introduced.
• An engineering workstation may assume responsibility for additional assets.
• Over time, legitimate behaviour moves away from the original baseline.

This is commonly described as model drift, where legitimate changes in the environment gradually move behaviour away from the original baseline. Continuous automatic retraining may appear to be an obvious solution, but in OT this needs to be handled carefully. If an attacker compromises an engineering workstation and slowly introduces a new communication pattern over several weeks, a system that automatically treats frequently observed behaviour as normal could eventually absorb that malicious activity into the trusted baseline.

The system should therefore distinguish between:

Behaviour we observe frequently.

and:

Behaviour we have sufficient confidence to consider legitimate.

That distinction is critical.

Baseline adaptation should incorporate change-management information, asset ownership, engineering validation, known production changes, and security review where appropriate.

Learning must not become automatic trust.

 

Not Every Asset Should Be Learned the Same Way

Industrial environments contain systems with very different functions.

A historian, engineering workstation, PLC, domain controller, firewall, HMI, and remote-access gateway should not necessarily be modelled using the same behavioural features.

For a PLC, valuable features might include:

• Communication peers
• Protocol operations
• Controller state
• Logic changes
• Write frequency
• Process-variable behaviour

For an engineering workstation:

• User identities
• Login times
• Remote-access history
• Engineering applications executed
• PLCs contacted
• Programming activity

For a remote-access gateway:

• Source locations
• Vendor identities
• Session times
• Destination systems
• Authentication behaviour
• Maintenance-window alignment

This is where OT asset classification becomes important.

AI should not simply learn traffic.

It should learn behaviour according to what the asset actually does.

Process Context Makes Behaviour More Meaningful

Network analysis might determine that PLC-04 received an unusual write command.

Process context may explain whether that matters.

For example:

• Was the process running?
• Was the controller responsible for a safety-relevant function?
• Did the command modify a normal operating parameter?
• Did a process value change afterwards?
• Did an alarm occur?
• Did the HMI display the same state as independent telemetry?
• Was another controller affected at the same time?
• The strongest detection may therefore combine cyber and physical observations.

For example:

Unexpected engineering session
→ PLC configuration modification
→ process threshold changes
→ unusual physical response

This is much more useful than treating each signal independently.

The goal is not to give AI autonomous control over industrial decisions.

It is to provide analysts and engineers with enough connected evidence to understand whether a cyber anomaly may have an operational consequence.

AI Should Explain Why Something Looks Abnormal

In a safety-critical environment, an unexplained score is not enough.

If a system tells an operator:

This activity is 97% anomalous.

the next question is obvious:

Why?

Useful behavioural detection should expose the contributing evidence.

For example:

This activity differs from the established baseline because the workstation has never communicated with this controller, the connection occurred outside an approved maintenance window, a write operation was observed, and the initiating identity normally has no engineering role.

This gives the analyst evidence that can be validated.

Explainability is particularly relevant in OT because decisions may involve systems responsible for production, safety, energy, water, transportation, or other critical functions.

NIST’s AI Risk Management Framework emphasises characteristics including reliability, safety, resilience, transparency, explainability, and appropriate human oversight throughout the AI lifecycle.

In industrial environments, these are not abstract AI-governance principles.

They directly affect whether operators can trust a detection enough to act on it.

Human Validation Remains Essential

AI can help analysts identify patterns across millions of events that would be difficult to detect manually, including unusual asset relationships, weak signals that only become meaningful when correlated, and deviations from established behavioural baselines. It can also help prioritise those deviations and explain which features made an event appear abnormal. However, the model may still lack important operational context that exists outside the available telemetry. An engineer may know that a controller was temporarily reconfigured because a pump had failed, a maintenance team may understand why a vendor connected outside the normal schedule, or an operator may recognise that an unusual process transition was caused by an emergency procedure. Because this contextual knowledge may not be visible to the detection system, human validation remains an essential part of the architecture, particularly in safety-critical OT environments.

For high-impact situations, the process should support:

AI detection → contextual enrichment → analyst review → OT engineering validation → controlled response

rather than:

AI detection → automatic production change

This is consistent with a broader principle already important in OT incident response: security controls must not create a larger operational problem than the activity they are attempting to contain.

Logstail Security Suite: Building the Context Around the Anomaly

Behavioural models depend on reliable telemetry and asset context.

A machine-learning system cannot determine that a workstation is communicating with an unusual PLC if it cannot identify the workstation, the PLC, or their previous relationships.

It cannot determine that an event occurred outside an approved pattern if the relevant security and operational evidence remains fragmented across unrelated tools.

The Logstail Security Suite provides the security-operations foundation for bringing monitoring, assets, alerts, cases, response workflows, and related security evidence into a shared operating layer.

Current Security Suite capabilities include SIEM monitoring, asset visibility, vulnerability information, cases, automated playbooks, and governance workflows.

For behavioural OT detection, this foundation can help connect observations such as:

• Identity activity
• Remote-access sessions
• Network events
• Asset information
• Vulnerability context
• Engineering-system activity
• Available OT telemetry
• Related alerts and cases

The objective is not to present conventional SIEM correlation as machine learning.

They solve different parts of the problem.

The Security Suite provides the evidence, asset context, investigation workflow, and operational history around an event.

AI-driven behavioural analysis can then help determine whether the behaviour represented by that evidence differs meaningfully from what the environment normally does.

Together, this supports a progression such as:

Collect evidence → understand assets → establish behaviour → detect deviations → add context → validate → respond

AICOT: Moving from Monitoring to OT-Native Behaviour Understanding

This is one of the areas where the AICOT — AI-Driven Cyber Defense Platform for Operational Technology Environments in Critical Infrastructure project becomes particularly relevant.

AICOT builds on Logstail’s existing SIEM and data-analytics capabilities and is designed to integrate advanced machine learning, anomaly detection, OT protocol analysis, threat intelligence, real-time monitoring, and response capabilities.

The project specifically recognises two challenges that behavioural OT security must solve.

First, AI models require domain-specific industrial data, while high-quality labelled OT attack datasets remain limited.

Second, conventional IT-oriented security tools do not always provide the explainability and adaptability required for safety-critical environments.

Behavioural analysis provides one path forward.

Instead of requiring a model to recognise every possible future attack in advance, the system can learn characteristics of legitimate industrial behaviour and identify meaningful deviations.

That could include understanding:

• Expected communication relationships between industrial assets
• Normal protocol operations
• Typical engineering activity
• Process and production states
• Changes in communication frequency or sequence
• Unusual combinations of otherwise legitimate actions
• Behaviour inconsistent with asset roles
• Deviations that may indicate zero-day or previously unseen activity

However, the objective is not simply to produce an anomaly score.

AICOT’s broader direction is toward OT-native detection in which machine learning, protocol analysis, asset context, threat intelligence, and operational understanding contribute to a higher-confidence security decision.

The platform is intended to be validated in realistic OT pilot environments, helping ensure that the resulting capabilities are applicable to real industrial conditions rather than only controlled datasets.

This matters because the real test of an OT behavioural model is not whether it can detect something unusual.

It is whether it can separate meaningful security deviations from legitimate industrial change.

Conclusion

The most useful question is therefore not:

Can AI detect something it has never seen before?

It is:

Can AI explain why what it is seeing does not make sense for this industrial environment?

The Logstail Security Suite provides a security-operations foundation for collecting, correlating, and investigating the evidence surrounding those behaviours. AICOT extends that direction toward advanced machine learning, anomaly detection, OT protocol analysis, and context-aware behavioural monitoring specifically designed for critical infrastructure.

The goal is not to replace industrial expertise with an algorithm.

It is to give security analysts and OT engineers a better way to recognise when apparently legitimate activity no longer fits the way the industrial system is supposed to operate.

Because in OT, unusual behaviour is only the beginning of the investigation.

Context determines whether it is a threat.

Follow the AICOT project on LinkedIn and X for project updates and practical insights into AI-driven OT cybersecurity.

AICOT is funded by the European Union’s Digital Europe Programme under Grant Agreement No. 101249826. Views expressed are those of the authors and do not necessarily represent the European Union or the European Cybersecurity Competence Centre.

Contact Our Experts or Sign Up for Free