Every identity platform claims an audit log. Most produce one in some custom JSON format and call it done — the same event below might land in your monitoring stack looking like this:
Custom JSON · what most vendors emit
{
"event": "sso.success",
"timestamp": "2026-05-18T09:14:22Z",
"user": "j.adesina@acme.example",
"ip": "203.0.113.42",
"device_id": "mac-001",
"app": "Workday",
"auth_method": "passkey",
"outcome": "success"
}
That payload is perfectly readable to a human and perfectly invisible to the tools your SOC and auditor actually use. The trouble starts when the auditor asks for evidence in the format their tools accept — or when the security operations centre asks for events in the format their monitoring platform reads — and the answer is “we don’t do that.”
Three formats, three audiences
The three industry-standard formats — call them by their colloquial names, Common Event Format, Log Event Extended Format, and the Open Cybersecurity Schema — were each designed for a different audience. The samples below all describe the same event as the JSON above: a successful SAML sign-in to Workday by an Acme employee.
Common Event Format is what the large enterprise monitoring platforms expect. Built originally for ArcSight in the early 2000s, it became the lingua franca for ingestion into Splunk, Microsoft Sentinel, and similar tools. A CEF line is a single record with a predictable prefix and a small set of well-defined fields, followed by a dictionary of extensions. It is verbose and structured, and an ingestion pipeline that supports it can parse it without custom code.
CEF · single line, pipe-prefixed
CEF:0|Trustaige|Identity|1.0|sso.success|SSO authentication succeeded|3|src=203.0.113.42 suser=j.adesina@acme.example duser=j.adesina@acme.example app=Workday outcome=success rt=May 18 2026 09:14:22 cs1Label=DeviceID cs1=mac-001 cs2Label=AuthMethod cs2=passkey
The seven pipe-separated fields up front are fixed and positional — vendor, product, version, signature, name, severity. Everything after the last pipe is space-separated key=value, drawn from a documented field dictionary. A SIEM that knows CEF can index every event without you writing a parser.
Log Event Extended Format is IBM QRadar’s preferred format — similar in structure to CEF but with subtly different field naming. If your organization runs QRadar, the SOC team will ask for LEEF.
LEEF · QRadar's variant
LEEF:2.0|Trustaige|Identity|1.0|sso.success|cat=auth usrName=j.adesina@acme.example src=203.0.113.42 resource=Workday severity=3 devTime=May 18 2026 09:14:22 GMT deviceId=mac-001 authMethod=passkey outcome=success
Shape is almost identical to CEF, but extensions are tab-separated and
field names differ (usrName instead of suser, devTime instead of
rt). QRadar’s parser is strict about these — emit CEF into a
LEEF pipeline and the events are dropped silently.
Open Cybersecurity Schema Framework is the newer one, born of a 2022 industry collaboration that included AWS and Splunk. It’s a typed, hierarchical schema designed for cloud-scale security analytics. Where CEF and LEEF were optimised for single-line log emission, OCSF is optimised for nested events with rich metadata — and is the format most likely to be requested by a modern cloud-native security team.
OCSF · typed, hierarchical JSON
{
"metadata": {
"version": "1.3.0",
"product": { "name": "Trustaige", "vendor_name": "Trustaige" }
},
"category_uid": 3,
"category_name": "Identity & Access Management",
"class_uid": 3002,
"class_name": "Authentication",
"activity_id": 1,
"activity_name": "Logon",
"time": 1747559662,
"status_id": 1,
"status": "Success",
"actor": {
"user": {
"name": "j.adesina@acme.example",
"type": "User"
}
},
"src_endpoint": {
"ip": "203.0.113.42",
"uid": "mac-001"
},
"auth_protocol": "SAML",
"mfa": true
}
The activity, class, and category IDs are drawn from the OCSF
taxonomy — a cloud analytics platform can group every “logon”
event across vendors by class_uid: 3002 without knowing what
“Trustaige” is. That’s the part the older formats can’t do.
The translation tax accrues quarterly
The reason this matters: an audit log that can only be exported in a custom JSON format becomes a translation problem at every audit and every SOC integration. The translation tax accrues quarterly, gets worse as the log volume grows, and tends to produce errors right before the auditor or the incident-response analyst needs the data most. Picking an identity platform whose audit export already matches the formats your tools read is one of the small decisions that compound, in security work, into the difference between a 30-minute response and a 30-day one.
Trustaige writes audit events into immutable storage and exports them in five formats — the three industry standards above, plus plain CSV and JSON for the cases where the consumer is a human or a one-off script. The exports can be downloaded on demand or streamed live; the live stream is what most security teams want, because it puts identity events alongside everything else the SOC is watching in the same console, in real time.
What to ask your identity vendor
- Which formats do you export, natively, without an integration product in between? “We have an API you can poll” is not the same answer as “we stream CEF to your collector.”
- How is the log made immutable, and how would you prove that to an auditor? Append-only storage, signed events, and an attestation chain are the answers a regulated buyer expects.
- Can you attribute every event to a specific person, or just to a session ID? A log that can’t name the actor is a log the auditor will reject.
These are small questions that take five minutes to ask and that sort serious identity platforms from the marketing kind.