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.
Editorial analysis by NHI Mgmt Group, based on content published by TENZIR: “Mapping the Microsoft Security Stack to OCSF and ASIM”.
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.
Q: Why does fragmented Microsoft telemetry create risk for identity investigations?
A: Fragmented telemetry forces analysts to reconcile the same security event across incompatible field names and record shapes.
Q: What breaks when Microsoft events are mapped directly to SIEM schemas?
A: Direct mapping breaks reuse because each destination ends up needing source-specific translation logic.
Practitioner guidance
- Normalize once before SIEM translation Build a single source-to-destination pipeline that converts Microsoft evidence into a common model before any SIEM-specific mapping happens.
- Preserve source detail through the intermediate model Retain original event identifiers, timestamps, actor data, authentication method, and source addresses so investigations can be traced back to the raw Microsoft record.
- Map identity and endpoint facts to shared investigative fields Align sign-ins, logons, device state, and cloud audit activity around the same core facts so analysts can compare events without learning each source format separately.
Bottom line: Microsoft telemetry normalization matters because related identity, endpoint, and cloud events arrive in different formats even when they answer the same security question.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago by NHI Mgmt Group
02/09/2026 1:30 pm
Normalization is becoming an identity governance control, not just a data engineering pattern. When sign-ins, device records, and cloud security events are split across incompatible schemas, the real risk is not only slower analysis but weaker governance over access evidence. Identity teams need a common event layer to make authentication, device state, and cloud activity comparable across tools. The practitioner conclusion is that telemetry normalization now sits inside the identity control plane.
A question worth separating out:
Q: Should teams treat Microsoft identity telemetry and device telemetry as separate problems?
A: No. In Microsoft environments, identity and device events often describe the same investigative fact from different angles, so treating them separately creates gaps in correlation. Teams should design pipelines around the security question being answered, not around product boundaries.
👉 Read our full editorial: Microsoft security telemetry normalization exposes the identity gap
This post was modified 2 days ago by NHI Mgmt Group