OCSF and schema-less SIEM: what Gurucul’s approach changes

At a glance

What this is: This is an analysis of how OCSF fits into a schema-less SIEM architecture and why the vendor treats schemas as interoperability contracts rather than storage truth.

Why it matters: It matters because IAM, NHI, and security engineering teams increasingly need telemetry models that preserve context across identity events, workload signals, and detection workflows without forcing brittle normalisation.

👉 Read Gurucul's analysis of OCSF in schema-less SIEM architecture

Context

Security teams often confuse standardisation with operational simplicity. In practice, the real problem is not whether a schema exists, but whether a platform can preserve rich identity and telemetry context while still letting teams exchange data cleanly across tools and teams.

For identity and security programmes, this becomes a governance issue as much as an engineering one. If the data model strips away source detail too early, it weakens investigations, detection portability, and the ability to relate human identity, non-human identity, and workload activity consistently.

OCSF is useful when it acts as a boundary contract, not a forced internal truth. Gurucul's framing is that the value sits in preserving fidelity first and using canonical structure only where interoperability or cross-team communication actually improves outcomes.

Key questions

Q: How should security teams decide where to use OCSF in a telemetry pipeline?

A: Use OCSF where a shared event language improves exchange, correlation, or downstream reporting, but keep the internal model rich enough to support investigations and behavioural analytics. The best rule is simple: standardise at the boundaries, preserve fidelity at the core, and never let canonical formatting remove context that analysts will need later.

Q: Why do schema-less architectures matter for identity and security data?

A: They matter because identity, cloud, endpoint, and workload telemetry rarely share the same shape or investigative value. A schema-less core preserves source richness and reduces the risk that early normalisation strips away fields needed for correlation, access analysis, or threat detection.

Q: What do teams get wrong about standardising security telemetry?

A: The most common mistake is assuming that a single canonical schema can replace analytic design. Standardisation helps teams share and move data, but it does not replace enrichment, entity resolution, or behavioural detection. If the schema becomes the ceiling, the platform becomes easier to integrate but harder to investigate.

Q: What is the difference between canonical export and internal detection logic?

A: Canonical export is a clean, shared representation for moving data between systems, while internal detection logic depends on the full context available inside the platform. Teams should use the export layer for interoperability and the internal layer for richer analytics, rather than forcing both to share the same limitations.

Technical breakdown

Why schema-less ingestion matters for telemetry fidelity

Schema-less ingestion means raw events are accepted without forcing them into a narrow internal template at the point of entry. That matters because identity, cloud, endpoint, SaaS, and workload telemetry often carry different fields, timing, and context that are easy to lose during premature normalisation. A schema-less core can preserve source richness while still allowing later modelling for search, analytics, and correlation. The technical advantage is late binding: structure is applied when it creates value, not when it would flatten data prematurely.

Practical implication: preserve raw telemetry first so identity and detection teams can decide later which fields deserve canonical mapping.

OCSF as a canonical interface, not the system of record

OCSF works best when it is treated as a shared representation layer at the edges of the platform. In that model, OCSF can standardise ingest, export, and cross-tool exchange without becoming the only internal data shape the analytics engine understands. This separation matters because canonical schemas help teams collaborate, but they are not equivalent to enrichment, entity resolution, or behavioural detection. A platform can speak OCSF while still keeping richer semantic layers underneath for investigation and modelling.

Practical implication: use OCSF for interoperability contracts, but do not let it constrain your enrichment or detection model.

Schema portability and the identity governance layer

When detections and reports depend on vendor-specific fields, portability breaks the moment telemetry moves. OCSF reduces that friction by creating common event vocabulary, which is especially relevant when identity data must move across SOC platforms, data lakes, and co-managed environments. The governance angle is that a canonical schema can improve communication about what an authentication, process, or network event means. But governance only works if the platform also retains enough context to explain the event, not just label it.

Practical implication: standardise enough to share detections, but keep enough source fidelity to preserve investigation quality.

NHI Mgmt Group analysis

OCSF should be treated as an interoperability contract, not an identity truth model. Standard schemas solve exchange problems, not analytic ones. The real governance question is whether telemetry can move across tools without losing the source-specific context needed for investigations, detections, and access decisions. Practitioners should treat canonical formats as a boundary control, not the architecture itself.

Schema-less architecture is most valuable when identity data is high-fidelity and heterogeneous. Human identity events, service account activity, API telemetry, and workload logs do not carry the same shape or investigative value. Forcing them into one rigid internal schema too early creates blind spots that later show up as weak correlation and brittle content portability. The practical conclusion is that fidelity should survive normalisation.

Shared schemas help cross-team governance, but only if the platform still preserves behavioural depth. OCSF can make detection logic easier to communicate and re-use, yet governance fails when the canonical layer becomes the ceiling for what the platform can see. This is a schema-vs-intelligence tradeoff only if the architecture is designed poorly. The better model is layered: raw, enriched, and canonical views serving different governance needs.

Canonical event language: the useful pattern here is a shared translation layer that helps security teams exchange telemetry without flattening the underlying identity signals. That matters because cross-platform portability is a governance problem as much as a data engineering problem. Practitioners should define where standardisation ends and analytic fidelity must begin.

From our research:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which shows how often identity context is already fragmented before telemetry normalisation begins.
• For the standards view, see Ultimate Guide to NHIs , Standards for how OCSF, OWASP NHI, and Zero Trust fit into identity governance.

What this signals

The operational signal here is that telemetry architecture is becoming an identity governance issue. When 92% of organisations expose NHIs to third parties, the pressure is no longer only on detection engineering but on whether the platform can preserve enough identity context to explain who or what actually acted across the chain.

Canonical event language: standard schemas can reduce integration friction, but they also tempt teams to mistake portability for completeness. The stronger programme pattern is layered visibility, where raw events, enriched context, and canonical exports each serve a distinct purpose without collapsing into one another.

For practitioners aligning telemetry strategy with broader control frameworks, the relevant question is whether data models support continuous context across identity and workload flows. The NIST Cybersecurity Framework 2.0 remains useful here because it forces teams to connect data quality, detection, response, and recovery rather than treat schema design as an isolated engineering task.

For practitioners

• Map where canonical schemas should stop Document which telemetry fields must survive ingestion unchanged because they support investigations, identity stitching, or behavioural detection. Use that boundary to decide where OCSF or any other canonical format belongs in the pipeline.
• Preserve raw events before enrichment Keep source logs intact so teams can re-model telemetry later when new use cases emerge. That is especially important for identity events, SaaS logs, and workload telemetry where later correlation may depend on fields that seem unimportant at ingest.
• Define portability requirements for detections Review whether detection content depends on vendor-specific field names or on portable concepts that can survive a move between platforms. If the rule cannot be explained in a shared vocabulary, it will be hard to scale across teams or tools.
• Use canonical exports for coordination, not confinement Export standardised telemetry to downstream tools when that improves reporting, collaboration, or partner integration. Keep the analytics engine free to use richer context than the export layer exposes.

Key takeaways

• OCSF is best treated as a shared exchange layer, not as the internal source of truth for security intelligence.
• Schema-less ingestion preserves raw telemetry context that identity and detection teams often need later for investigation and correlation.
• Practitioners should standardise at the boundary, but keep the core architecture rich enough to support behavioural analytics and governance.

Key terms

• Open Cybersecurity Schema Framework: A standard vocabulary for representing security events across tools and platforms. OCSF helps teams exchange telemetry in a consistent way, but it does not replace the need for enrichment, correlation, or behavioural analysis inside the security stack.
• Schema-less ingestion: An approach that accepts raw telemetry without forcing it into one fixed internal structure at the point of entry. This preserves source fidelity, which matters when identity, cloud, and workload logs need to be reinterpreted later for investigation or detection.
• Canonical export: A standardised output format used to send telemetry or findings to downstream systems. It improves interoperability and portability, but it should not become the limit of what the platform can analyse internally.
• Behavioural intelligence: Analytic logic that focuses on how an identity or system behaves over time rather than only on static fields or labels. In security operations, it depends on preserved context, enrichment, and the ability to compare activity patterns across sources.

What's in the full article

Gurucul's full blog post covers the operational detail this post intentionally leaves for the source:

• Exact examples of how OCSF is mapped at ingest, export, and integration boundaries
• The schema-less core design choices behind Gurucul's semantic layer and enrichment flow
• Use-case-level explanations for onboarding, portability, and cross-team detection sharing
• The vendor's own guidance on when OCSF helps and when it should not be forced internally

👉 Gurucul's full post covers OCSF mappings, use cases, and the schema versus intelligence tradeoff in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.