Identity Threat Detection and Response (ITDR): Enterprise Security Playbook 2026

Your SIEM fired zero alerts while attackers moved laterally through your network for 194 days using valid credentials. No malware signature, no dropped file, no exploit. Identity Threat Detection and Response (ITDR) is the security discipline built to catch the attacks that look like normal user behaviour to every other tool in your stack: credential misuse, privilege escalation with legitimate accounts, and Active Directory compromise that leaves almost no trace in a standard log pipeline.

This guide is for IT security managers, SOC leads, and architects who need to evaluate whether their detection stack covers identity-based attack paths. It covers what ITDR is, how it differs from existing tools, which seven attack patterns it must detect, and how to deploy it in a phased enterprise rollout.

Why ITDR Exists: The Detection Gap in Enterprise Security

Enterprise security teams invest heavily in two detection layers: SIEM for log aggregation and correlation, and EDR for endpoint behavioural analysis. Both assume the attacker will eventually do something recognisably malicious on a specific system. Identity attacks break that assumption entirely.

An attacker holding valid credentials for a privileged account can move through Active Directory, cloud consoles, and SaaS applications without triggering a DPAPI alert, without dropping a malicious file, and without matching a known signature. From the SIEM's perspective, a legitimate admin is working late. From the EDR's perspective, nothing is wrong. ITDR supplies the missing layer.

CISA's advisory AA23-216A identified identity-based attacks as the primary initial access vector used by advanced persistent threat actors against US critical infrastructure, noting specifically that existing SIEM deployments often lack the identity-specific correlation rules to detect these intrusions before lateral movement begins.

ITDR vs SIEM vs EDR: What Each Layer Covers

ITDR is not a replacement for SIEM or EDR. It feeds into both. It is a specialist layer that generates high-fidelity identity alerts that enrich SIEM investigations and can trigger EDR response actions on the targeted endpoint.

The 7 Identity Attack Patterns ITDR Must Detect

These patterns represent the most common techniques used in enterprise identity-based intrusions. Each is documented in MITRE ATT&CK under the Credential Access and Lateral Movement tactics.

1. Credential Stuffing Against the Identity Provider

Automated login attempts using breached username and password pairs against Okta, Microsoft Entra ID, or Ping Identity endpoints. Detection signal: high volume of failed authentication attempts from a distributed IP range, followed by one successful login that immediately triggers a session creation. ITDR differentiates this from a forgotten-password scenario by correlating attempt volume, source IP reputation, and the geographic origin of the successful login against the account's established baseline.

2. Impossible Travel

A user authenticates from London at 08:45 and from Singapore at 09:30. No commercial flight covers that distance in 45 minutes. ITDR maps authentication events against geolocation data and flags pairs that require movement faster than commercially possible. This is one of the most reliable signals for session token replay attacks originating from threat actors in other time zones.

3. Kerberoasting

Any authenticated domain account can request Kerberos service tickets for service principal names (SPNs). If those service accounts use weak passwords, the tickets can be cracked offline in minutes with Hashcat. Detection signal: a single account generating an unusually large number of Kerberos TGS requests against multiple SPNs in a short window. Normal users generate a small number of TGS requests per session; Kerberoasting generates dozens or hundreds within minutes.

4. DCSync

DCSync mimics the replication protocol domain controllers use to synchronise password hashes. An attacker with Replicating Directory Changes permissions calls MS-DRSR to pull NTLM hashes for every account in the domain, including the KRBTGT account used to forge Golden Tickets. Detection signal: a non-domain-controller host initiating MS-DRSR replication calls. This is almost never a legitimate operation on a managed enterprise network.

5. Pass-the-Hash and Pass-the-Ticket

Instead of cracking a stolen NTLM hash, an attacker passes it directly to authenticate as the victim without knowing the plaintext password. Pass-the-Ticket performs the same operation using a Kerberos ticket. Detection signal: NTLM authentication from a host that is not the account's typical workstation, or a Kerberos ticket used from a machine that did not originate the initial authentication request. Both appear as valid logins in raw authentication logs without ITDR correlation.

6. Privilege Escalation Outside Change Windows

An attacker adds an existing standard user account to the Domain Admins or Global Admins group. Without ITDR, this looks like a routine administrative change. With ITDR, it is correlated against the change management calendar, the account's historical privilege level, and the time of day. A Global Admin grant at 02:30 on a Sunday with no associated change ticket is a high-confidence alert.

7. Golden Ticket and Silver Ticket Attacks

A Golden Ticket is a forged Kerberos TGT created using the KRBTGT account hash, granting persistent domain access for up to 10 years by default. A Silver Ticket forges a service ticket for a specific application. Detection signals: Kerberos tickets with lifetimes exceeding the domain's configured maximum, tickets where the account RID does not match the account name, or privilege attributes that exceed what the account should hold. Standard log inspection does not surface these. Dedicated ITDR analysis is required.

Core Detection Signals: What to Monitor

A practical ITDR deployment focuses on these seven telemetry categories. Each maps to one or more of the attack patterns above.

• Authentication logs: Every success and failure event from Active Directory, Entra ID, Okta, or Ping, including source IP, device ID, geographic location, and MFA outcome
• Directory change events: Group membership changes, privilege escalations, new account creation, and permission delegation changes
• Kerberos ticket requests: Volume and target of TGS requests per account, ticket lifetimes, and anomalous ticket attributes
• Service account activity: Any interactive login by a service account, cross-system authentication patterns, and deviation from the account's established behaviour baseline
• Admin session activity: Out-of-hours access, access from new devices, geographic anomalies, and actions that exceed normal administrative scope
• Replication events: MS-DRSR calls from non-domain-controller hosts, which indicate a potential DCSync attempt
• MFA event data: Push notification responses, TOTP validations, failed attempts, and changes to registered MFA devices or phone numbers

Enterprise ITDR Products in 2026

Several vendors now offer dedicated ITDR capabilities. The right choice depends on your existing identity infrastructure and whether you need a standalone product or an add-on to a platform you already operate.

Microsoft Entra ID Protection is the default starting point for organisations running M365 with a P2 or E5 licence. It requires no additional agents and supports risk-based conditional access policies that can step up authentication or block sessions automatically when anomalies are detected. For organisations with significant on-premises Active Directory infrastructure, CrowdStrike Falcon Identity or SentinelOne Singularity Identity offer deeper coverage of AD-specific patterns like Kerberoasting and DCSync.

Implementing ITDR: A 5-Step Enterprise Rollout

Step 1: Establish Identity Telemetry Baselines (Weeks 1-2)

Before any detection rule goes live, collect two to four weeks of authentication and directory change logs without alerting. This gives ITDR tools the data to establish normal behaviour patterns for each account. Deploying detection rules without baselines produces alert fatigue within days. Key baseline data: typical login hours, usual source IPs and device IDs, standard daily authentication volume, and expected directory change frequency for admin accounts.

Step 2: Connect Identity Sources to ITDR (Weeks 2-3)

Integrate Active Directory, your cloud identity provider, MFA platform, and privileged access workstation logs. For Microsoft environments, enable Entra ID audit logs with the full sign-in event schema. For on-premises AD, configure Windows Security Event log forwarding with Kerberos authentication events (Event IDs 4768, 4769, 4771) and directory change events (4728, 4732, 4756, 5136). Most ITDR platforms ship with connectors for these sources.

Step 3: Prioritise High-Signal Detection Rules (Weeks 3-4)

Start with the five rules that produce the highest-confidence alerts at the lowest false positive rate: impossible travel, privilege escalation outside change windows, DCSync from non-DC hosts, service account interactive logins, and high-volume Kerberos TGS requests from a single account. Tune thresholds against your baseline data before enabling automated response actions. One miscalibrated rule that fires on legitimate activity generates enough noise to kill analyst confidence in the entire tool.

Step 4: Connect ITDR Response Actions to Identity Provider Policies (Weeks 4-6)

ITDR without automated response is a detection tool that requires manual triage for every alert. Connect high-confidence findings to identity provider response policies: force an MFA re-challenge on medium-risk sessions, require admin-approved step-up authentication for high-risk sessions, and trigger immediate session revocation for critical-severity events like DCSync or Golden Ticket detection. Microsoft Entra Conditional Access, Okta Adaptive MFA, and Ping Access all support risk-signal-driven policy triggers via API.

Step 5: Integrate ITDR Alerts into SIEM and Incident Response (Ongoing)

ITDR alerts should flow into your existing SIEM as high-priority incidents. Map each ITDR alert category to the corresponding MITRE ATT&CK technique and your NIST SP 800-61 incident response procedures. SOC analysts should know immediately which playbook to open when a Kerberoasting alert arrives, not search for one during active triage. Document response procedures for each of the seven attack patterns before the ITDR deployment goes live.

The Credential Management Foundation ITDR Depends On

ITDR detects attacks in progress. It cannot prevent an attacker from obtaining credentials in the first place. The two controls that reduce what ITDR needs to catch are eliminating password reuse and enforcing phishing-resistant MFA on privileged accounts.

Credential stuffing, the most common initial access pattern targeting enterprise identity providers, depends entirely on passwords appearing in breach databases. A centralised enterprise password manager removes reuse across accounts and enforces complexity without relying on users to manage distinct credentials for every system. NordPass Business provides zero-knowledge encrypted vaults with admin policy enforcement, bulk credential auditing, and a breach exposure scanner that alerts when stored credentials appear in known leak databases, directly reducing the attack surface ITDR monitors at the authentication layer.

FIDO2 hardware security keys on privileged accounts eliminate Pass-the-Hash, Pass-the-Ticket, and credential relay attacks at the source. FIDO2 authentication binds each login to the physical device and the originating domain. There is no password hash to steal and no ticket to replay. For the accounts ITDR monitors most closely (domain admins, cloud console admins, CI/CD platform operators), hardware key enforcement removes entire attack categories from the detection queue.

ITDR Implementation Checklist

• Identity telemetry sources connected: Active Directory, cloud IdP, MFA platform, PAM logs
• Behavioural baselines established before detection rules activate (minimum 2 weeks of data)
• Impossible travel, privilege escalation outside change windows, and DCSync rules live and tuned
• Service account behaviour baselines in place: expected hosts, hours, and target systems
• Automated identity provider response policies connected to medium and high-risk ITDR alerts
• ITDR alert categories mapped to SIEM incident queue and documented response playbooks
• Privileged accounts enrolled in FIDO2 hardware key authentication
• Enterprise password manager deployed to remove browser-stored credentials and eliminate password reuse
• KRBTGT password rotation scheduled as a standard response to any Golden Ticket detection
• ITDR alert handling included in quarterly SOC tabletop exercises

Frequently Asked Questions

What is Identity Threat Detection and Response (ITDR)?

ITDR is a security discipline focused on detecting attacks that target enterprise identity infrastructure: credential misuse, privilege escalation via valid accounts, Active Directory attacks like Kerberoasting and DCSync, and identity provider compromise. It differs from SIEM and EDR by using identity-specific behavioural baselines rather than signature-based or network-based detection.

How is ITDR different from SIEM?

SIEM aggregates logs from many sources and applies rule-based correlation. ITDR focuses exclusively on identity telemetry with per-account behavioural baselines. A SIEM catches known bad signatures; ITDR catches behaviour that deviates from what a specific user or service account normally does, even when that behaviour uses only valid credentials and built-in system tools.

What are the most important ITDR detection signals?

In order of detection confidence: impossible travel, DCSync from non-domain-controller hosts, privilege escalation outside change windows, high-volume Kerberos TGS requests from a single account (Kerberoasting), service account interactive logins, and NTLM authentication from an unexpected host as a Pass-the-Hash indicator.

Which tools provide enterprise ITDR capabilities?

Microsoft Entra ID Protection (P2 licence), CrowdStrike Falcon Identity Threat Protection, SentinelOne Singularity Identity, Vectra AI, and Okta ThreatInsight. For organisations already running M365 E5, Entra ID Protection is the natural starting point with no additional agent deployment required.

Does ITDR replace SIEM and EDR?

No. ITDR is a specialist layer that generates high-fidelity identity alerts for the SIEM and can trigger automated responses via the identity provider or EDR. EDR covers endpoint activity, SIEM provides broad log correlation, and ITDR covers the identity attack surface that neither handles well on its own. All three layers are complementary.

Related Reading