OT Security Monitoring: What to Log and Why


Effective OT security starts with high-quality logs from the right places. Prioritise PLCs, HMIs, historians, firewalls and remote access. Capture the fields analysts actually use. Turn logs into detections that matter, retain them long enough for audits, and design a clean pipeline from plant sensors to your SIEM.

KEY TAKEAWAYS

• Start where it matters: controllers, consoles, historians, borders and remote access.

• Write rules for logic, modes, access and anomalies. Map to ATT&CK for ICS.

• Prove compliance with defined retention, integrity controls and synchronised time.

Prioritized log sources and fields

Start with assets that change process state or grant access. In practice: PLCs, HMIs/engineering stations, historians, firewalls and remote access concentrators. Where devices cannot emit rich logs, supplement with network sensors tapping protocol payloads. Keep OT device constraints in mind to avoid impacting availability.

Minimum fields to retain per event: precise timestamp with timezone, event type, user or service ID, device ID or asset tag, source and destination IP, command or function invoked, result and a unique event ID. Use structured JSON and consistent schemas to ease correlation across plants and vendors.

Priority sources in OT environments: 1) safety-critical devices and lines, 2) internet-exposed OT assets, 3) assets at network boundaries. Where device logs are weak or proprietary, log traffic to and from the device at a sensor or gateway.

Detections that matter

Focus on rules that surface unsafe changes, new pathways and privilege escalation in OT.

  • PLC logic change or program download from any user or host not on an allowlist. Map to ATT&CK for ICS Modify Program (T0889) and Modify Controller Tasking (T0821). Alert plus forced approval workflow.
  • Operating mode change to PROG/REMOTE on a running controller, or key-switch state drift. Night or weekend equals high severity. Maps to Change Operating Mode (T0858) and Detect Operating Mode (T0868).
  • Manipulation of control events: setpoint edits outside maintenance windows; alarm thresholds lowered; HMI tag remaps. Maps to Manipulation of Control (T0831).
  • New remote access path: fresh VPN account, new jump host, sudden admin group membership.
  • Historian anomalies: mass reads or exports from unfamiliar users or tools.

Ground your rules in protocol-aware telemetry and device semantics. Tie alerts to plant context and work orders so SOC can decide in minutes, not hours.

Logs are also useful when performing auditing and forensic analysis, supporting internal investigations, establishing baselines, and identifying operational trends and long-term problems.

Karen Kent, NIST SP 800-92, Guide to Computer Security Log Management.

Retention and evidence for audits

Set retention by risk, legal duty and dwell time. Guidance from government logging best practices notes intrusions can persist 70–200 days before discovery, so keep hot searchable logs for months and cold archives longer to support investigations. Use tiering to control cost while staying audit-ready.

For NIS2 evidence, document procedures, define log retention periods, enforce access control, and ensure time synchronisation across assets. Show redundant storage, health monitoring of the logging stack, and proofs that expired data is deleted. These elements are called out as examples of evidence in ENISA’s implementation guidance.

Protect integrity in transit and at rest with TLS 1.3 and cryptographic verification, and isolate your SIEM or data lake to limit tampering. Back up, restrict delete rights, and record access to the logging environment itself.

No logs, no truth.

Without trustworthy logs, you cannot detect unsafe changes, prove compliance, or reconstruct incidents across plants.

Pipeline from sensors to SIEM

Design for low impact, normalisation and actionability.

  • Collect: device logs from PLCs, HMIs, historians and firewalls. Where logs are thin, deploy SPAN/TAP sensors with DPI for ICS protocols, and broker site telemetry via MQTT where appropriate. Use JSON and automated normalisation to a common schema.
  • Substations: capture IEC 61850 events. Configure IEDs to report virtual inputs via MMS to a concentrator and forward to your log platform. Track GOOSE publish/subscribe status for protection events.
  • Aggregate to a hardened, central data lake, then forward curated streams to SIEM/XDR for correlation with IT identity and ticketing.
  • Orchestrate: bind detections to SOC playbooks that include OT-safe steps and plant escalation trees.

Outcome: fewer blind spots, faster triage, and repeatable incident response across sites.

FAQ

What OT logs should I enable first?

Start with PLC program changes, controller mode state, HMI user actions, historian queries, firewall denies and VPN sessions.

How long should we retain OT logs?

Keep hot data for rapid search and cold archives for months or more, driven by risk, regulation and dwell time evidence.

How do we prove NIS2 logging compliance?

Document procedures, define retention, secure access, synchronise time, store redundantly and keep evidence of reviews.

What if PLCs don’t emit detailed logs?

Capture network communications and payloads to and from devices, and enrich with engineering context.


About the Author

Liam Rose

I founded this site to share concise, actionable guidance. While RFID is my speciality, I cover the wider Industry 4.0 landscape with the same care, from real-world tutorials to case studies and AI-driven use cases.