Identity Threat Detection and Response (ITDR)

Identity Threat Detection and Response (ITDR) is the practice and tooling of detecting attacks that use or target identities (credential theft, session hijacking, privilege escalation in directories, and misuse of legitimately held access) and of responding to them by revoking sessions, disabling accounts, or forcing re-authentication. It closes a gap between preventive IAM controls, which cannot tell an attacker's valid sign-in from the owner's, and general security monitoring, which rarely understands identity systems in depth. ITDR reads authentication events, directory activity and identity provider telemetry directly, and hands its findings to the same response processes as the rest of security operations.

Attacks That Look Like Valid Access

Most identity attacks succeed without breaking anything. A password spray tries one common password against many accounts, slowly enough that no single account locks. A phishing proxy relays the real sign-in page, lets the user complete multi-factor authentication (MFA), and keeps the session cookie the identity provider issued. A consent phishing link asks the user to grant an attacker's application access to their mailbox, and the grant is a legitimate OAuth consent. In each case the identity provider sees a correct credential, a completed factor or an approved consent, and a preventive control that checks those things has nothing to object to.

ITDR looks for what is wrong around the valid step. Failures spread thinly across hundreds of accounts from a few sources are a spray. A session that was issued to one device and then presented from another network and a different client is a stolen cookie; Device Bound Session Credentials remove the replay for browsers that support them, and ITDR catches the attempt where they do not. A run of declined MFA prompts followed by one approval is push fatigue. A new application consented to by many users within an hour, or requesting mail and file scopes it has no reason to need, is a consent campaign.

The directory is the second target. In an on-premises Kerberos domain, an attacker with any account can request service tickets for accounts with a service principal name and crack their passwords offline (Kerberoasting). One who has gained replication rights can request directory replication as if they were a domain controller to extract every password hash, and one who holds the key that signs tickets can forge them. These leave no failed sign-in behind. They show up as unusual ticket requests, replication requests from a machine that is not a domain controller, or tickets whose properties the domain would never have issued, and seeing them requires reading the directory's own protocol activity rather than a sign-in log.

The third target is the trust the identity system extends to others. An attacker with enough privilege adds a federation trust, registers a token-signing certificate or adds a credential to an application registration, and can then mint valid tokens without touching a user account at all. ITDR treats these configuration changes as detections in their own right, because each one is rare, and every one made outside a change request deserves an explanation.

What ITDR Reads, and What It Compares Against

ITDR's advantage over general monitoring is that it reads identity systems in their own terms. It takes the identity provider's sign-in and audit logs through their native interfaces, observes directory protocol traffic or the domain controllers' own events, and in some deployments reads session and token material on endpoints, where stolen cookies are used. It consumes events from the Shared Signals Framework (SSF) where applications transmit them, and it can transmit a Continuous Access Evaluation Profile (CAEP) risk-level-change event when it has concluded that an account is compromised, so that every receiver can act on the conclusion.

Detection then compares what happens against a baseline: the devices, locations, applications and times that are usual for an identity, and for its peers in the same role. Human baselines are noisy, because people travel, change teams and work odd hours. Non-human identities are the easier case. A service account or a workload identity usually signs in from the same hosts, to the same targets, on a fixed schedule, so any deviation is suspicious and false positives are rare. Many ITDR deployments get their clearest early wins there.

The baseline needs to know what an identity is supposed to be. An administrator reading every mailbox is an incident unless the administrator runs the eDiscovery process; a service account signing in interactively is always wrong. That knowledge sits in identity governance, the directory and the AI agent registry, and ITDR is only as precise as its access to them.

ITDR reads the identity estate directly rather than only through the log pipeline, and hands what it finds to the same response layer as its neighbours.

ITDR collects authentication and directory activity itself and compares it against a baseline of ordinary behaviour, which is how an action every authorization control accepted still becomes an incident; it tells the estate its risk conclusion directly and hands anything destructive to the response layer.

From Detection to Response

Speed is what makes identity response worth automating: a phishing proxy's operator uses a stolen session within minutes. The cheapest effective responses feed back into the identity provider. A raised risk level makes conditional access demand a phishing-resistant factor, or block the sign-in, at the next attempt; a revoked session forces the attacker back to a login they cannot complete. Those actions are reversible, a legitimate user loses a minute at most, and ITDR tools commonly carry them out themselves.

Anything beyond that, such as disabling accounts, rotating credentials, removing what the attacker added or undoing directory changes, belongs to the playbook discipline described under SOAR: a containment order, approval before destructive steps, and changes made through identity governance so that reconciliation does not reverse them. Whether an ITDR tool or a SOAR platform executes those steps matters less than that one set of rules applies to both. The finding and every action taken on it go to the SIEM, which keeps the record the incident and its audit will be answered from.

The measure of an ITDR deployment is time, not alert count: from the first malicious sign-in to the moment the attacker's last session ends. Testing it takes an exercise, not a dashboard. A red team using a phishing proxy, a password spray and a Kerberoasting attempt shows which of them ITDR sees, how long it takes, and which applications still honour the stolen session after the response.

What ITDR Cannot See

ITDR detects use, not weakness. A privileged account without MFA, an unused federation trust or a conditional access exclusion nobody remembers is invisible to it until an attacker uses one, and finding them beforehand is the job of Identity Security Posture Management (ISPM). Coverage is the other limit: applications with their own local accounts, systems not federated to the identity provider, and SaaS tenants whose logs nobody connected produce no telemetry for ITDR to read. A coverage list per identity system, stating what is and is not observed, tells a security team where an attack would go unseen.

Misuse by the rightful holder is the hardest case. An employee exporting customer data they are entitled to read generates the same events as their ordinary work, and the only signal is volume or timing that departs from their baseline. Detection there is probabilistic, and in Germany behavioural analysis of employees also needs the works council's agreement before it starts.

AI Agent Activity

ITDR's behavioural focus makes it one of the few controls that applies when an identity is used exactly as authorized. When an AI agent is redirected by injected instructions in content it retrieves, each individual action is correctly authenticated and within the agent's granted permissions, so no authorization control registers a violation. Correlating agent activity against behavioural baselines is what surfaces the resulting privilege abuse and unusual delegation patterns, provided the events carry both the agent's identity and the user principal it acts for, as token exchange records them. Agents are closer to service accounts than to people in this respect: their tasks are narrow, so their baselines are tight, and the AI Agent Registry and Lifecycle supplies the inventory those baselines are built against.