Topic starter
23/06/2026 7:29 pm
TL;DR: Unosecur finds enterprise security tools still handle identity risk unevenly: SIEM is built for log aggregation and forensic review, XDR broadens cross-domain telemetry, and ITDR is needed for continuous identity behaviour monitoring across human and machine accounts. The real gap is that generic detection stacks assume identity abuse will surface as obvious event data, which is often too late.
Editorial analysis by NHI Mgmt Group, based on content published by Unosecur: “ITDR vs. SIEM vs. XDR: Understanding the differences – and why it matters”.
Key questions
Q: What breaks when SOC teams rely on SIEM alone for identity abuse detection?
A: They usually get broad event visibility without enough identity context to decide whether activity is malicious.
A: Identity based attacks create more risk because attackers can stay below the threshold of any single control while still progressing through the environment.
Q: What are the signs that identity detection is too weak?
A: Common warning signs include alerts that arrive only after access has already expanded, too many false positives from broad telemetry, and blind spots around service accounts or privileged sessions.
Practitioner guidance
- Map detection ownership by identity layer Define which identity events belong in SIEM, which belong in XDR, and which require ITDR so no team assumes another tool will catch subtle identity misuse.
- Baseline behaviour for human and machine accounts separately Build different normality profiles for employee accounts, service accounts and privileged sessions because their activity patterns are not interchangeable.
- Prioritise privilege drift and session misuse Look for incremental privilege changes, unusual session use and dormant account activation rather than waiting for high-severity alerts that may arrive too late.
Bottom line: Identity abuse is often invisible to broad telemetry until the attacker is already inside the trust boundary of an account.
What's in the full article
Unosecur's full blog covers the implementation detail this post intentionally leaves for the source:
- How its ITDR engine enriches identity events with historical behaviour profiles and privilege context
- Examples of automated response actions such as dynamic access revocation and session termination
- The documented financial-institution case that shows how subtle credential abuse was detected in practice
- How the vendor positions ITDR alongside existing SIEM and XDR deployments in an operational stack
👉 Read Unosecur's analysis of why ITDR needs its own identity security layer →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 3:32 am
Identity security has outgrown the SIEM-first model: SIEM still matters for history, compliance and broad correlation, but it was not designed to watch identity as a moving target. The article’s core point is that identity abuse often progresses in small increments before it becomes a log-worthy event. Practitioners should stop treating identity as a secondary data source and recognise it as a primary detection domain.
A few things that frame the scale:
- 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: How should organisations divide responsibility between SIEM, XDR and ITDR?
A: SIEM should support auditability and forensic reconstruction, XDR should correlate broader cross-domain signals, and ITDR should own identity-specific behaviour analysis. The programme fails when all three tools are treated as interchangeable. Each layer needs a distinct operating role and a clear escalation path for identity anomalies.
👉 Read our full editorial: ITDR vs SIEM vs XDR: why identity needs its own layer