Log aggregation in operational technology is the practice of collecting log records from many scattered sources, PLCs, HMIs, switches, firewalls, servers, and gateways, and forwarding them into one central, protected store. It is the plumbing layer of security and operations visibility: before anyone can analyze events or hunt for threats, the raw log data has to be gathered off the devices that produce it and kept somewhere it cannot be quietly altered. Aggregation is not analysis; it is the disciplined act of getting every device's record into one place, in a consistent form, before it is lost, overwritten, or tampered with. A SIEM correlates and alerts, but it can only work on what aggregation has already collected.
Log Aggregation in one line: Log aggregation in OT is the collection of log records from distributed control-system and network devices into a single centralized, tamper-evident repository, typically over syslog or an agent, so events are preserved consistently for later analysis, retention, and forensics. It is the collection layer beneath a SIEM: aggregation gathers and stores the raw logs, while the SIEM correlates and alerts on them.
An OT environment produces logs in many places and formats. Network gear, switches, firewalls, and routers, emit syslog messages about link states, denied traffic, and configuration changes. Servers and HMIs generate operating-system and application logs about logins, service starts, and errors. PLCs and controllers keep more limited internal records, often reachable only through the engineering software or a diagnostic buffer, so their events may reach the aggregator indirectly through a gateway or a polling service. The job of aggregation is to pull all of these into one pipeline despite their different origins.
The dominant transport for aggregation is syslog, a simple protocol where devices forward log lines to a central collector. Where syslog is not available or not trustworthy on its own, a lightweight agent or a forwarder runs on the host and ships logs reliably, sometimes buffering locally when the network is down so nothing is lost during an outage. On OT networks, this collection traffic has to respect the same segmentation the rest of the network does: log forwarders sit inside the appropriate zone, and their flows to the aggregator are explicit, permitted paths rather than ad hoc connections that punch through zone boundaries.
Because devices timestamp and format events differently, a good aggregation layer normalizes as it collects, at least enough to make records comparable. Consistent, synchronized time across all sources is essential, because reconstructing what happened during an incident depends on being able to line up events from a firewall, an HMI, and a controller on one clock. Without disciplined time synchronization, aggregated logs become a pile of records that cannot be reliably sequenced, which defeats much of the purpose of gathering them.
The single most important property of an aggregation store is that logs, once collected, cannot be silently changed. Attackers routinely try to cover their tracks by editing or deleting local logs on the device they compromised, so the value of shipping logs off the device immediately is that a record already sits somewhere the attacker does not control. Making that central store tamper-evident, using append-only storage, integrity hashing, or write-once media, means that even if someone gains access to it, alterations are detectable rather than invisible. A log you can quietly rewrite is not evidence.
Retention policy decides how far back you can look. Some OT incidents are discovered long after they begin, so keeping aggregated logs for a meaningful window, balanced against storage cost and any regulatory requirements that apply to the operation, determines whether a forensic investigation has anything to work with. Retention also interacts with the modest logging capacity of field devices: a PLC or an HMI may only hold a small rolling buffer locally, so if aggregation does not pull those records off promptly, they are overwritten and gone. The aggregation layer is often the only place older device events survive at all.
Access to the aggregated store deserves the same care as access to the devices themselves, because whoever can read all the logs can see the whole operation, and whoever can write to them can rewrite history. Reads should be limited to the people who need them, writes should come only from the authorized forwarding paths, and every access should itself be logged. Handled this way, the aggregation store becomes a trustworthy audit chain, a defensible account of what happened, when, and by whom, rather than a convenient but deniable collection of files.
A cloud SCADA platform changes where aggregation naturally happens. Instead of every field site needing its own on-premise log server and its own long-term storage, telemetry and event data flow outbound to a central platform that can serve as the aggregation point for the whole fleet. That consolidation is powerful for operators running many remote, unmanned sites, because the records from a hundred well pads land in one place with one clock and one retention policy, rather than being trapped in a hundred local buffers that no one ever reads.
The collection still has to be resilient to the realities of field networks. Remote sites lose connectivity, so a field gateway or forwarder should buffer log data locally and forward it when the link returns, so an outage does not create a permanent gap in the record. This store-and-forward behavior is exactly what keeps aggregation honest at the edge: the point of gathering logs is undermined if the very network problems you most want to investigate are also the ones that lose the evidence. Local buffering plus reliable forwarding is how the aggregation layer survives the conditions it exists to document.
It is worth being clear about the boundary between aggregation and everything above it. Aggregation collects and preserves; a SIEM analyzes, correlates, and raises alerts; an event log or operator record is a curated human-facing view of a subset of these events. They are layers, not competitors. Getting aggregation right, complete collection, consistent time, tamper-evident storage, sensible retention, is the unglamorous foundation that makes the analysis and alerting above it trustworthy. If the collection layer is incomplete or corruptible, no amount of clever correlation on top can recover what was never gathered.
Log aggregation is the collection layer: it gathers log records from many devices into one central, tamper-evident store. A SIEM sits on top of that store and does the analysis, correlating events across sources, detecting patterns, and raising alerts. Aggregation preserves the raw material; the SIEM interprets it. You can aggregate without a SIEM, but a SIEM can only reason about logs that aggregation has already collected.
Two reasons. First, an attacker who compromises a device will often edit or delete its local logs to hide their actions, so a copy already sitting in a store they do not control is much harder to erase. Second, field devices like PLCs and HMIs usually hold only a small rolling log buffer that overwrites old entries quickly, so if aggregation does not pull those records off promptly they are lost. Central collection preserves both the integrity and the history.
The forwarder or gateway at the site buffers log data locally when the network is down and forwards it once the link returns, a pattern called store-and-forward. This matters because outages are often exactly the events you want to investigate, so the collection layer must survive the conditions it documents. Local buffering plus reliable forwarding prevents a connectivity gap from becoming a permanent hole in the aggregated record.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.