Microsoft security telemetry normalization exposes the identity gap

At a glance

What this is: This is an analysis of how Microsoft security telemetry can be collected, normalized, and translated through TQL so endpoint, identity, and cloud evidence can share a common event model.

Why it matters: It matters because identity and security teams cannot investigate or automate effectively when the same authentication facts appear in different schemas across Windows, Entra ID, Microsoft Graph, and Sentinel.

👉 Read TENZIR's analysis of Microsoft security telemetry normalization and TQL mapping

Context

Microsoft security operations often fail at the handoff between source telemetry and the SIEM. Windows logs, Entra ID sign-ins, Microsoft Graph resources, and endpoint collectors all describe the same security events in different structures, which forces teams to normalize before they can correlate, enrich, or investigate reliably. For identity and access teams, that creates a governance problem as much as a data engineering one.

The practical issue is not whether Microsoft produces enough telemetry, but whether defenders can preserve detail while turning that telemetry into a shared model. That is where identity evidence, cloud activity, and endpoint activity converge. When the same logon or sign-in is represented differently by each collector, downstream detections become brittle and identity analytics lose context.

Key questions

Q: How should security teams normalize Microsoft identity telemetry across different sources?

A: Teams should normalize Windows, Entra ID, and Graph evidence into a shared schema before they translate anything into a SIEM-specific format. That preserves investigative detail while reducing the number of custom source-to-destination paths. The goal is one evidence model that supports correlation, detection, and casework across identity and endpoint telemetry.

Q: Why do provider-aware Windows event mappings matter for security operations?

A: Because Windows event IDs are not globally unique in meaning. The provider determines what an event actually represents, so routing on event ID alone can distort investigations and detections. Provider-aware mappings keep the source context intact and reduce the risk of misclassification in downstream analytics.

Q: What breaks when identity and endpoint events use different schemas?

A: Correlation breaks first, then investigation speed, then confidence in the evidence. If sign-ins, logons, and cloud changes are represented differently, analysts must mentally translate each source before they can compare them. That creates brittle detections and makes it harder to explain access behavior across the environment.

Q: How do security teams know whether telemetry normalization is working?

A: It is working when the same investigative question can be answered consistently from Windows, cloud, and identity sources without custom parsing for each consumer. Analysts should be able to trace a normalized event back to its original source, preserve key fields such as timestamps and origin, and reuse the same model across detections and investigations.

Technical breakdown

Why Microsoft telemetry needs canonical normalization

Microsoft telemetry arrives through multiple collection paths, and each one preserves different field names, nesting, and typing conventions. A Windows event may be XML in one pipeline and structured records in another, while Microsoft Graph returns identity and cloud evidence in a separate schema altogether. Canonical normalization solves this by mapping source-specific detail into a stable intermediate model before any destination-specific translation occurs. In this article, that intermediate model is OCSF, which makes the same investigation logic usable across sources instead of rebuilding it per collector.

Practical implication: normalize once into a shared event model before any SIEM-specific translation.

How identity evidence and endpoint evidence become comparable

An endpoint logon and an Entra ID sign-in answer the same investigative questions, but they do so with different shapes and labels. The useful abstraction is not the product source, but the security fact set: who authenticated, when, from where, by what method, and whether the attempt succeeded. By mapping those facts into OCSF Authentication, the pipeline can preserve user, source IP, device, MFA method, and outcome without forcing every downstream consumer to understand Microsoft Graph, Windows, or Sentinel-specific quirks. That is the difference between collection and usable evidence.

Practical implication: standardize identity facts before building detections or case correlation logic.

Why provider-aware Windows routing matters for detection fidelity

Windows event IDs are not globally meaningful on their own. The same event ID can mean different things depending on the provider, so a pipeline that treats event IDs as universal will misclassify security activity. Provider-aware routing resolves that by pairing provider and event ID, then mapping those combinations into the right OCSF classes. The result is broader coverage without collapsing investigative meaning. For detection engineering, that matters because fidelity depends on preserving source context, not just moving events into a central store.

Practical implication: key detections to provider plus event ID, not event ID alone.

NHI Mgmt Group analysis

Telemetry normalization is now an identity governance issue, not just an engineering convenience. When sign-ins, device state, directory changes, and alerts sit in disconnected schemas, identity teams lose the ability to reason about access behavior as a single control plane. That weakens investigation quality and makes access governance harder to operationalize across cloud and endpoint data. The practical conclusion is that identity telemetry must be governed as a normalized security asset.

Common event models create the conditions for cross-domain identity analytics. OCSF-like normalization lets teams compare Entra ID sign-ins, Windows logons, and Microsoft Graph changes without rewriting every consumer for every source. That reduces the cost of correlation while preserving source detail for incident response and compliance evidence. For identity programmes, the lesson is that schema alignment is a prerequisite for trustworthy analytics.

Provider-aware parsing is the named concept this article really surfaces. Windows event IDs only become reliable when paired with their provider, because the provider supplies the context that gives the event its meaning. This is a narrow but important governance lesson for SIEM and identity teams alike. The practical conclusion is to preserve source provenance all the way through the normalization pipeline.

Destination-specific translation should happen last, not first. If teams translate directly from each source into a SIEM schema, every new source adds another custom path and another maintenance burden. By translating from a common model into ASIM after normalization, the pipeline isolates source complexity from destination complexity. That is the cleaner operating model for identity, cloud, and SOC teams that need to share evidence without multiplying integrations.

This architecture reinforces Zero Trust thinking at the data layer. The control objective is not to trust a collector because it came from Microsoft, but to verify and normalize the evidence before use. That aligns with NIST Cybersecurity Framework 2.0 and the discipline of preserving context through each transformation. Practitioners should treat normalization as an assurance step, not a transport detail.

What this signals

Provider-aware identity telemetry is becoming a prerequisite for SOC and IAM convergence. As more investigations depend on stitching together sign-ins, device state, and directory changes, teams need evidence models that retain provenance and normalise consistently across collectors. The operational signal is clear: build around shared semantics now, because the old source-by-source approach will not scale across hybrid identity estates.

Normalization will increasingly determine whether identity data is usable for automation. If a pipeline cannot preserve the original event while translating it into a common model, automated detection and response will inherit false confidence. For practitioners, the right benchmark is not how much telemetry arrives, but whether the same identity event can move cleanly from source to analysis to response without losing meaning.

For practitioners

• Implement a single normalization layer Map Windows, Microsoft Graph, and endpoint identity events into one canonical schema before any SIEM-specific formatting, so detections and investigations consume the same evidence model.
• Preserve source provenance through translation Carry original event IDs, provider names, timestamps, and source field mappings through the pipeline so analysts can trace every normalized record back to its origin.
• Key Windows detections to provider context Write parsing and detection logic around provider plus event ID combinations, especially where Microsoft source families reuse numeric identifiers across different event meanings.
• Validate identity analytics across source types Test whether the same sign-in or logon can be queried, correlated, and investigated consistently across Entra ID, Windows, and cloud telemetry after normalization.

Key takeaways

• Microsoft telemetry becomes materially more useful when identity, endpoint, and cloud evidence are normalized into one common model before SIEM translation.
• Provider context is not optional for Windows events because event IDs alone do not carry stable meaning across source families.
• Teams that preserve provenance and normalize once can build more reliable identity analytics without multiplying custom integrations.

Key terms

• Log Normalization: Log normalization is the process of converting different event formats into a common schema. It lets detection rules work across many sources, reduces source-specific rule drift, and keeps investigations consistent when infrastructure or vendors change.
• Common Event Model: A common event model is a shared schema that lets different telemetry sources describe the same investigative facts in consistent terms. It reduces integration sprawl and improves correlation because analysts and tools can reason over one representation instead of many.
• Provider-Aware Mapping: Provider-aware mapping is the practice of interpreting an event ID together with its originating provider, rather than treating the numeric ID as universally meaningful. This is essential in environments like Windows, where the same ID can represent different activity depending on source context.
• Access Provenance: Access provenance is the record of how an identity was created, approved, used, and withdrawn. In NHI governance, it is the evidence trail that lets teams prove an account is legitimate, explainable, and still within its intended access boundary.

What's in the full article

TENZIR's full analysis covers the operational detail this post intentionally leaves for the source:

• The full TQL examples for Microsoft Graph sign-in ingestion and OCSF normalization
• The provider and event-ID mapping approach used to expand Windows coverage across multiple event classes
• The ASIM translation path from OCSF into Microsoft Sentinel-ready schemas
• The field-level examples that show how source detail is preserved through each transformation

👉 TENZIR's full post includes the Microsoft Graph example, Windows mapping coverage, and ASIM translation details

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, identity lifecycle, workload identity, and secrets management. It gives security practitioners a practical foundation for governing machine and human access across modern identity programmes.