Audit event
In OPC UA, an audit event is a server-generated event recording a security-relevant action: a channel opened, a session created or activated, a certificate rejected, a value written, history modified, a node added. Audit events answer who did what and when, for forensics and accountability - they are not operator alarms.
The type hierarchy tells you the coverage
AuditEventType is the base, with AuditSecurityEventType beneath it covering the security actions: AuditChannelEventType and AuditOpenSecureChannelEventType for the transport, AuditSessionEventType with AuditCreateSessionEventType and AuditActivateSessionEventType for sessions, AuditCancelEventType, and a family of AuditCertificate event types for validation failures. Separately, AuditNodeManagementEventType, AuditWriteUpdateEventType and AuditHistoryUpdateEventType cover changes to the model and to data.
The fields that make it usable
Every audit event carries an ActionTimeStamp, a Status saying whether the action succeeded, the ServerId, and a ClientUserId - the identity behind the action. The one people forget is ClientAuditEntryId, which the client supplies in the AuditEntryId field of the request header. Fill it in with your own correlation id and a plant-wide audit becomes searchable across systems; leave it empty, as most clients do, and you can only correlate by timestamp.
What they are actually for
Three concrete jobs. Attribution after the fact: who wrote 950 to that setpoint at 03:12 and from which application. Detecting attempts rather than successes: a run of failed ActivateSession or rejected-certificate events is a probe or a misconfigured client, and both matter. And regulatory or process-safety evidence, where you must show that a change was made by an authorised identity. Note the dependency: audit events are worth nothing if every session is anonymous, so roles and audit are one project, not two.
Getting them out of the server
Audit events are delivered like any other event, by subscribing with an EventFilter on the Server object, so your collector is an ordinary OPC UA client. Servers gate them behind an auditing setting that is often off by default, and the range of actions actually audited varies widely by product - the reference stack raises them for channel, secure-channel, session, activate and cancel. Ship them off the server promptly: a local audit log on the audited device is evidence an attacker can edit. Confirm with the vendor which audit event types their server really emits.
Example
Subscribing to audit events - the select clause that makes them useful
Subscribe to Server (i=2253) EventNotifier = SubscribeToEvents
EventFilter select clause:
EventType, SourceName, Severity, Time,
ActionTimeStamp, Status, ClientUserId, ClientAuditEntryId,
/SessionId, /ClientCertificate
where clause: OfType(AuditSecurityEventType) or OfType(AuditWriteUpdateEventType)
A write audit then reads roughly:
AuditWriteUpdateEventType Status=Good ClientUserId="engineer_rk"
ClientAuditEntryId="CHG-2026-0914" node=ns=4;s=Line3.Press.SetpointForce
OldValue=880 NewValue=950 ActionTimeStamp=2026-09-08T03:12:44ZDefined in: Part 4 - Services, audit event types; Part 5 - Information Model for the event type hierarchy.
Last verified 7 September 2026 against OPC UA 1.05.07. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.