What is identity threat detection and response (ITDR)?

Where did ITDR come from?

Gartner introduced the term identity threat detection and response in 2022, listing it among that year's top security and risk management trends. The category answered a shift that incident responders had been watching for years: attackers were no longer breaking in through the network perimeter, they were logging in with valid credentials. Identity infrastructure itself, including directories, identity providers, and federation trust, had become a primary target rather than a supporting system.

The data continues to support that framing. The Verizon Data Breach Investigations Report (2025) found that 22% of breaches began with credential abuse as the initial access vector, and that 88% of basic web application attacks involved stolen credentials. Preventive controls alone were not holding, and organizations needed a way to catch identity compromise while it was happening.

How is ITDR different from IAM and ISPM?

IAM, ISPM, and ITDR form a before, during, and after sequence. Identity and access management (IAM) is preventive: it decides who gets access and enforces authentication controls such as MFA and SSO. Identity security posture management (ISPM) is proactive hygiene: it finds misconfigurations, dormant accounts, and excessive permissions before an attacker does. ITDR is detective and reactive: it assumes prevention will eventually fail and watches for the signals of an identity under active attack.

What does an ITDR system actually do?

In practice, ITDR tooling combines telemetry, detection logic, and response actions across the identity layer:

• Collects signals from identity providers, directories such as Active Directory and Entra ID, cloud IAM logs, and VPN or SSO gateways
• Baselines normal behavior per identity and flags deviations such as impossible travel, unusual privilege use, or abnormal session patterns
• Detects identity-specific attack techniques, including password spraying, MFA fatigue prompts, Kerberoasting, session token theft, and forged federation assertions such as Golden SAML
• Responds by revoking sessions, forcing reauthentication, quarantining or disabling accounts, and triggering credential rotation
• Feeds identity context into the SOC through SIEM and SOAR integrations so identity incidents are triaged alongside endpoint and network alerts

Where do non-human identities strain classic ITDR?

ITDR grew up around human accounts, and its core heuristics show it. Impossible travel, off-hours logins, unfamiliar devices, and step-up MFA challenges all presume a person with a phone, a location, and a work schedule. Non-human identities such as service accounts, CI/CD pipelines, and workload credentials have none of those properties. They operate around the clock from many locations at machine speed, so human-centric baselines either fire constantly or get tuned into silence.

The scale problem compounds the signal problem. CyberArk's Identity Security Landscape (2025) found that machine identities outnumber human identities 82 to 1, and that 42% of machine identities hold privileged or sensitive access. Response playbooks break down too: you cannot call a service account to verify a login, and disabling one or resetting its secret can take down production. NHI response requires knowing what depends on a credential before you touch it.

What changes when AI agents enter the picture?

AI agents stress ITDR even further than traditional NHIs. A service account does roughly the same thing every day, so once baselining is adapted for machines it can work. An agent is non-deterministic by design: its legitimate behavior varies with every task it is given, which makes anomaly detection against a historical baseline unreliable in both directions. Agents also chain identities, acting through delegated tokens, connected tools, and protocols such as MCP, so a single action may traverse several credentials and the question of who actually did what becomes hard to answer from login events alone.

For ITDR to cover agents, detection has to move from login-time signals to action-time signals: which identity performed which operation, under whose delegation, and whether it fell inside the scope that identity was granted for the task at hand. Response has to become equally precise, revoking one agent session or one delegated token rather than disabling a shared account that dozens of workflows depend on.

What does an identity attack look like end to end?

The clearest way to see what ITDR has to catch is to walk a composite intrusion, assembled from the patterns incident responders describe over and over. It starts small: an employee installs a cracked utility on a personal machine, and an infostealer quietly exports every saved password and session cookie from the browser, including a profile synced from the work laptop. The attacker who buys that log never has to beat MFA. The stolen cookie represents a session that already passed it, which makes this token theft rather than a login attack, and replaying the cookie through a residential proxy near the victim's city keeps impossible-travel logic quiet from the first minute.

With a live session in hand, the attacker builds persistence before doing anything loud. They enroll an extra MFA method, register a device, and grant a plausible-looking productivity app broad mailbox scopes, the same grant mechanics that power consent phishing. Now a password reset alone fixes nothing: the OAuth grant and the rogue MFA method both survive it. Searching the mailbox turns up what secret sprawl always leaves behind, an API key pasted into a two-year-old thread, and that key opens a service account with standing access to production data. An intrusion that began with one phished human is now operating as a non-human identity that no MFA prompt or travel heuristic will ever touch.

Every hop in that chain is a detection opportunity, and the misses compound:

• The cookie replay is catchable as an anomalous session: same token, new device fingerprint, new network on a session that never re-authenticated
• A new MFA method plus a new device within minutes of a fresh session is a classic persistence sequence that warrants automatic step-up or revocation
• A first-time OAuth grant requesting broad mail scopes deserves review before it starts pulling data, not after
• The service account suddenly reading data it has never touched, at a rate no scheduled job produces, is the last and often only machine-side signal left

How do you implement ITDR?

ITDR programs fail more often from sequencing than from tooling. Posture work and detection work reinforce each other but answer different questions, a split covered in ITDR vs ISPM, and the detection side has a workable build order:

• Inventory first. Build one list of every identity, human and non-human, each with a named owner. You cannot detect on behalf of accounts you do not know exist, and unowned accounts stall every response decision. If identity sprawl is severe, fix discovery before writing a single detection.
• Wire the telemetry. Stream identity provider sign-in and audit logs, directory changes, cloud IAM events, and OAuth grant activity into one place, with each event resolved to a common identity key rather than a raw username.
• Deploy deterministic detections before anomaly detection: password spraying, MFA fatigue sequences, suspicious federation changes, dormant-account revival. These fire on technique rather than baseline, so they work on day one with zero history.
• Add behavioral baselines per identity class, not per fleet. Humans get travel, device, and schedule logic. Service accounts get source, target, and volume envelopes. Mixing the two produces noise on one side and silence on the other.
• Pre-authorize response. Decide in advance which detections may revoke a session automatically, which downgrade standing privileges to just-in-time approval, and which require a human, and get that sign-off before the first real incident rather than during it.
• Shrink what detection has to cover. Every standing credential you eliminate is telemetry you no longer need to baseline, which is why zero standing privileges is as much an ITDR strategy as an access strategy.
• Rehearse the scenario where the identity provider itself is compromised: who responds, and through what channel, when the system you use to authenticate responders is the thing under attack.

How does identity detection work under the hood?

Most identity detection stacks layer three kinds of logic. Deterministic rules match known technique artifacts: a Kerberos ticket requested with a deliberately weak encryption type, a federation certificate added outside a change window, a sign-in that skips expected policy evaluation. Statistical baselines model each identity's history, its source networks, target applications, hour-of-day rhythm, and typical volume, then score deviation from that history. Correlation joins events across systems, so that an endpoint infostealer alert, a new MFA enrollment, and an unusual OAuth grant resolve into one incident with one timeline instead of three tickets in three queues.

The unglamorous hard part is identity resolution. The same person appears as a directory account, a cloud IAM principal, several SaaS usernames, and an email address. The same workload appears as a role, a Kubernetes service account, and an OAuth client ID. Until those aliases resolve to one principal, per-identity baselines fragment, and an attacker who hops between aliases looks like five quiet accounts instead of one loud one. This is also where entitlement context from CIEM earns its keep: knowing what a compromised principal can actually reach is what turns an anomaly score into a blast-radius estimate a responder can act on.

What are the most common ITDR mistakes?

The recurring failure modes are organizational as much as technical:

• Treating ITDR as a SIEM rule pack. Without response plumbing back into the identity provider, detection produces tickets, not containment, and dwell time barely moves.
• Onboarding only human identities. With machine identities outnumbering humans 82 to 1, a human-only deployment monitors a small minority of the accounts an attacker can use.
• Tuning machine-identity alerts into silence instead of building machine-specific baselines, which quietly recreates the blind spot the tuning was supposed to manage.
• Revoking the session but not the persistence. If the OAuth grants, MFA methods, and registered devices added during a compromised session survive the response, the attacker walks back in after the incident is closed.
• Ignoring new identity surfaces. Unsanctioned shadow AI tools and browser-based agents mint credentials and grants that never appear in the telemetry ITDR was pointed at.
• Skipping ownership mapping. An alert on a service account nobody owns cannot be safely actioned, so it ages out of the queue instead, which is indistinguishable from having no detection at all.

Where does ITDR go from here?

The common thread across these mistakes is stopping at detection, treating the alert as the deliverable. The direction of travel is toward runtime identity security: checking each action against a verified identity and its intended scope as it executes, so that the distance between signal and containment shrinks to the point where response is precise enough, and safe enough, to automate.

Frequently asked questions

Related terms