Logs ship in formats someone else's SOC can read
Three-fourteen in the morning. The asset owner's security operations centre receives an alert: anomalous outbound connection attempts from a SCADA workstation in the wind farm control room. The analyst on duty pulls up the device logs to investigate. The SCADA application's log shows the timestamp that the alert correlated to, then a single line: NetworkException: connection failed. No source process, no destination, no protocol, no port, no user, no return code. Just the message and the time.
The analyst escalates to a senior analyst, who pulls the firewall logs for context. The firewall shows three connection attempts, two seconds apart, all blocked — outbound to a hostname that resolves to an IP address in a jurisdiction the asset owner's policy flags as restricted. The source was the SCADA workstation. The initiating process is identified at the network layer but not the application layer; the firewall sees the parent of the OS network stack, not the executable that opened the socket.
The senior analyst calls the manufacturer's emergency line. The on-call engineer takes the report. Twenty minutes later they come back. Yes, they have seen this. The manufacturer operates a fleet-wide telemetry system that monitors network behaviour on their SCADA installations across multiple customers. The same anomalous pattern appeared at three other sites the previous month, traced to a misconfigured update check in a third-party library bundled with the SCADA application, patched in the latest release. They had not communicated the issue because their support contract did not specifically require them to.
The asset owner's SOC has spent ninety minutes investigating an event the manufacturer already knew about. The manufacturer's monitoring picked it up, diagnosed it, fixed it in the product, and did not tell the operator whose plant they were watching. The architectural failure is not in either side's monitoring. It is in the assumption that two parallel monitoring systems was an acceptable architecture.
The principle the asset owner expects is direct. The security operations centre is the system of record for security events affecting the deployed equipment. Not the manufacturer's monitoring centre, not the manufacturer's fleet analytics, not the manufacturer's support ticket system. Every security-relevant event the equipment generates must reach the asset owner's SIEM (Security Information and Event Management platform) in a format the SIEM can consume, with the fields necessary for investigation, time-synchronised to the asset owner's authoritative time source, with an audit trail that is tamper-evident and that the manufacturer cannot unilaterally delete or rotate.
The manufacturer's own monitoring may continue to exist — there are good reasons for it to exist, including fleet benchmarking and predictive maintenance — but it is not a substitute for the operator's monitoring. The two systems serve different purposes, sit under different governance, and are accountable to different parties.
What the SIEM needs
The asset owner's SIEM is the integration point for security event data across the entire OT environment. It correlates events from firewalls, intrusion detection systems, jump hosts, secure remote access brokers, identity platforms, network switches, and the OT devices themselves. To do that work, it needs events in a specific shape.
Standard format. The most widely supported formats are Syslog (RFC 5424 , with structured data extensions), the Common Event Format originally from ArcSight, and the Log Event Extended Format originally from IBM QRadar. OpenTelemetry is increasingly accepted as a modern alternative, particularly for newer deployments. The choice between them is the asset owner's, but the device must support at least one. Proprietary log formats that require custom parsers, manufacturer-specific dashboards as the only viewing mechanism, or binary log files that require manufacturer-supplied tooling to interpret — none of these integrate cleanly. The transport itself should be secure: Syslog over TLS (RFC 5425) is the floor, not plain Syslog over UDP that was acceptable two decades ago.
Required fields. For each security-relevant event, the SIEM needs to know when it happened (timestamp at millisecond resolution, in UTC, sourced from the agreed time reference), what happened (a structured event type from a documented taxonomy), who was involved (the identity that performed the action, the device that generated the event, the source and destination if it is a network event), what the outcome was (success, failure, blocked, allowed), and any context that distinguishes this event from similar events (session identifier, ticket reference, correlation token). Events that lack these fields cannot be correlated effectively with events from other sources, which is the entire reason the SIEM exists.
Documented event taxonomy. The manufacturer should publish, as part of the product documentation, the complete list of security events the device generates — what each event type means, when it fires, what fields it includes, how it differs from similar events, what severity it should be treated as. Without the taxonomy, the SIEM team is reverse-engineering event meanings from observed behaviour. This works for the loudest event types and misses the subtler ones. A well-documented event taxonomy is often the most useful single artefact a manufacturer can provide to a deploying asset owner.
Time synchronisation. Every device emits timestamps. Those timestamps must be synchronised to the asset owner's authoritative time source — typically a GNSS-disciplined master clock distributing NTP or PTP, as covered earlier in this series for the substation side . A device whose clock drifts by minutes makes correlation difficult; a device whose clock drifts by hours makes investigation impossible. The agreed time source, the protocol, and the acceptable drift tolerance are part of the operational specification, and the manufacturer's equipment must accept the time source the asset owner provides rather than relying on a hard-coded NTP pool or, worse, a vendor-internal time source.
Audit logs as a distinct category. Audit logs — records of who did what against the device — are a specific subset of the device's log output, and they have stricter handling requirements than operational logs. They must be tamper-evident, typically through cryptographic hash chaining or write-once storage on the device. They must be forwarded to the SIEM in real time, not stored locally and pulled on demand. They must not be deletable or rotatable by an unprivileged user, and the manufacturer's service engineers must not be able to delete or rotate them through any service interface, including service-mode access during maintenance. The audit log is the evidence base for incident investigation; its integrity is what makes the investigation defensible to a regulator.
IEC 62443-3-3 organises the system-level requirements for audit logging under foundational requirement 2 (use control), with SR 2.8 covering auditable events, SR 2.9 covering audit storage capacity, SR 2.10 covering response to audit processing failures, and SR 2.11 covering timestamps. The component-level equivalents in 62443-4-2 are addressed to the manufacturer directly.
Why the manufacturer's monitoring is not a substitute
The manufacturer's own monitoring serves their interests. They benchmark fleet performance, identify common fault patterns, improve their products through observation, support their service operations. None of these activities is bad. None is sufficient.
The asset owner's monitoring serves the asset owner's interests. They detect threats specific to their environment, correlate events across systems the manufacturer cannot see, comply with their regulatory reporting obligations, and maintain the audit trail their lender requires. The two activities overlap in some areas — both observe the device's behaviour, both might notice the same anomaly — but they answer different questions, are accountable to different parties, and produce different artefacts.
Three reasons the two systems cannot be substituted.
The asset owner cannot rely on the manufacturer to share information about events that affect the asset owner's equipment. The manufacturer may have commercial reasons to not share. They may not consider an event significant enough to mention. They may be on a different time cycle for analysis and notification. The asset owner's regulatory obligations — incident notification under NIS2 within 24 hours of becoming aware — assume the asset owner becomes aware through their own infrastructure, not through a third party's selective disclosure.
The SIEM correlates events across systems. A login event from the identity platform, a connection event from the firewall, a process event from the controller, a configuration change event from the engineering workstation — together these tell a story that no single system tells alone. The manufacturer's monitoring sees only the device behaviour; it cannot correlate against the other systems the SIEM integrates with, because it does not see them.
The audit trail must be the asset owner's. Under NIS2 and the broader EU framework, the asset owner needs to be able to evidence what happened, when, on what authority, in their own systems, without dependency on a third party. The manufacturer's logs, held in the manufacturer's monitoring centre, accessible only through the manufacturer's tooling, do not meet this standard. The audit trail must be in the asset owner's hands.
The constructive arrangement is that both monitoring systems exist, with clear scope and a defined information-sharing protocol. The manufacturer monitors fleet behaviour for their own purposes, anonymised where appropriate, with the analytics they need for product improvement. The asset owner monitors all security-relevant events from the deployed equipment in their SIEM. The manufacturer is contractually required to share, in real time, any event their monitoring detects that the asset owner's monitoring would have detected if it had equivalent visibility — meaning anything security-relevant, anything anomalous, anything indicative of compromise. The default position is that information flows from the manufacturer to the asset owner promptly, with the manufacturer's monitoring serving as a supplementary sensor rather than a sealed channel.
False positives and instrumentation gaps
A practical observation worth noting. Industrial firmware is often log-noisy in unhelpful ways. The device emits log messages for routine events that, in modern IT systems, would never be logged at the security event level — successful self-tests, normal protocol handshakes, scheduled tasks completing on schedule. These events flood the SIEM, create false positives in the alert rules, and obscure the events that actually matter. The first weeks of any new deployment involve substantial SIEM tuning to suppress the noise without losing signal.
The remedy is on both sides. The device's logging configuration should be tunable — by event severity, by event category, by source module — so the asset owner's SOC team can suppress noise without losing signal. The SIEM's correlation rules should be authored specifically for the device's event taxonomy, not generic patterns assumed from other equipment. Both adjustments take work. They are normal SOC tuning activities, not signs that the integration is broken.
A different category of problem comes from inadequate device instrumentation — events that should fire and do not, or that fire with insufficient information. A login event without the source IP. A configuration change event without the changed parameter. A network event without the destination. A privilege escalation event that does not specify the privilege being escalated to. Each is a gap in the SIEM's investigative capacity. The remedy here is product improvement: the asset owner raises the gap with the manufacturer, the manufacturer addresses it in a firmware release through the patch contract described in the previous article . Over time the device's logging maturity improves, the false positive rate falls, and the SOC integration becomes routine. The first six months of operation are typically the noisiest; the second six months see substantial improvement.
The asset owner's SOC team is, in this sense, a continuous reviewer of the manufacturer's product quality. They see, in their alert rates and their investigation hours, where the device is well-instrumented and where it is not. Manufacturers who treat the asset owner's SOC findings as product feedback — incorporating instrumentation improvements into the development backlog — see their equipment become easier to integrate over time and their SOC integration cost fall accordingly. Manufacturers who treat the findings as deployment-specific configuration issues to be worked around locally never improve at the source.
At proposal stage
A manufacturer's bid that addresses logging — that specifies the supported formats (Syslog with structured data, CEF, LEEF, or OpenTelemetry), commits to a documented event taxonomy delivered with the equipment, supports configurable log severity and category filtering, supports time synchronisation to the asset owner's authoritative source, and confirms that audit logs are tamper-evident and forwardable in real time — is a bid that has anticipated the conversation. The conversation that follows is operational: SIEM integration testing during factory acceptance, event taxonomy review with the asset owner's SOC team, log volume estimation for SIEM sizing, alert rule authoring against the documented taxonomy.
A manufacturer's bid that proposes "comprehensive logging available through our cloud monitoring dashboard, accessible to the customer through a customer portal" signals the previous decade's model. The model is incompatible with the asset owner's SIEM-as-system-of-record requirement, and the work to close the gap involves either reconfiguring the device to emit standard-format logs in real time over a secure transport, or building a secondary export path that achieves the same outcome — typically the latter, because the device firmware changes are slower.
The deeper observation is that monitoring discipline pays off across the manufacturer's entire market. Standard log formats, documented event taxonomies, tamper-evident audit logs, time synchronisation, real-time forwarding — these are not EU-specific requirements; they are the direction every serious asset owner's security operations infrastructure is moving. A manufacturer who delivers monitoring this way has reduced friction across their global service organisation and has positioned themselves to integrate with the customer's tooling rather than requiring the customer to integrate with theirs. The shift from "log into our portal to see what your equipment is doing" to "your SIEM is the system of record, we contribute structured events to it" is, in the long run, the easier model for the manufacturer too — fewer customer portals to maintain, fewer parallel monitoring stacks to support, clearer information-sharing protocols when things go wrong.
The next article picks up the topic that monitoring exposes more clearly than any other: where the data the manufacturer collects actually goes, who has access to it, under whose jurisdiction it sits, and whether the architecture as built can survive the lender's transfer impact assessment under the GDPR's cross-border data provisions.
This article reflects the regulatory and standards landscape at publication. References to RFC 5424, RFC 5425, IEC 62443-3-3, and commercial logging formats (CEF, LEEF) are stable but may be supplemented by newer standards such as OpenTelemetry as deployment patterns evolve. If a citation has rotted or a clause has moved, LinkedIn is the way to flag it.