ITDR vs SIEM vs XDR: why identity needs its own layer

At a glance

What this is: This article compares SIEM, XDR and ITDR and concludes that identity-specific monitoring is the missing layer for detecting subtle credential abuse, privilege drift and session misuse.

Why it matters: It matters because IAM, PAM and NHI teams cannot rely on broad telemetry alone to spot identity abuse early enough to contain it, especially when human and machine accounts behave differently.

👉 Read Unosecur's analysis of why ITDR needs its own identity security layer

Context

Identity security now sits at the center of enterprise detection because attackers increasingly exploit credentials, privileged accounts and session behaviour rather than perimeter weaknesses. SIEM and XDR both contribute visibility, but neither is designed to continuously inspect identity behaviour at the level needed to catch low-and-slow abuse across human and machine accounts.

ITDR fills that gap by treating identity as a live security surface rather than a log source. That distinction matters for NHI governance as much as for human IAM, because service accounts, tokens and privileged sessions can drift into misuse without producing the kind of obvious event spike that SIEM and XDR are built to surface.

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. SIEM may show the login and the resource call, but not the privilege shift, session history, or trust relationship that explains the threat. Identity-specific response needs that context to contain abuse quickly.

Q: Why do identity based attacks create more risk when security controls only watch for individual events?

A: Identity based attacks create more risk because attackers can stay below the threshold of any single control while still progressing through the environment. If detections only look at one atomic event at a time, teams lose the storyline of the intrusion. That makes it harder to distinguish legitimate administration from account takeover, credential compromise, or insider driven abuse.

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. If your tooling sees activity but cannot explain whether the identity is behaving normally, detection is too shallow.

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.

Technical breakdown

Why SIEM misses subtle identity abuse

SIEM platforms centralise logs and correlate them against predefined rules. That architecture is useful for compliance, historical reconstruction and broad anomaly detection, but it assumes the suspicious pattern will be visible as an event worth matching. Identity abuse often starts as a series of small changes, such as a slow shift in login behaviour or a gradual change in privilege use, which can remain below threshold until the attack is already established. In practice, SIEM is strongest after the fact, not during the identity attack’s quiet phase.

Practical implication: use SIEM for investigation and auditability, but do not expect it to be your primary control for detecting nuanced identity misuse.

How XDR broadens telemetry without solving identity granularity

XDR merges endpoint, network and cloud signals into a cross-domain detection layer. That improves visibility into lateral movement and broader attack chains, but identity often remains an input rather than the analytical focus. When the control plane prioritises system-level events, incremental privilege abuse, unusual session token use and account behaviour drift can be underweighted. XDR can tell you something is happening across the environment, but it may not explain whether the identity itself has become the weak point.

Practical implication: enrich XDR with identity context, or it will continue to miss low-signal identity attacks that never look dramatic at the infrastructure layer.

Why ITDR treats identity as an always-on detection surface

ITDR is designed to continuously monitor identity configuration, permissions and behaviour across user and service accounts. The core idea is behavioural context: baseline normal access patterns, then detect deviations such as dormant accounts waking up, unusual access requests, unexpected privilege escalation or suspicious session activity. That makes ITDR more specific than generic analytics because it evaluates identity state in motion, not just the presence of credentials. For NHI governance, this is especially important because machine accounts often have stable names but unstable usage patterns.

Practical implication: build identity detection around live behaviour baselines and privilege context, not around static account inventories alone.

Threat narrative

Attacker objective: The attacker wants to use legitimate identity behaviour as cover so access looks normal until sensitive systems, data or administrative paths are reached.

1. Entry begins with credential theft, privileged account abuse or session impersonation that reuses legitimate identity material instead of exploiting a perimeter weakness.
2. Escalation occurs when the attacker leverages that identity to expand privileges, reuse tokens or move into resources that the original account can access.
3. Impact follows when the attacker blends into routine identity activity long enough to evade generic event correlation and operate across human and machine accounts.

Breaches seen in the wild

• Sumo Logic breach 2023: A compromised credential opened a Sumo Logic AWS account; customers were told to rotate API keys and stored credentials. No data impact was found.
• Mailchimp breach 2022: Attackers socially engineered Mailchimp staff, used a support tool to export 102 customer lists and exposed customer API keys for phishing.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

ITDR is the identity-layer answer because it closes the behavioural gap: XDR improves cross-domain awareness, but it still tends to treat identity as one signal among many. ITDR becomes necessary when the security question is not simply what happened in the environment, but whether the account itself is behaving outside its normal trust boundary. That is a different control problem, and it belongs with IAM and PAM decision-making.

Identity drift is the right named concept for this category: the article shows that the highest-risk identity events are often not abrupt compromise but gradual deviation in access patterns, privilege use and session behaviour. That drift is difficult for generic telemetry to classify because each individual event can look innocuous. The implication is that identity governance must be designed around change detection, not just event collection.

Human and machine identities need the same detection principle, not the same signals: the article explicitly spans both user accounts and service accounts, which is the right framing. The governance mistake is assuming that one correlation model can cover both simply because both authenticate. Practitioners should separate identity baseline logic by actor type while keeping one policy view across the programme.

Layered detection only works when each layer owns a distinct job: SIEM should retain its forensic and compliance role, XDR should keep its cross-domain response role, and ITDR should own identity-specific behavioural analysis. Confusing those roles creates blind spots and alert fatigue at the same time. The operational conclusion is to assign identity misuse to the layer that can actually observe it.

From our research library:

• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey.
• Read next: Identity Threat Detection and Response (ITDR) Guide

What this signals

Identity drift is the operational blind spot: security programmes that rely on generic telemetry tend to miss the slow change in access behaviour that precedes identity abuse. The practical shift is to treat behavioural deviation in accounts as a detection problem in its own right, not as a side effect of infrastructure monitoring.

SIEM and XDR remain necessary, but they do not replace identity-specific analysis because they are optimised for event correlation and cross-domain visibility rather than privilege context. The programme question is no longer whether to add another dashboard, but whether identity has a dedicated detection layer with ownership, baselines and response triggers.

For practitioners

• 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.
• Enrich broad telemetry with identity context Feed privilege level, historical access patterns and account purpose into your detection pipeline so cross-domain tools can evaluate identity behaviour instead of raw events alone.

Key takeaways

• Identity abuse is often invisible to broad telemetry until the attacker is already inside the trust boundary of an account.
• SIEM and XDR remain useful, but neither is purpose-built to track privilege drift, session misuse or subtle identity behaviour changes.
• Organisations need a distinct identity detection layer if they want to reduce dwell time and respond before normal-looking access turns malicious.

Key terms

• Identity Threat Detection and Response: Identity threat detection and response is the practice of finding misuse of credentials, unusual access patterns, and compromised identities across human and machine actors. For NHIs, it relies on telemetry from code, vaults, cloud services, and pipelines to detect abuse early enough to contain it.
• Identity Drift: Identity drift is the gap between the access path originally approved and the behavior that exists later. For browser extensions, drift can appear through updates, remote configuration, publisher changes, or permission expansion, turning a trusted integration into a materially different risk.
• Session impersonation: Session impersonation is when an attacker or malicious actor uses an existing authenticated session or session token to act as if they are the real user or workload. The activity may look valid to basic monitoring because the session itself is authenticated, even though the actor behind it is not.
• Behavior Baseline: A record of normal activity for a non-human identity, including typical consumers, resources, and actions over time. Baselines help security teams detect when an identity is being used in an unusual way and provide the context needed to enforce least privilege safely in dynamic environments.

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

👉 Unosecur's full post explains how ITDR, SIEM and XDR differ in detection depth and response scope.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.