An audit trail that lives only inside the system it audits has a weakness: anyone who compromises or controls that system can potentially reach the record too. Audit log forwarding removes that single point of failure by streaming the SCADA's own activity record out to an independent system. This guide explains what part of the audit log gets forwarded, the formats and delivery guarantees involved, and how sending records to an external destination supports retention, separation of duties, and tamper-evidence.
Audit Log Forwarding in one line: Audit log forwarding is the practice of streaming a SCADA platform's application-level audit trail - user logins, permission and configuration changes, and other tracked activity - out to an external system such as a customer SIEM, a syslog collector, or a cold archive. Keeping an independent copy means the records survive even if the SCADA platform is compromised, lost, or under someone's control, which satisfies retention and separation-of-duties requirements.
It is worth being precise about what is being forwarded. This is the application-level audit trail: the record of who logged in, whose permissions changed, what configuration was edited, and other user-facing activity inside the SCADA. That is a different stream from the low-level device and network logs a field gateway or firewall produces. Both are valuable and both can be shipped off-box, but audit log forwarding as described here is about the human and configuration story the SCADA application records, not the packet-level chatter of the OT network.
The forwarded stream typically carries the same fields the internal audit trail holds - a timestamp, the acting user, the action, the object affected, the origin, and where relevant the before-and-after values of a configuration change. Each event becomes a message sent to the external destination as it happens or in near-real-time batches. The receiving system then owns a second, independent copy of the record that grows alongside the one inside the SCADA.
The reason to duplicate the record externally is independence. As long as the only copy of the audit trail is inside the SCADA, the completeness of that record depends on the SCADA staying honest and available. Forwarding breaks that dependency: the external copy is written to a system under different control, so tampering with or losing the SCADA's internal log does not erase the evidence. This is the core value proposition and the reason forwarding shows up in security and compliance requirements.
Forwarding has to speak a language the destination understands. The common targets are a SIEM, which correlates the SCADA's events with logs from the rest of the enterprise; a syslog collector, which is the long-standing standard for shipping log messages over the network; and a cold archive, where records are retained cheaply for long periods to meet retention rules. Each expects a particular format, so the forwarder emits structured messages - often syslog framing or a structured record like JSON - that the receiver can parse, index, and search.
Delivery guarantees matter because a dropped audit event is a gap in the record. A forwarder that sends and forgets can lose messages if the network hiccups or the receiver is down, which undermines the whole point of keeping an independent copy. Stronger implementations queue events locally and retry until the destination confirms receipt, and use a transport that acknowledges delivery, so the external copy is complete rather than best-effort. The trade-off is buffering and back-pressure handling, but for an audit stream completeness is usually worth it.
Getting the record safely off the platform also means protecting it in transit and at rest on the far side. The stream is normally sent over an encrypted channel so it cannot be read or altered on the wire, and the destination is expected to store it with its own access controls. Once the events land in a SIEM or archive, they inherit that system's retention and protection, which is frequently stronger and longer than what the operational SCADA is configured to keep.
The security principle behind forwarding is separation of duties: the people who operate and administer the SCADA should not be the same people who control the record of what they did. If an administrator can both change a setpoint and edit the log that records the change, the log cannot be trusted against that administrator. Forwarding the audit trail to a system owned by a different team - often a security or IT function - places the record beyond the reach of the operators it documents, which is exactly what separation of duties requires.
This arrangement makes the audit trail tamper-evident across the whole path. The SCADA writes its internal log append-only, and it also forwards each event to an external destination as it occurs. To hide an action, someone would now have to alter two independent records held by two different parties before anyone reconciled them, which is far harder than editing one. In practice the external copy becomes the authoritative record precisely because it is out of the operator's hands, and discrepancies between the two copies are themselves a signal that something was tampered with.
For a hosted, multi-tenant SCADA serving field operations, forwarding is also what lets a customer own their compliance destiny. Even though the platform runs the monitoring, the customer's own SIEM or archive holds a durable, independent copy of every login, permission change, and configuration edit affecting their sites. That copy satisfies retention obligations on the customer's terms, feeds their existing security monitoring, and survives regardless of what happens to the SCADA subscription, which is a level of assurance an internal-only log cannot provide.
Device syslog forwarding ships low-level logs from field gateways, PLCs, and network gear - the packet-level and system chatter of the OT network. Audit log forwarding ships the SCADA application's own audit trail: who logged in, whose permissions changed, and what configuration was edited. Both send records off-box for safekeeping, but they cover different layers, and a full picture usually forwards both to a SIEM.
An audit trail kept only inside the SCADA depends on that system staying honest and available; if it is compromised or lost, so is the record. Forwarding writes an independent copy to a system under different control, so tampering with or losing the SCADA's internal log does not erase the evidence. That independence is what satisfies separation-of-duties and long-term retention requirements.
Because a dropped event is a permanent gap in the record, robust forwarding queues events locally and retries until the destination confirms receipt, rather than sending and forgetting over an unreliable channel. It also sends over an encrypted transport so the stream cannot be read or altered on the wire. The goal is a complete, protected external copy rather than a best-effort one.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.