OT security alerts are only valuable when they transform industrial telemetry into clear, prioritised actions. PLC state changes, engineering workstation activity, HMI events, firewall sessions, remote-access logs, authentication records, process measurements, asset data, and vulnerability findings can all reveal security-relevant behaviour.

The challenge is not collecting more data. It is determining which events represent normal industrial operations, which indicate an equipment or configuration problem, and which could be part of a cyberattack affecting production, safety, or critical services.

Effective OT security alerts must identify the affected asset, explain its role in the physical process, determine whether the activity was authorised, and provide the SOC and OT engineering teams with a safe response path.

An effective OT security alert must therefore answer more than:

What happened?

It must also answer:

• Which industrial asset was affected?
• What role does that asset have in the physical process?
• Was the activity expected and authorised?
• Did it occur during an approved maintenance window?
• Which user, workstation, remote connection, or external service initiated it?
• Could the event affect availability, safety, product quality, or environmental controls?
• What should the SOC and OT engineering teams do next?

This is how industrial telemetry becomes an actionable security decision.

The Rockwell PLC Campaign: A Real-World Warning

A recently reported campaign demonstrates why OT telemetry must be correlated with operational context.

According to a July 23, 2026 report based on a joint CISA and FBI advisory, attackers targeted internet-connected PLCs used in government, water, wastewater, and energy environments. The reported activity involved Rockwell Automation CompactLogix and Micro850 controllers, as well as Schneider Electric and Siemens systems.

The attackers reportedly used legitimate engineering software to download PLC project files, modify control logic, alter reusable program modules, and manipulate information presented through HMI and SCADA interfaces. In one case, modified logic preserved enough functionality to keep parts of the process running while overriding controls associated with safe operating limits.

This distinction matters.

Traditional IT security monitoring may identify a successful login, an SSH connection, a software execution event, or network traffic from an unusual address. Each signal can appear relatively ordinary when analysed independently.

Inside an OT environment, however, the same activity may represent an attacker:

1. Accessing an exposed remote-management device.
2. Authenticating to an engineering workstation.
3. Launching approved vendor programming software.
4. Uploading modified logic to a PLC.
5. Disabling alarm or shutdown functions.
6. Manipulating HMI data to hide the physical impact.

The tools may be legitimate. The authentication may technically succeed. The network traffic may use an approved industrial protocol.

The malicious behaviour emerges from the sequence, context, timing, asset role, and operational consequence.

Why OT Alerting Is Different from IT Alerting

IT security commonly prioritises confidentiality, integrity, and availability. OT security must consider those principles while placing additional emphasis on:

• Human safety
• Production continuity
• Process integrity
• Equipment protection
• Environmental impact
• Service availability
• Deterministic and time-sensitive operations

In an enterprise IT environment, isolating an endpoint or disabling a user account may be an appropriate automated response.

In an industrial environment, automatically blocking an engineering workstation or interrupting PLC communication could stop production or interfere with a safety-critical process. OT response workflows therefore require more context, stronger approval controls, and close coordination between security analysts and plant engineers.

Τhis distinction is described by highlighting that OT environments include PLCs, HMIs, historians, engineering workstations, SCADA platforms, and protocols such as OPC UA, MQTT, and Modbus. The objective is not simply to ingest these signals, but to connect them with asset importance, process function, vulnerabilities, ownership, and potential safety or availability impact.

From Raw Telemetry to an Actionable Alert

A mature OT detection pipeline can be divided into five stages:

1. Collect Telemetry Across the IT/OT Boundary

OT attacks rarely remain inside a single technology layer. Relevant evidence may exist across:

• PLCs, RTUs and industrial controllers
• HMIs and SCADA servers
• Engineering workstations
• Industrial historians
• Windows and Linux systems
• Firewalls and network-security devices
• VPN and remote-access services
• Jump servers
• Identity providers and directory services
• Vulnerability-management platforms
• Asset inventories
• Cellular routers and industrial modems
• Cloud-hosted vendor services
• External attack-surface data

Logstail Platform can provide a central security view of logs, events, network information, identity activity, vulnerabilities, and OT-supporting evidence from connected environments.

The goal is not to send every sensor measurement directly into a SIEM. Continuous process telemetry can generate enormous volumes of data and unnecessary noise.

Instead, organisations should collect or derive security-relevant events such as:

• Controller mode changes
• PLC program uploads and downloads
• Firmware or configuration modifications
• New engineering connections
• Authentication failures
• Remote sessions outside approved hours
• Unexpected industrial protocol commands
• Alarm suppression
• Safety-limit changes
• New communications between network zones
• Access from unmanaged systems
• Deviations from known process states

2. Normalise Assets, Identities and Events

The same device may appear under several identifiers:

• IP address
• MAC address
• Hostname
• PLC name
• Asset tag
• Serial number
• Engineering project name

Without entity resolution, the SIEM may treat these identifiers as unrelated assets.

Telemetry should be normalised into a shared model containing fields such as:

Context	Example
Source identity	Vendor engineer account
Source asset	Engineering workstation EW-04
Access path	External VPN → jump server → OT network
Destination asset	Packaging PLC-02
Asset function	Controls conveyor speed and emergency stops
Protocol	EtherNet/IP or CIP
Action	Program download
Maintenance status	No approved window
Change reference	No matching change ticket
Process state	Production active
Operational impact	High
Safety relevance	Critical

This enrichment turns an isolated network event into something an analyst can interpret.

3. Establish Operational Baselines

Static signatures and indicators of compromise remain useful, but they are not enough for OT.

Industrial attacks may use legitimate accounts, trusted programming tools, vendor protocols, and authorised communication paths. Behavioural baselines help identify when legitimate functionality is being used in an abnormal way.

Useful baselines include:

• Which engineering workstations normally communicate with each PLC
• Which users are permitted to perform program changes
• Normal maintenance windows
• Expected controller operating modes
• Typical communication patterns between network zones
• Normal volumes of write commands
• Approved firmware and logic versions
• Expected HMI-to-PLC relationships
• Standard remote-access locations
• Usual process ranges and state transitions

A new communication path is not automatically malicious. A new communication path combined with an unusual login, an unapproved programming command, and a safety-limit change is a different story.

4. Correlate Events into Attack Sequences

The strongest OT detections often combine events that look low-risk individually.

Consider the following sequence:

1. A vendor account connects through the VPN at 02:15.
2. The connection originates from a previously unseen location.
3. No maintenance activity is scheduled.
4. The account authenticates to a jump server.
5. The jump server opens a session to an engineering workstation.
6. Vendor programming software starts.
7. The workstation communicates with a safety-relevant PLC.
8. A program download occurs.
9. The active PLC logic no longer matches the approved baseline.
10. An HMI alarm is disabled shortly afterwards.

A basic monitoring system may generate ten separate alerts.

An effective IT/OT monitoring platform should create one correlated incident:

Unauthorised remote engineering activity resulted in a logic change on a safety-relevant PLC during active production.

That incident should preserve the identity, network, endpoint, asset, vulnerability, process, and change-management evidence within a single timeline.

Logstail’s SIEM can collect and correlate identity, remote-access, endpoint, network, asset, vulnerability, and OT-supporting evidence. Its SOAR capabilities can then create cases, enrich evidence, notify the relevant teams, and guide response through controlled playbooks.

5. Prioritise According to Operational Risk

Traditional alerts are often prioritised using technical severity alone.

OT alert prioritisation should incorporate:

• Asset criticality
• Process function
• Safety relevance
• Production state
• Exposure to external networks
• Presence of exploitable vulnerabilities
• Confidence that the activity is unauthorised
• Potential physical consequences
• Availability of compensating controls

A failed login against an isolated test PLC should not receive the same priority as a successful logic change on a controller managing water treatment, energy distribution, or emergency shutdown functions.

A practical OT risk score might be expressed as:

Alert priority = detection confidence × asset criticality × operational impact × exposure level

The calculation does not need to be mathematically complex. Its purpose is to ensure that the SOC investigates what matters to the physical operation—not merely what produced the loudest technical signal.

High-Value OT Detection Scenarios

Unauthorised PLC Program Modification

Trigger when:

• A PLC project upload or download is detected.
• The source is not an approved engineering workstation.
• The user lacks an authorised change request.
• The activity occurs outside a maintenance window.
• The logic hash differs from the known-good baseline.

Increase severity when the controller supports safety, shutdown, chemical dosing, pressure, temperature, speed, or other critical operating limits.

Suspicious Engineering Tool Usage

Trigger when vendor programming software runs on:

• A non-engineering workstation
• A newly provisioned system
• A jump server
• A system accessed through an unusual remote session
• A workstation associated with a compromised identity

This is especially valuable because attackers may use approved engineering software rather than custom malware, as reported in the recent PLC campaign.

Alarm or Safety-Logic Suppression

Trigger when:

• An HMI alarm is disabled.
• A shutdown instruction is modified.
• A safety threshold changes.
• A reusable logic module is deleted or replaced.
• The displayed process state conflicts with independent telemetry.

These changes should be correlated with recent authentication, remote-access, and engineering workstation activity.

IT-to-OT Lateral Movement

Trigger when:

• A user authenticates remotely.
• The user accesses a jump server or dual-homed workstation.
• New traffic appears toward an OT network segment.
• The same identity or source begins communicating with critical industrial assets.

Logstail’s unified model is particularly relevant here because evidence can be connected across identity systems, VPN services, endpoints, firewalls, asset inventories, vulnerabilities, and available OT telemetry.

Exposure Followed by Exploitation Activity

Trigger when:

• A previously unknown internet-facing service is discovered.
• The service exposes remote access, management, VPN, modem, or industrial functionality.
• Authentication attempts or suspicious sessions subsequently target the asset.
• Internal telemetry shows movement toward an engineering workstation or OT segment.

This detection requires external visibility as well as internal monitoring.

Logstail EASM: Detecting the Entry Point Before the Incident

The Rockwell PLC campaign reportedly relied heavily on exposed systems, weak access controls, and legitimate engineering capabilities rather than a new zero-day vulnerability.

This makes External Attack Surface Management an essential part of OT defence.

Logstail EASM is designed to identify external assets such as:

• Unknown domains
• Cloud resources
• Certificates
• Shadow IT
• Unmanaged services
• Risky internet-facing infrastructure

It then helps teams prioritise exploitable exposure and reduce internet-facing risk.

In an IT/OT architecture, this can reveal:

• Forgotten VPN gateways
• Exposed industrial modems
• Remote desktop services
• Vendor-management portals
• Test environments
• Misconfigured firewalls
• Publicly reachable monitoring systems
• Cloud assets connected to plant operations

EASM identifies where the attack path may begin.

The Logstail Platform can then connect that exposure with internal authentication, network activity, monitored assets, vulnerabilities, incidents, remediation ownership, and response workflows.

This creates a continuous process:

Discover exposure → validate ownership → assess risk → monitor activity → correlate incidents → remediate the root cause

Logstail Academy: Building Human Detection Capability

OT security cannot be solved through tooling alone.

SOC analysts need to understand industrial processes and protocols. Plant engineers need to recognise cyberattack patterns. Incident responders must understand why an action that is safe in IT may be dangerous in OT.

Logstail Academy provides SOC-focused training through guided learning paths, hands-on labs, practical exercises, and realistic attack scenarios.

Its OT and ICS training catalogue includes subjects such as:

• The ICS cyber-threat landscape
• Adversary tactics in industrial environments
• Securing ICS networks and architecture
• Modbus, OPC UA and MQTT security
• Monitoring and threat detection
• Incident response and forensics
• MITRE ATT&CK for ICS
• Simulated industrial attacks
• Alert building and tuning
• SOC-to-OT coordination

This closes an important gap: organisations do not merely deploy detections—they train their people to interpret, validate, tune, and respond to them safely.

AICOT: Extending Logstail’s SIEM and SOAR for OT

Logstail is also leading the AICOT project: AI-Driven Cyber Defense Platform for Operational Technology Environments in Critical Infrastructure.

The EU-funded project is implemented through a single-member consortium led by Logstail, with Logstail responsible for coordination, end-to-end platform development, AI research, secure cyber-threat-intelligence exchange, pilot deployment, and validation.

AICOT builds on Logstail’s existing SIEM and data-analytics capabilities and is intended to integrate:

• Advanced machine learning
• Anomaly detection
• OT protocol analysis
• Threat intelligence
• Real-time monitoring
• Threat detection
• Response capabilities

The objective is to deliver a modular, production-ready OT cybersecurity platform validated in realistic pilot environments.

AICOT is expected to extend Logstail’s SIEM and SOAR foundation with deeper OT-native capabilities, including stronger protocol understanding, behaviour analysis, risk prioritisation, and context-aware response support.

The project also targets proactive detection using generative and adversarial AI, privacy-preserving CTI sharing, realistic OT pilot deployments, and support for European digital sovereignty.

This evolution is important because the next generation of OT defence must understand more than logs.

It must understand:

• How an industrial asset normally behaves
• Which devices are permitted to communicate
• Whether a command is appropriate for the current process state
• Whether an observed sequence could affect physical operations
• Whether several weak signals form a coordinated attack
• Which response action is safe for that specific environment

Conclusion

Industrial telemetry becomes valuable security intelligence only when it is connected to operational context.

A PLC command, VPN login, engineering tool execution, firewall session, logic change, or external exposure may appear harmless in isolation. When those signals are correlated across identities, assets, vulnerabilities, network zones, maintenance schedules, and process functions, they can expose an attack before it causes physical disruption.

The recent targeting of internet-connected PLCs shows that OT attackers do not always need a sophisticated zero-day. Exposed assets, weak access controls, legitimate engineering tools, and limited cross-domain visibility may be enough.

Logstail addresses this challenge through a connected ecosystem:

• SIEM and monitoring to collect, normalise, detect, and correlate IT and OT evidence.
• SOAR and case management to coordinate controlled response workflows.
• EASM to discover exposed infrastructure before attackers exploit it.
• Logstail Academy to develop practical SOC and OT-security skills.
• AICOT to extend the platform with AI-driven, OT-native monitoring, protocol analysis, anomaly detection, threat intelligence, and context-aware response.

The objective is not simply to generate more OT alerts.

It is to generate fewer, higher-confidence incidents that tell security analysts and plant engineers what happened, why it matters, what may be affected, and how to respond without creating additional operational risk.

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

The AICOT project has received funding from the European Union’s Digital Europe Programme under Grant Agreement No. 101249826. Views and opinions expressed are those of the authors and do not necessarily reflect those of the European Union or the European Cybersecurity Competence Centre.

Contact Our Experts or Sign Up for Free