Identity Threat Detection and Response: why identity attacks need ITDR

At a glance

What this is: ITDR is a monitoring and response layer for identity-driven attacks, focused on spotting anomalous identity activity and containing it before escalation.

Why it matters: It matters because IAM, PAM, and NHI programmes need runtime detection and response when credentials, sessions, or privileged access are already being abused.

By the numbers:

• credentials appear as the vector of attack number one for attackers, according to Verizon DBIR in 2025.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read Soffid's article on Identity Threat Detection and Response for identity attacks

Context

Identity Threat Detection and Response, or ITDR, is the practice of monitoring identity activity for signs of compromise, abuse, or abnormal behaviour. The article argues that this layer is needed because identity has become the primary control point in cloud, remote, and hybrid environments, where credential theft can bypass traditional perimeter assumptions.

For IAM teams, the important shift is that identity security can no longer stop at provisioning and policy design. ITDR extends visibility into logins, privilege changes, session behaviour, and non-human accounts, which is where many identity attacks become operational rather than theoretical.

Key questions

Q: How should security teams use ITDR to stop identity attacks in hybrid environments?

A: Teams should use ITDR as a runtime containment layer, not as a replacement for IAM or PAM. The goal is to detect abnormal identity behaviour, correlate it with risk, and trigger containment actions such as revoking sessions, resetting credentials, or forcing reauthentication before attackers can expand access.

Q: Why do identity attacks bypass traditional security controls so often?

A: Identity attacks succeed because valid credentials and sessions often look legitimate to controls that only check initial authentication or static policy. Once access is granted, the attacker can operate inside approved pathways, which is why continuous identity monitoring and response have become necessary.

Q: What do organisations get wrong about monitoring non-human identities?

A: They often monitor employees thoroughly while leaving service accounts, tokens, and bots outside the same detection model. That creates blind spots because non-human identities can carry privileged access, persist for long periods, and generate abuse patterns that differ from human logins.

Q: How can teams tell whether ITDR is actually working?

A: ITDR is working when identity anomalies are detected early enough to contain them before privilege escalation or data access occurs. Good indicators include shorter time to revoke sessions, fewer unexplained privilege changes, and coverage across both human and non-human identities.

Technical breakdown

How identity anomaly detection works in ITDR

ITDR typically builds a behavioural baseline for each identity, then flags deviations such as unusual geolocation, off-hours access, rapid privilege escalation, or atypical data access. It can also correlate those events with threat intelligence to reduce false positives and identify known malicious patterns faster. In practice, this turns identity telemetry into a detection surface rather than treating authentication as a one-time event. The value is strongest when the platform can observe human users, privileged accounts, third parties, and non-human identities in the same control plane.

Practical implication: teams need identity telemetry that is continuous, correlated, and usable across IAM, PAM, and NHI accounts.

Why automated response matters after credential abuse

Once credentials are stolen or session state is abused, manual investigation is often too slow to prevent lateral movement. ITDR systems therefore automate response actions such as step-up authentication, session revocation, account disabling, and password reset. These are containment controls, not replacement controls, and they work best when tied to well-defined risk signals rather than broad policy exceptions. The architecture is closer to identity incident response than pure monitoring, which is why integration with IAM, PAM, and SIEM matters.

Practical implication: define which identity events can trigger automated containment before an attacker reaches privilege escalation.

How ITDR extends to non-human identities

The article notes that ITDR also watches identities beyond employees, which is important because service accounts, bots, and API-connected identities often have persistent access and weak behavioural baselines. For NHI governance, this means detection must account for machine-to-machine access patterns, long-lived secrets, and privilege use that does not resemble human login behaviour. A useful ITDR programme does not assume all identities behave like people; it distinguishes expected automation from suspicious access at runtime.

Practical implication: include service accounts and other NHIs in identity detection rules, or the programme will miss common abuse paths.

Threat narrative

Attacker objective: The attacker’s objective is to turn valid identity access into silent reach across systems before defenders can interrupt the session or revoke the account.

1. Entry begins when attackers obtain or abuse credentials, which gives them a direct path into identity-controlled systems without needing perimeter compromise.
2. Escalation follows when anomalous access expands into privilege changes, suspicious session activity, or movement across cloud and hybrid resources.
3. Impact occurs when compromised identities are used to reach sensitive systems or data before defenders can revoke access or contain the session.

Breaches seen in the wild

• MITRE ATT&CK Enterprise Matrix — MITRE ATT&CK Enterprise — adversary tactics and techniques, threat detection, attack chain mapping, credential access, lateral movement, privilege escalation.
• Cisco Active Directory credentials breach — Kraken ransomware group leaked Cisco Active Directory credentials.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity threat detection is now a runtime control, not a monitoring add-on. Once credentials are the primary entry path, the security question shifts from whether identity is governed to whether misuse is visible fast enough to matter. That is why ITDR belongs beside IAM and PAM, not underneath them as a logging layer. Practitioners should treat identity telemetry as an operational control surface.

ITDR exposes the gap between provisioning-time trust and session-time abuse. IAM programmes often assume that authentication confirms legitimacy, but that assumption fails when stolen credentials behave normally enough to pass static policy checks. The field needs controls that can detect abnormal use after access has already been granted. Practitioners should expect runtime detection to absorb more of the burden previously placed on access design.

Identity blast radius: the real unit of risk is no longer the account, but how far a compromised identity can move before containment. That concept matters because hybrid environments make identity compromise cross system, cross cloud, and cross workflow. ITDR is valuable insofar as it reduces the distance between anomaly detection and containment. Practitioners should measure how much damage an identity can still do before response triggers.

NHI visibility gaps make ITDR incomplete unless machine identities are included. NHIs already outnumber human identities at scale, and the majority of organisations still lack full visibility into service accounts. That means a programme focused only on employee logins will miss a large share of realistic abuse paths. Practitioners should extend identity detection coverage to the full non-human estate, including bots, API keys, and service accounts.

From our research:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• That is why the NHI Lifecycle Management Guide is the right next resource for teams trying to close rotation and offboarding gaps.

What this signals

Identity Threat Detection and Response will increasingly be judged by how much of the NHI estate it can actually see. With only 5.7% of organisations having full visibility into their service accounts, the programme gap is not just detection quality, it is identity inventory quality. Teams should expect ITDR to become less useful unless it is paired with explicit NHI discovery and ownership mapping.

Runtime identity control is becoming the bridge between IAM, PAM, and breach containment. The organisations that adapt fastest will be the ones that treat identity telemetry as part of the response stack, not just the audit stack. That shift matters because identity compromise now moves too quickly for review cycles to be the main control.

Identity blast radius is the more useful planning metric than login volume. As access spans cloud, SaaS, and machine identities, the question is how far a compromised identity can travel before containment. If the answer is unclear, the ITDR programme is not yet mature enough.

For practitioners

• Define identity containment playbooks Map specific alert types to containment actions such as session revocation, credential reset, forced reauthentication, and temporary account disablement. Make sure the playbooks differ for employees, privileged users, and service accounts so response does not break legitimate automation.
• Baseline identity behaviour across all account classes Build behavioural baselines for human users, privileged accounts, third parties, and NHIs separately. Treat unusual geolocation, time-of-day variance, privilege jumps, and impossible access paths as different detection signals rather than one generic anomaly model.
• Integrate ITDR with IAM, PAM, and SIEM Wire identity alerts into existing control and investigation workflows so the SOC can see authentication events, privilege changes, and session actions in one sequence. Use the MITRE ATT&CK Enterprise Matrix to map identity abuse to credential access and lateral movement patterns.
• Extend monitoring to service accounts and API credentials Include long-lived tokens, service accounts, and third-party identities in the same detection scope as human identities. If machine identities are excluded, attackers can use the quietest part of the estate as the easiest route to persistence.

Key takeaways

• ITDR exists because identity compromise has become a primary attack path, not a peripheral risk.
• The biggest operational value of ITDR is fast containment after credential abuse, especially across human and non-human identities.
• Programmes that exclude service accounts, bots, or API credentials will leave the largest identity blind spots untouched.

Key terms

• Identity Threat Detection and Response: Identity Threat Detection and Response is the practice of spotting suspicious identity activity and containing it before it turns into a breach. It extends beyond login checks to session behaviour, privilege change, and machine identity use, making it especially relevant in hybrid estates where access can be abused after authentication.
• Identity telemetry: Identity telemetry is the event data produced by authentication, access, privilege, and session activity. In an ITDR programme, that telemetry becomes the evidence base for detecting abnormal behaviour, correlating threats, and deciding whether to contain an identity before it can move laterally.
• Identity blast radius: Identity blast radius is the amount of damage a compromised identity can cause before it is contained. It reflects how far access reaches across systems, clouds, and workflows, and it is a useful way to measure whether response controls are actually limiting operational impact.
• Non-human identity: A non-human identity is any account or credential used by software, workloads, bots, API integrations, or autonomous systems. These identities often have persistent access, long-lived secrets, and weak ownership discipline, which makes them a major source of hidden exposure in IAM and ITDR programmes.

What's in the full article

Soffid's full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step explanation of how the ITDR cycle detects, monitors, and responds to anomalous identity activity in practice.
• Specific examples of automated containment actions such as blocking compromised accounts, revoking sessions, and forcing stronger authentication.
• Discussion of how the platform integrates with IAM, IGA, PAM, and AM in hybrid environments.
• Operational framing for visibility across employees, privileged users, third parties, and bots.

👉 The full Soffid article covers continuous monitoring, anomaly detection, and response actions across hybrid identity estates.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.