How should security teams implement ITDR alongside IAM and SIEM?

Why This Matters for Security Teams

ITDR is the missing layer when IAM proves that access was granted and SIEM proves that something happened, but neither can explain whether the identity itself is being abused. Security teams are increasingly dealing with token theft, consent abuse, directory tampering, and privilege escalation that look legitimate until the blast radius is already expanding. Current guidance suggests identity telemetry must be correlated with authentication, privilege, and directory-change activity, not treated as a separate alert feed.

That distinction matters because identity attacks often begin with valid credentials or sessions and then pivot through trusted tooling. The NIST Cybersecurity Framework 2.0 frames this as a detect-and-respond problem, but ITDR makes it identity-specific by tying activity back to the account, role, or service principal in play. NHIMG research also shows why this matters operationally: lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations in The State of Non-Human Identity Security. In practice, many security teams encounter identity compromise only after a privileged session has already been used to move laterally.

How It Works in Practice

Effective ITDR sits between IAM and SIEM. IAM remains the system of record for who or what is allowed to authenticate, while SIEM remains the broad telemetry layer that collects logs from endpoints, directories, cloud platforms, and SaaS. ITDR adds the identity context needed to recognise misuse: impossible travel, atypical consent grants, suspicious group membership changes, new device trust, abnormal token replay, or privilege changes that do not match the identity’s normal behaviour.

Practitioners usually get the best results when they connect these sources into a single detection chain:

• Authentication events from IAM, directory services, and federation providers
• Privilege changes such as role assignment, group membership, or admin consent
• Directory and configuration changes that can indicate persistence or escalation
• Session and token signals that show whether access is continuing after initial login
• Response actions that can revoke tokens, force reauthentication, disable accounts, or quarantine devices

SIEM should still do the heavy lifting for ingestion and retention, but ITDR rules should be tuned to identity abuse patterns rather than generic anomaly detection. That is where identity-specific baselining matters. For example, the JetBrains GitHub plugin token exposure incident shows how a trusted integration can become an attack path when secrets or tokens are mishandled, while JetBrains GitHub plugin token exposure is a reminder that monitoring must extend to service accounts and automation, not only employees. A related pattern appears in Azure Key Vault privilege escalation exposure, where directory and role changes can quietly convert read access into control-plane abuse. These controls tend to break down when identity telemetry is fragmented across multiple IdPs and cloud tenants because the detection logic cannot reconstruct a complete privilege timeline.

Common Variations and Edge Cases

Tighter ITDR coverage often increases tuning and integration overhead, requiring organisations to balance faster containment against alert fatigue and operational complexity. The biggest variation is whether the identity is human, privileged, or non-human. Human identities are often easier to baseline, while service accounts, OAuth apps, and API clients can generate noisy but legitimate activity. Best practice is evolving here, and there is no universal standard for this yet.

In hybrid and multi-cloud environments, ITDR often fails when directory events, SaaS audit logs, and cloud control-plane data arrive with different delays or identifiers. That makes correlation fragile unless teams standardise identity attributes and map them across systems. It also means SIEM rules alone are usually too blunt: they may flag volume spikes but miss the sequence that shows compromise. Security teams should therefore use IAM for prevention, ITDR for identity-focused detection and containment, and SIEM for broader investigation and retention. Where that model breaks down most often is in organisations with multiple identity providers and unmanaged service principals, because no single control plane sees the full attack path.

Related resources from NHI Mgmt Group

• How should security teams reduce identity silos across IAM, ITDR, and NHI tooling?
• How should security teams implement identity detection and response in IAM?
• How should security teams govern non-human identities alongside human accounts?
• How should security teams implement DSPM alongside IAM and NHI controls?