Syslog forwarding is the plumbing that gets log messages out of network and control devices and into a central place where they can be stored and analyzed. Switches, firewalls, RTUs, and many other OT devices can emit events in the syslog format and send them over the network to a collector, which is how a SIEM ends up with the raw material it needs to correlate and alert. It sounds simple, but the classic transport, syslog over UDP port 514, silently loses messages, which matters a great deal when the lost message might be the one recording an attack. This page explains how OT devices emit syslog, why UDP 514 drops events, and how a collector ships those logs upstream reliably.
Syslog Forwarding in one line: Syslog forwarding is the sending of log messages from a device across the network to a central collector, using the standard syslog format that switches, firewalls, RTUs, and many other OT devices support. It is the pipeline that feeds a SIEM its event data. The traditional transport is syslog over UDP port 514, which is simple but unreliable because UDP does not guarantee delivery, so events can be silently lost, which is why a reliable pipeline uses a collector and often TCP or an acknowledged transport instead.
Syslog is a long-established, widely supported format for log messages, and a great many OT-relevant devices can produce it. Managed switches emit syslog for events like link changes, configuration changes, and port security violations; firewalls emit it for allowed and denied connections and rule changes; and many RTUs, gateways, and control-adjacent devices emit it for logins, configuration edits, and operational events. Each message carries a timestamp, an indication of the source, a severity, and the text of the event, in a common shape that a collector can parse regardless of which vendor produced it.
This commonality is the point. Because so many different devices all speak syslog, a single collection pipeline can gather events from a heterogeneous mix of network gear and control equipment without a bespoke integration for each one. The device is configured with the address of a collector and simply sends its events there as they happen, requiring nothing more of the device than pointing it at a destination. That low bar is why syslog is the default log-shipping method across so much of the infrastructure a SIEM wants to watch.
Not everything speaks syslog, of course, and that shapes the pipeline. Some deep control devices log only locally or in proprietary formats, and Windows-based engineering workstations produce event logs that are collected by other means before being normalized. In practice an OT log pipeline is a blend: native syslog from the network and security gear that supports it, and adapters or agents that translate other sources into a common form. Syslog forwarding is the backbone of that pipeline even though it is not the only strand.
The traditional way to send syslog is over UDP on port 514, and its weakness is inherent to UDP itself. UDP is a fire-and-forget transport with no acknowledgement and no retransmission, so a device sends its message and never learns whether it arrived. If the packet is dropped, whether because the network was congested, a link hiccuped, or the collector was momentarily too busy to receive it, the message is simply gone, and neither the sending device nor the collector has any record that it ever existed. The loss is completely silent.
For security this silence is the real danger. The events most worth capturing, a burst of failed logins, a configuration change, a flood of denials during an attack, tend to arrive exactly when the network is busiest and packet loss is most likely, so UDP syslog is prone to losing precisely the messages you most need. Worse, because there is no delivery confirmation, you cannot tell after the fact whether your log record is complete or riddled with gaps, which undermines confidence in any investigation that depends on it and can leave an attacker's key action simply missing from the record.
The fixes address the transport, not the format. Sending syslog over TCP adds delivery acknowledgement and retransmission, so a message that fails to arrive is resent rather than lost, and reliable syslog variants add further guarantees. Because the field devices are often the ones limited to UDP, a common architecture puts a nearby collector very close to the sources to minimize the lossy hop, then has that collector forward onward over a reliable transport. Buffering at the collector also protects against loss when the upstream destination is briefly unreachable, holding messages until they can be delivered rather than dropping them.
A collector is the component that receives syslog from many devices and ships it onward reliably, and it is where a robust pipeline earns its reliability. Software such as an rsyslog-based collector, or a similar log shipper, listens for incoming syslog, buffers it to disk so nothing is lost if the upstream link stalls, and forwards it to the SIEM or central store over an acknowledged transport. Placing the collector close to the sources keeps the fragile UDP hop short and local, then upgrades the traffic to something reliable for the longer journey to the SIEM.
A good collector does more than move bytes. It can normalize timestamps and time zones so that events from different devices line up correctly, which is essential for the sequencing that correlation depends on, and it can enrich or tag events with the site or asset they came from so a downstream analyst knows their origin. It can also throttle and buffer during a storm of events, absorbing a burst that would otherwise overwhelm the destination, so the pipeline degrades gracefully under exactly the load spikes that accompany incidents rather than collapsing when it matters most.
For distributed OT, this collect-then-forward pattern is what makes centralized monitoring workable. Each site runs a local collector that gathers syslog from its switches, firewalls, and RTUs over the short local hop and then forwards the aggregated, buffered stream over the wide-area link to a central platform, which cushions the pipeline against the latency and unreliability of remote connectivity. A cloud SCADA or security platform such as Merobix receiving those forwarded streams from many sites can then correlate and alert on a complete picture, but only because the plumbing beneath it was built to ship the logs reliably rather than to fire them into a UDP socket and hope. The value of every correlation rule and every alert rests on this pipeline actually delivering the events it is fed.
Because UDP is a fire-and-forget transport with no acknowledgement or retransmission, so a device sends its message and never learns whether it arrived. If the packet is dropped due to congestion, a link problem, or a busy collector, the message is simply gone, and neither end has any record it existed. This matters most during an attack or a fault, when the network is busiest and packet loss is likeliest, so UDP syslog tends to lose exactly the events you most need to capture.
By fixing the transport and buffering the flow. Sending syslog over TCP or a reliable syslog variant adds delivery acknowledgement and retransmission so lost messages are resent, and putting a collector close to the sources keeps any unavoidable UDP hop short and local. The collector then buffers events to disk and forwards them onward over an acknowledged transport, holding messages when the upstream link stalls rather than dropping them, so the pipeline degrades gracefully instead of losing data under load.
A good collector normalizes and protects the data as it passes through. It aligns timestamps and time zones so events from different devices sequence correctly, which correlation depends on, and it can tag events with the site or asset they came from so their origin is clear downstream. It also buffers to disk and throttles during event storms, absorbing bursts that would overwhelm the destination, and forwards everything onward reliably, which is what lets a distributed OT environment feed a central SIEM without losing events.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.