What Is ITDR? Identity Threat Detection and Response

ITDR, or identity threat detection and response, is the practice and tooling for spotting attacks that abuse identities, and the systems that manage them, and then shutting those attacks down. Where most security tools watch endpoints, networks or applications, ITDR watches the identity layer itself: your directory, your identity provider, your privileged accounts, and the tokens and credentials moving between them.

The term came from Gartner in 2022, which means it arrived with the usual cloud of vendor marketing. Underneath the marketing is a real gap, and most organizations I talk to have it. This post covers what ITDR is, what it actually detects, how it differs from the tools you already own, and how to start without buying anything on day one.

Why do attackers target identity?

Because it works. An attacker with valid credentials doesn’t need an exploit, doesn’t trip most malware detection, and looks a lot like an employee having an unusual day. Logging in is quieter than breaking in.

The common techniques fall into a few groups:

• Credential theft. Phishing, password spraying, credential stuffing with passwords leaked from other breaches, and infostealer malware that scoops saved browser passwords and session cookies. I covered the broader menu in common cyber threats.
• MFA fatigue. Also called push bombing. The attacker already has the password and sends push notification after push notification until someone taps Approve to make it stop. It’s low tech and it works far more often than it should.
• Token and session theft. If an attacker steals a session cookie or OAuth refresh token after the user has signed in, MFA has already happened. The attacker replays the token and skips the login entirely. Adversary-in-the-middle phishing kits make this available to people with very little skill.
• Active Directory attacks. AD is still the identity backbone for most enterprises, and it has well-documented weaknesses. Kerberoasting requests service tickets for accounts with service principal names and cracks them offline, which is why weak service account passwords are so dangerous. A Golden Ticket attack uses the stolen KRBTGT account hash to forge Kerberos tickets for any user, effectively giving the attacker the keys to the domain until KRBTGT is reset (twice). Pass-the-hash, DCSync and abuse of overly permissive ACLs round out the list.
• Privilege escalation through misconfiguration. Nested groups nobody understands, stale admin rights, service accounts with domain admin “because it was easier.” Attackers map these paths with freely available tools and walk them.

The thread through all of these: the attacker ends up with a legitimate identity doing things that legitimate identity is technically allowed to do. Preventive controls struggle with that. Detection has to fill the gap.

A common version of this: Picture a typical MFA fatigue case. The attacker has a password from an infostealer log, sends push prompts late in the evening, and the user approves one to make it stop. The IdP logs a successful MFA sign-in, the EDR sees nothing because no malware touched an endpoint, and the SIEM has the events but no rule connecting a burst of denials to the approval that followed. Every tool did its job, and nobody noticed. That gap is what ITDR exists to close.

What does identity threat detection and response actually do?

ITDR has two halves, and both matter.

Detection

ITDR tools collect telemetry from identity systems (domain controller events and Kerberos traffic, IdP sign-in logs, MFA events, PAM session and checkout activity, cloud directory audit logs) and look for patterns that indicate abuse. Typical detections include:

Detection	What it might mean
Many Kerberos service ticket requests from one account in a short window	Kerberoasting
Kerberos tickets with abnormal lifetimes or no matching authentication	Forged tickets (Golden or Silver Ticket)
Replication requests from a host that isn’t a domain controller	DCSync
Burst of MFA push denials, then an approval	MFA fatigue that succeeded
Session token used from a new device or location minutes after sign-in	Token theft and replay
Impossible travel, or a sign-in from an unusual ASN	Compromised credentials
A privileged account used outside of a PAM checkout	Credentials taken out of band, or a bypass
Sudden membership change in a highly privileged group	Escalation or persistence

The better tools also do posture work, sometimes called identity security posture management: finding the misconfigurations before an attacker does. Accounts with SPNs and weak password policies, unconstrained delegation, dormant admins, risky ACL paths to Domain Admins. Fixing those is cheaper than detecting their abuse.

Response

Detection without response is just a more expensive log. ITDR response actions usually include:

• Revoking sessions and refresh tokens
• Forcing a password reset or step-up MFA
• Disabling or suspending the account
• Pulling the account out of privileged groups
• Rotating a credential through the PAM vault
• Opening an incident and handing context to the SOC

The goal is to act in minutes. Identity attacks move fast once an attacker has a privileged foothold, and an alert that waits in a queue until Monday is not a response.

How is ITDR different from IAM, PAM, EDR and SIEM?

This is where most of the confusion lives, because every vendor in these categories now claims some ITDR capability. Here’s how I separate them:

Tool	Main job	Where it falls short on identity attacks
IAM (SSO, MFA, directory)	Authenticates users and grants access	Focused on letting the right people in, not on noticing when a valid session is being abused
PAM	Vaults, rotates and brokers privileged credentials; records sessions	Strong control over the accounts it manages, but blind to privileged access that happens outside it
EDR / XDR	Detects malicious activity on endpoints and correlates across sources	Sees the process, not always the meaning of the Kerberos request or the IdP event
SIEM	Collects and correlates logs from everything	Can do identity detection, but only if someone builds and tunes the rules, and most teams haven’t
ITDR	Detects and responds to abuse of identities and identity infrastructure	Doesn’t prevent access on its own; depends on good integrations to act

The short version: IAM and PAM are mostly preventive. They decide who gets in and how. ITDR assumes that some of those decisions will be wrong, or that a valid credential will end up in the wrong hands, and watches for it.

ITDR and PAM pair particularly well. PAM gives you a known-good baseline (“this admin account should only ever be used through a vaulted session”), and ITDR tells you when reality departs from it. If you’re comparing PAM platforms, it’s worth asking how each one feeds or integrates with identity threat detection; I touched on that in my CyberArk vs. BeyondTrust vs. Delinea comparison.

On the SIEM point, I’ll be honest: a well-staffed SOC can build much of this in a SIEM. Most SOCs are not that well staffed, and identity detection logic is specialized. That’s the real argument for a dedicated tool or a platform with ITDR built in.

Where does ITDR fit in Zero Trust?

Zero Trust has three principles: verify explicitly, use least privilege, and assume breach. ITDR lives in the third one.

Verifying explicitly and enforcing least privilege reduce how often an attacker gets in and how far they can go. Assume breach says plan for the attacker who gets in anyway. For identity, that means continuously checking whether authenticated sessions still behave like their owners, and being able to cut them off quickly when they don’t.

I made the case in What Is Zero Trust? that it’s a program, not a product, and that identity is the right place to start. ITDR is what closes the loop on that identity pillar. Without it, you’ve built a very good front door and stopped watching the hallways.

Can ITDR help with insider threats?

Yes, with limits. A malicious insider uses their own legitimate credentials, so prevention-focused tools see nothing wrong. ITDR looks at behavior: an account suddenly accessing systems it never touches, privilege changes that didn’t go through a request, a privileged account used at 2 a.m. from a personal device.

The same detections that catch an external attacker using stolen credentials often catch an insider misusing their own, because from the identity layer the two look similar. What ITDR won’t do is tell you intent. That still takes HR, legal and a human investigation. There’s more on that side in my post on insider threats.

How do you get started with ITDR?

You don’t need to start with a purchase order. A practical sequence:

1. Know your identity infrastructure. List your directories, IdPs, PAM platforms and federation trusts. Hybrid AD plus a cloud IdP is the common case, and both need coverage.
2. Clean up the obvious posture issues. Service accounts with SPNs and old passwords, accounts with unconstrained delegation, dormant privileged accounts, and anything with Domain Admin that doesn’t need it. Free and open-source AD assessment tools will surface most of these in an afternoon.
3. Get identity logs flowing. Domain controller security events, IdP sign-in and audit logs, MFA logs and PAM activity, all in one place with enough retention to investigate.
4. Start with a short list of high-value detections. Kerberoasting, DCSync from non-DCs, MFA fatigue, privileged group changes, and privileged accounts used outside PAM. Get those working before chasing the long tail.
5. Define response playbooks and test them. Who can revoke sessions? Who can disable a privileged account at 2 a.m.? Can the SOC actually do it without calling the identity team?
6. Then evaluate tools. Look at what you already own first. Many IdP, EDR/XDR and PAM platforms now include identity threat detection features, and you may be closer than you think. If you buy a dedicated product, test it against your own environment, not the vendor’s demo.

What I’d look for: The first thing I’d check is whether privileged accounts can be used outside PAM without anyone knowing. If a domain admin logs on directly to a server, does an alert fire, and does a person see it? The common gap is that domain controller logs, IdP logs and PAM activity live in different places, so nobody correlates them. Second question: can the SOC actually revoke a session or disable an account at night without waiting for the identity team?

The short answer

ITDR is detection and response aimed at the identity layer: catching stolen credentials, hijacked sessions, Kerberos abuse and privilege escalation, then cutting them off fast. It doesn’t replace IAM, PAM, EDR or your SIEM. It covers the gap between them, where an attacker with a valid login can otherwise operate unnoticed.

If you take one thing from this: attackers log in more often than they break in, so watch the logins. Start with the posture fixes and a handful of high-value detections, make sure someone can act on them, and build from there. More on the identity side at /topics/identity-security/.