It may target an information object that the HMI rarely controls. It may occur outside the normal operating sequence. It may appear at an unusual frequency. It may conflict with telemetry from related equipment. Or it may originate from a legitimate engineering workstation that has itself been compromised.

This is where AI becomes particularly interesting in IEC 104 security.

The most useful role for AI is not replacing IEC 62351, firewalls, access control, network segmentation, or deterministic security rules. Its real value is adding a behavioral and contextual layer capable of asking a different question:

The message is technically valid, but does it make operational sense?

IEC 104 Security Is More Complex Than “An Insecure Protocol”

IEC 60870–5–104 is widely used for telecontrol and SCADA communication, particularly in electric power systems. It essentially brings IEC 60870–5–101 application functionality onto TCP/IP networks.

The protocol was created in an operational environment where trust assumptions were very different from the threat landscape facing modern industrial networks. This is one reason IEC 104 is frequently described as having limited native security capabilities.

However, saying that IEC 104 simply “has no security” is increasingly inaccurate.

Modern IEC standards have evolved to address these issues. IEC 62351–5 defines security mechanisms for communication protocols derived from IEC 60870–5. More recently, IEC TS 60870–5–7:2025 defines how security mechanisms can be applied specifically to IEC 60870–5–101 and IEC 60870–5–104 environments.

These mechanisms introduce stronger authentication, integrity protection, transport security, and integration with role-based access control.

This changes the security discussion.

The challenge is no longer only whether an attacker can modify an IEC 104 message in transit. A more difficult problem is detecting malicious or abnormal activity when the traffic itself is authenticated, structurally correct, and sent through an apparently legitimate communication path.

Cryptography can help prove that a message came through an authenticated security context and was not modified during transmission.

It cannot always determine whether executing that command is operationally appropriate.

That distinction creates an important role for behavioral analytics and AI.

Why IEC 104 Is Well Suited to Behavioral Detection

OT environments have one major characteristic that defenders can exploit: communication behavior is usually much more deterministic than in traditional IT networks.

In a corporate environment, users may access hundreds of websites, cloud applications, APIs, and external systems. Traffic patterns change continuously.

A substation or industrial control environment is different. Specific systems normally communicate with specific devices using relatively stable protocols and operational patterns.

IEC 104 provides even more structure.

A monitoring system does not need to observe only a network connection such as:

Control Center → RTU → TCP/2404

A protocol-aware system can understand relationships such as:

Control Center → RTU → ASDU Type → Cause of Transmission → Common Address → Information Object

This creates a much richer behavioral model.

The system can learn not only which devices communicate with each other, but also what kinds of operational actions normally occur between them.

Suppose an RTU usually receives a narrow set of commands from one supervisory system. Suddenly, the same authorized supervisory system begins issuing an unusual command type toward information objects that historically only generated telemetry.

A firewall sees authorized communication.

A traditional signature sees a syntactically valid IEC 104 message.

A behavioral system sees a deviation from the operational baseline.

That difference is important.

What Should AI Actually Learn From IEC 104?

This is where many AI-for-OT projects become too generic.

Training a machine-learning model only on source IP, destination IP, packet size, TCP flags, and connection duration may create a useful network IDS, but it does not necessarily create an IEC 104-aware security system.

The real value comes from combining multiple layers of context.

At the network layer, the model can analyze source and destination systems, session duration, connection frequency, packet rate, and inter-arrival timing.

At the IEC 104 layer, it can analyze frame categories, ASDU Type IDs, Causes of Transmission, Common Addresses, Information Object Addresses, command frequency, and communication sequences.

At the operational layer, it can examine normal command patterns, expected telemetry relationships, time-of-day behavior, maintenance windows, and common process sequences.

Asset information can provide additional context. A security platform should know whether a system is an HMI, RTU, gateway, historian, engineering workstation, or operator station, and how critical that asset is to the process.

Identity information adds another dimension. An IEC 104 command becomes significantly more interesting when it can be correlated with an operator login, privileged-access session, jump-server connection, or unusual authentication event.

The goal is therefore not simply packet anomaly detection.

The goal is operational behavior detection.

The Most Dangerous IEC 104 Event May Be Completely Valid

Imagine an IEC 104 connection between a control center and RTU-17.

For most of the day, telemetry behaves normally.

At 13:02:11, the monitoring platform sees normal telemetry.

At 13:02:13, more normal telemetry arrives.

At 13:02:15, a control operation is issued.

One second later, another control operation appears.

Then another.

Finally, a control request targets an information object that is almost never operated remotely.

Every individual message may be technically valid.

The source IP is allowed. The TCP connection is established correctly. The protocol format is valid. Authentication may even be successful.

But the sequence is abnormal.

A useful AI system should not simply produce an alert saying:

“Anomaly score: 0.94.”

It should provide operational context.

For example:

Command frequency from HMI-01 to RTU-17 is significantly above its historical baseline. The targeted Information Object Address has not previously been controlled by this source during the observed baseline period. The activity is also occurring outside the normal operational pattern.

This type of explanation matters because OT engineers cannot reasonably investigate black-box anomaly scores.

In critical infrastructure, explainability is part of security engineering.

Why a Hybrid Detection Model Makes More Sense

There is a tendency in cybersecurity to assume that a more sophisticated neural network automatically creates a better detection system.

That is not necessarily true in OT.

IEC 104 environments are particularly well suited to hybrid detection.

Some conditions should be handled by deterministic rules because they are already known to be invalid or unacceptable. Unexpected communication pairs, prohibited command categories, unauthorized addressing relationships, or violations of network zoning are examples.

Statistical baselines can then identify unusual timing, packet rates, command frequency, or session behavior.

Machine-learning models can examine deviations that were never explicitly encoded into rules.

Sequence-based models can analyze how IEC 104 events evolve over time rather than evaluating each packet independently.

Finally, asset, identity, process, and security telemetry can be correlated to produce a contextual risk score.

A practical architecture could therefore look like this:

IEC 104 Traffic → Protocol Parser → Feature Extraction → Rules → Behavioral Baseline → ML Anomaly Detection → Context Correlation → SOC Investigation

The principle is simple.

Use deterministic controls where deterministic logic works best.

Use AI where behavior is too complex to describe with static rules.

Machine Learning for IEC 104 Is Already More Than a Theory

IEC 104 has already become an active research area for intrusion detection and machine learning.

Several public datasets now contain labeled IEC 60870–5–104 traffic covering simulated attack scenarios such as unauthorized commands, denial-of-service behavior, and man-in-the-middle activity.

Research has also evaluated machine-learning approaches including Decision Trees, Random Forests, Support Vector Machines, and deep-learning models against IEC 104 traffic.

Some experimental studies have reported accuracy above 90 percent under laboratory conditions.

However, the important lesson is not the exact percentage.

A laboratory dataset is not a substation.

Real OT environments contain firmware upgrades, maintenance activities, new RTUs, engineering changes, configuration updates, communication failures, and process changes that may significantly alter network behavior.

This creates one of the most important challenges for AI in OT security: concept drift.

A model may learn that a behavior is abnormal today, while an approved operational change makes that same behavior normal next month.

Production AI therefore requires controlled re-baselining, model versioning, feedback from analysts, change-management integration, and continuous validation.

AI should learn from the environment.

It should not silently redefine the environment.

IEC 62351 and AI Solve Different Security Problems

IEC 62351 and behavioral AI should not be treated as competing approaches.

They solve different problems.

IEC 62351 provides mechanisms for authentication, integrity protection, confidentiality, and secure communication.

AI does not replace these controls.

At the same time, cryptographic security does not eliminate abnormal behavior.

An authenticated operator can perform an unusual action.

An authenticated engineering workstation can become compromised.

A legitimate application can malfunction.

An authorized command can occur at the wrong time.

A cryptographically protected session can still contain operationally dangerous behavior.

IEC 62351 therefore answers one important question:

“Can I trust the communication and its security context?”

Behavioral AI answers another:

“Does this activity make sense?”

A mature IEC 104 security architecture needs both.

Encryption Creates a New Visibility Problem

There is also an interesting side effect when stronger IEC 104 security is deployed.

Encryption improves confidentiality and integrity, but it can reduce the visibility available to traditional passive network monitoring systems.

If a monitoring sensor can no longer inspect application-level IEC 104 semantics, security architecture must evolve.

This does not mean encryption should be avoided.

It means monitoring must move beyond packet inspection.

Security teams may need to correlate telemetry from IEC 104 gateways, SCADA applications, RTUs, authentication systems, firewalls, endpoint tools, privileged-access platforms, historians, and process-control systems.

In other words, stronger protocol security increases the importance of observability architecture.

The future OT SOC may rely less on one network sensor and more on distributed security telemetry.

Where Generative AI Actually Fits

Large language models should not sit directly inside the IEC 104 control loop deciding whether a breaker command should be executed.

Industrial control requires deterministic, predictable behavior.

Introducing a probabilistic language model directly into that decision path would create unnecessary operational risk.

Generative AI is much more valuable above the control layer.

Imagine that an IEC 104 behavioral engine identifies an unusual command sequence.

The firewall confirms the source host.

The asset inventory identifies it as an engineering workstation.

Identity logs identify the active user.

The historian records a corresponding process change.

Endpoint security detects an unusual process execution on the same workstation shortly before the IEC 104 activity.

A traditional SOC may receive five separate alerts.

A security-focused LLM could instead summarize the investigation context:

Engineering workstation ENG-03 initiated a rare IEC 104 control operation toward RTU-17 outside the normal maintenance window. Similar activity has not been observed during the baseline period. Endpoint telemetry from ENG-03 also indicates unusual process execution shortly before the control operation. Validation with the control-room operator is recommended.

This is a far more realistic use case for GenAI in critical infrastructure.

The language model is not controlling the industrial process.

It is helping humans understand security evidence faster.

How I Would Deploy AI Monitoring in an IEC 104 Environment

For production OT environments, I would start with a strictly passive architecture.

IEC 104 traffic should be observed through appropriate monitoring infrastructure without introducing additional dependencies into the control path.

A protocol-aware parser can extract IEC 104 metadata and enrich it with asset information.

Deterministic detection rules can identify obvious policy violations.

Behavioral models can learn normal communication patterns.

Machine learning can identify unusual combinations or sequences.

Alerts can then be forwarded to the OT SOC or SIEM for investigation.

Initially, the system should not automatically block IEC 104 operations based only on AI output.

The first goal should be understanding.

Which anomalies represent legitimate operational activity?

Which are caused by maintenance?

Which are configuration errors?

Which indicate actual security risk?

This learning period is critical because a security control that incorrectly disrupts an industrial process may introduce more operational risk than the threat it was designed to stop.

If you are working on OT/ICS security and want to move from concepts to a more structured assessment approach, I have also prepared an OT Security Toolkit covering practical controls, assessment points, and operational security considerations for industrial environments.

You can explore it here: https://techsavant013.gumroad.com/l/ot-security-toolkit