Topic starter
25/06/2026 1:22 am
TL;DR: Semperis outlines how identity telemetry only changes SOC outcomes when it sits inside the response workflow. Sentinel and Security Copilot can then surface exposure, Tier 0 paths, and posture as queryable data during investigation.
Editorial analysis by NHI Mgmt Group, based on content published by Semperis: “Bringing Identity Context Into the Microsoft Security Workflow: Semperis’ Integration with Sentinel and Copilot”.
Key questions
Q: Why does identity context reduce SOC response time?
A: Because analysts lose time whenever they must switch tools to understand whether an identity alert is truly dangerous.
Q: What happens when identity posture data stays outside the SIEM?
A: The SOC sees signals without the surrounding identity picture, which slows investigation and weakens prioritisation.
Q: How can SOC teams respond faster when identity risk shows up in security investigations?
A: SOC teams respond faster when identity context is embedded directly in existing workflows, so investigators can assess access, privilege, and governance signals without leaving the SIEM.
Practitioner guidance
- Map identity telemetry to SOC questions Define the identity questions your analysts need answered during triage, then structure telemetry so exposure, Tier 0 paths, and posture can be queried directly in Sentinel.
- Normalize identity data into queryable tables Use a consistent table model for identity posture data so KQL searches, hunting logic, and analytics rules operate on the same governed sources.
- Set retention and deduplication rules for identity logs Align append-only identity feeds with retention tiers, duplicate handling, and review windows so historical lookbacks remain usable without bloating cost.
Bottom line: Identity telemetry only changes SOC outcomes when it is available inside the response workflow, not in a separate specialist console.
Glossary terms: Identity Telemetry, Tier 0 Asset, Identity Blast Radius, SOC Workflow Integration
What's in the full article
Semperis' full article covers the operational detail this post intentionally leaves for the source:
- Azure Function connector design for streaming Lightning Intelligence into Sentinel at scale
- How the Log Analytics table model supports KQL hunting, analytics rules, and historical investigation
- How Security Copilot agents use identity-specific KQL tools in task-based and conversational modes
- Practical examples of identity questions analysts can ask once the data is inside Microsoft security workflows
👉 Read Semperis' analysis of identity risk in Sentinel and Security Copilot →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 4 hours ago by NHI Mgmt Group
25/06/2026 10:43 am
Identity risk only becomes actionable when it is available at the point of investigation. The long-standing problem in identity security is not that defenders lack telemetry, but that the telemetry arrives outside the SOC workflow where decisions are made. When exposure and attack-path data sit in a separate console, response speed degrades and identity becomes a reporting layer rather than an operational control plane. Practitioners should treat this as a workflow design problem, not a visibility problem.
A question worth separating out:
Q: Should security teams let AI assistants query identity telemetry directly?
A: Yes, but only through governed tables and approved query paths. AI assistants are most useful when they accelerate structured evidence retrieval, not when they broaden access to raw identity data. The control point is data governance, query scope, and analyst role boundary, not the chatbot interface itself.
👉 Read our full editorial: Microsoft Sentinel and Copilot gain identity context in SOC flow
This post was modified 4 hours ago by NHI Mgmt Group