Notifications
Clear all
Topic starter
02/09/2026 1:29 pm
TL;DR: Microsoft security telemetry is fragmented across endpoints, identity, cloud management, and security products, and TENZIR’s analysis shows why a source to destination pipeline must normalize evidence once before translating it to SIEM-specific schemas. The identity gap matters because sign-ins, device activity, and cloud events are often investigating the same questions, yet they arrive in incompatible formats.
NHIMG editorial — based on content published by TENZIR: Microsoft security telemetry normalization and TQL mapping
Questions worth separating out
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.
Q: Why do provider-aware Windows event mappings matter for security operations?
A: Because Windows event IDs are not globally unique in meaning.
Q: What breaks when identity and endpoint events use different schemas?
A: Correlation breaks first, then investigation speed, then confidence in the evidence.
Practitioner guidance
- 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.
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
👉 Read TENZIR's analysis of Microsoft security telemetry normalization and TQL mapping →
Microsoft telemetry normalization: what identity teams need to know?
Explore further
02/09/2026 1:30 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Microsoft security telemetry normalization exposes the identity gap
