ITDR: Detecting and Responding to Identity Threats

Every modern breach investigation eventually arrives at the same artifact: a credential. Not a zero-day, not a firewall misconfiguration — a token, a service account, an over-permissioned role, or a session cookie that outlived its purpose. Identity Threat Detection and Response (ITDR) is the discipline built to catch that moment before it becomes a headline, and doing it well requires treating identity — human and non-human — as the primary control plane of the enterprise, not an afterthought bolted onto the network perimeter.

Why identity is the new perimeter

The traditional security model assumed a defensible boundary: a network edge, a VPN concentrator, a DMZ. Attackers who breached that edge still had to move laterally through segmented networks, escalate privileges on individual hosts, and evade endpoint controls at every hop. That model has been dissolving for a decade, and identity has replaced the network as the thing an attacker actually needs to compromise. SaaS sprawl, hybrid cloud, remote work, and API-first architectures mean that a valid identity — a username and password, an OAuth token, an API key, a service principal — is frequently sufficient to reach production data, cloud consoles, source repositories, and financial systems, all without ever touching a corporate-owned network segment.

This shift shows up starkly in incident data. Verizon's DBIR and multiple vendor breach reports have consistently placed credential abuse, phishing-derived credential theft, and stolen session tokens among the top initial access vectors for several years running. Ransomware crews increasingly skip malware delivery altogether, logging in with legitimate remote access credentials purchased from initial access brokers. Cloud incident response teams report that the median time from a stolen access key appearing on a paste site to it being used against a production AWS or Azure account is now measured in hours, not days.

What makes identity uniquely dangerous as an attack surface is that a compromised identity does not look like an attack. A firewall rule violation, a malformed packet, an unsigned binary executing — these have shapes that signature and heuristic detection can recognize. A valid login from a valid account, using a valid password, from a plausible geography, followed by normal-looking API calls, is by definition indistinguishable from legitimate use at the point of authentication. The attacker is not exploiting a flaw in the identity system; they are using it exactly as designed. This is why ITDR exists as a distinct discipline from both traditional IAM (which is concerned with provisioning and access policy) and traditional SIEM/EDR (which is built around network and endpoint telemetry). ITDR closes the gap between "who is allowed to do this" and "is this specific instance of doing it consistent with how this identity actually behaves."

The modern identity attack surface

Human identities

Human identity risk begins with credential theft — phishing, MFA fatigue attacks, SIM-swapping, infostealer malware harvesting browser-stored passwords and session cookies — and extends into the far messier problem of entitlement sprawl. A typical enterprise employee accumulates access across dozens of SaaS applications, cloud consoles, and internal tools over a multi-year tenure, and that access is rarely fully revoked when a role changes. Standing privileged access — domain admin, cloud IAM admin, database superuser roles held indefinitely rather than checked out for the duration of a task — multiplies the blast radius of any single compromised account.

Non-human identities

The more consequential shift over the last five years is the explosion of non-human identities: service accounts, API keys, OAuth application grants, CI/CD pipeline credentials, Kubernetes service accounts, and machine-to-machine certificates. Industry estimates from identity vendors now put the ratio of machine identities to human identities at somewhere between 45:1 and 80:1 in large cloud-native organizations, and that ratio is climbing as agentic AI systems, automation platforms, and microservice meshes proliferate. Non-human identities are disproportionately dangerous for three structural reasons:

• They are long-lived by default. A service account credential minted during initial deployment frequently outlives the engineer who created it, the ticket that justified it, and often the application it was built for.
• They are rarely subject to MFA or conditional access. Machine identities authenticate with static secrets — API keys, client secrets, private keys — that, once exfiltrated, work indefinitely with no step-up challenge.
• Their behavioral baseline is narrower but their blast radius is wider. A CI/CD credential that only ever pushes container images to one registry is highly predictable, which is good for detection, but if compromised it typically holds write access to production artifact pipelines — a supply-chain-level foothold.

Session and token-based identity

A third category deserves separate treatment: the session itself. Modern authentication increasingly relies on bearer tokens — SAML assertions, OAuth access and refresh tokens, browser session cookies protected (or not) by device-binding. Adversary-in-the-middle phishing kits and infostealers now routinely target these tokens directly, bypassing MFA entirely because the token represents a session that already completed authentication. A stolen session token is functionally equivalent to a stolen password for the lifetime of that token, and unlike a password, most organizations have no operational muscle for revoking a session mid-flight the way they would reset a password.

What ITDR actually is: scope and boundaries

ITDR is best understood as a layer that sits between identity infrastructure (directories, identity providers, PAM vaults) and security operations (SIEM, SOAR, XDR). Gartner formalized the term in 2022 to describe tools and practices purpose-built to protect identity systems themselves — detecting attacks on Active Directory, Entra ID, Okta, and similar infrastructure — and to detect misuse of identities across the environments they authenticate into. In practice, mature ITDR programs cover four overlapping capability areas:

• Identity infrastructure hardening and detection. Monitoring the directory and identity provider itself for attack techniques such as Kerberoasting, DCSync, Golden/Silver Ticket forgery, password spray against the IdP, and abuse of federation trust relationships.
• Identity threat detection across the fleet. Behavioral analytics on authentication and authorization events wherever they occur — endpoint logons, cloud console sign-ins, SaaS application access, API calls made under a service identity.
• Privileged access monitoring. Real-time oversight of PAM-vaulted credential checkouts, session recording, and just-in-time elevation requests, correlated with what the privileged session actually did.
• Identity posture and governance. Continuous assessment of standing privilege, entitlement creep, dormant accounts, shadow admin paths, and misconfigurations that create exploitable identity attack paths — the preventive half of the equation that reduces what detection has to catch.

It is worth being precise about what ITDR is not. It is not identity governance and administration (IGA) — the system of record for who should have access to what, driven by joiner-mover-leaver workflows and access certifications. It is not PAM itself, though it consumes PAM telemetry heavily. And it is not a replacement for XDR or SIEM; rather, identity signal is one of the highest-value inputs those platforms can ingest, and ITDR platforms are increasingly expected to feed detections directly into a unified XDR triage pipeline rather than operate as an isolated console analysts have to context-switch into.

Detection mechanics: how identity threats actually get caught

Signal sources that matter

Effective ITDR detection depends on assembling telemetry that individually looks benign but collectively reveals intent. The core sources are directory and IdP audit logs (Windows Security Event Log 4624/4625/4768/4769/4776, Entra ID sign-in and audit logs, Okta System Log), cloud provider identity logs (AWS CloudTrail, Azure Activity Log, GCP Cloud Audit Logs), SaaS application audit trails, VPN and remote access logs, endpoint EDR process and logon telemetry, and PAM vault checkout/checkin records. The single biggest practical failure mode in ITDR programs is incomplete log coverage — teams that ingest Active Directory logs but not Entra ID conditional access logs, or that monitor human SSO logins but have zero visibility into the thousands of daily API key authentications hitting internal services.

Detection techniques

Rule-based detection still matters for known attack techniques with unambiguous signatures — Kerberoasting produces a distinctive spike in RC4-encrypted TGS requests for service accounts; DCSync requires replication permissions rarely granted outside domain controllers; impossible travel is a straightforward geovelocity calculation. These deterministic rules, mapped to MITRE ATT&CK identity-related techniques (T1003 credential dumping, T1558 steal-or-forge Kerberos tickets, T1550 use of alternate authentication material, T1621 MFA request generation), should form the always-on baseline of any ITDR deployment because they are cheap to run and produce low false-positive, high-confidence alerts.

But rules alone miss the majority of real-world identity compromise, because the attacker is using legitimate credentials to do legitimate-looking things. This is where behavioral analytics — commonly branded UEBA (User and Entity Behavior Analytics) — earns its keep. A behavioral model builds a per-identity baseline across dimensions such as typical login times, source geographies and ASNs, device fingerprints, applications and resources accessed, typical session duration, peer-group comparison (does this account behave like others with the same job function), and sequence-of-actions patterns. Deviation is scored, not treated as a binary alert, and multiple weak deviations are combined into a single risk score that crosses an actionable threshold only when several independent signals align — a login from a new country, using a new device, followed immediately by an attempt to enumerate other users' permissions, is a very different risk than any one of those signals alone.

A mature program layers a third technique on top: identity attack-path graphing. This models the directory, cloud IAM, and application entitlements as a graph and continuously computes which identities have a path — direct or through a chain of role assumptions, group memberships, and trust relationships — to a critical asset (domain admin, a production database, a code-signing key). This is fundamentally a posture technique, but it becomes a detection multiplier: an anomaly on an identity that sits on a short attack path to a crown-jewel asset should be triaged and escalated completely differently than the identical anomaly on an identity with no meaningful path to anything sensitive.

How ITDR relates to SIEM, XDR, and UEBA

Organizations frequently ask whether ITDR is a new tool category to buy or a capability that should live inside an existing SIEM or XDR platform. The honest answer is that it depends on architecture maturity, but the direction of the market is convergence. Standalone ITDR point products emerged because SIEM correlation rules and EDR-centric XDR platforms were built around network and endpoint telemetry models that do not naturally represent identity concepts — entitlements, role hierarchies, federation trust, session lineage. A purpose-built ITDR engine models identity as a first-class entity with its own graph of relationships, not just another log source.

That said, running identity detection in a silo separate from endpoint, network, and cloud detection creates exactly the kind of coverage gap attackers exploit — an identity anomaly and a subsequent endpoint or cloud action are often two halves of the same kill chain, and a SOC analyst pivoting between three separate consoles to reconstruct that chain loses the minutes that matter during an active intrusion. The architecture that holds up under real incident pressure treats identity signal as one first-class stream feeding a unified detection and response fabric, alongside endpoint, network, and cloud telemetry, correlated by a single reasoning layer rather than stitched together manually by a tired analyst at 2 a.m. This is the model behind Algomox's approach to agentic SOC operations, where identity, endpoint, and cloud signals are correlated automatically before an analyst ever sees the alert, and it is the design principle behind treating identity security as a peer discipline to XDR detection and response rather than a bolted-on module.

Practically, most enterprises land on a hybrid: a dedicated identity telemetry and analytics layer (purpose-built for directory/IdP/PAM signal richness) whose detections and risk scores are streamed into the broader SIEM/XDR correlation engine and SOAR playbook layer for unified triage, case management, and response orchestration. What must never happen is identity alerts landing in a queue that only the IAM team monitors during business hours, disconnected from the 24/7 SOC — that organizational gap, more than any technology gap, is why identity attacks routinely go undetected for days.

Privileged access as the highest-value target

If identity is the new perimeter, privileged identity is the new crown jewel, and PAM is the control that most directly shrinks the blast radius of a compromise. The operational shift that matters most is the move from standing privilege to just-in-time (JIT) access. Standing privilege — a domain admin account that is always domain admin, a database role that always has write access — means that compromising the credential at any moment yields full privileged capability. JIT access instead grants elevation only for the duration of an approved task, typically ranging from fifteen minutes to a few hours, after which the grant is automatically revoked and the credential reverts to a non-privileged state.

A well-implemented PAM/ITDR integration does four things in concert:

• Vaults and rotates credentials so that privileged secrets are never known to the human or process using them — the vault injects a session credential and rotates it after use, eliminating the static-secret exposure that makes credential theft profitable.
• Brokers just-in-time elevation tied to a specific ticket, task, or approval workflow, with time-boxed expiry enforced automatically rather than relying on someone remembering to de-provision.
• Records and streams privileged sessions — keystrokes, commands, screen recording where applicable — to both a compliance archive and, critically, to real-time behavioral analysis so that an anomalous command sequence inside an approved session (a legitimate admin suddenly running credential-dumping tools, or dumping an entire database instead of the single record the ticket authorized) triggers an alert or automatic session termination while it is happening, not in next week's audit review.
• Feeds elevation and session events into ITDR analytics so that privileged access requests themselves become a monitored signal — a spike in elevation requests, elevation requested outside normal working patterns for that individual, or elevation immediately following a suspicious authentication event, all raise the identity risk score even before anything happens inside the privileged session.

This is the substance behind combining identity and PAM into a single operational program rather than two disconnected tools: PAM without behavioral monitoring is a vault with an audit log nobody reads until after the incident; ITDR without PAM integration is blind to the highest-consequence access category in the environment.

Non-human identity: the governance gap nobody has closed

Service accounts, API keys, and machine credentials deserve their own operational program because they break every assumption human-identity security controls are built on. They cannot complete an MFA challenge. They frequently cannot tolerate short-lived credentials without application changes. They are created ad hoc by developers under deadline pressure and rarely tracked in a central inventory. And their owners — the human who originally created the service account — leave the company, change teams, or simply forget the credential exists, leaving it live and unmonitored indefinitely.

A workable non-human identity program has to start with discovery, because you cannot govern what you cannot see. This means scanning source code repositories, CI/CD pipeline configurations, container images, and secrets managers for hardcoded and orphaned credentials; enumerating cloud IAM roles, service principals, and Kubernetes service accounts programmatically rather than relying on a spreadsheet someone updates quarterly; and inventorying OAuth application grants across SaaS platforms, since a malicious or compromised third-party integration with broad Drive, email, or CRM scopes is functionally a backdoor that most security teams never review after initial approval.

Once inventoried, non-human identities benefit from the same posture discipline as human ones, adapted to their constraints:

• Ownership assignment. Every service account and API key should have a named human or team owner responsible for its lifecycle, with automatic escalation when the owner leaves or the account goes unused past a defined threshold.
• Credential rotation and short-lived tokens. Wherever the architecture allows it, replace static long-lived API keys with short-lived tokens issued via workload identity federation (AWS IAM Roles Anywhere, GCP Workload Identity Federation, Azure Managed Identities, SPIFFE/SPIRE for cross-platform workloads) so there is no persistent secret to steal in the first place.
• Least-privilege scoping. Service account permissions should be scoped to the specific resources and actions the workload actually needs, not the broad admin roles that get assigned because it is faster than working out the minimal permission set.
• Behavioral baselining for machine identities. A CI/CD service account that suddenly authenticates from a new geography, calls APIs it has never called before, or operates outside its normal deployment schedule is exhibiting the machine equivalent of impossible travel, and should be scored and alerted the same way.
• Dormancy detection and automatic deprovisioning. Unused credentials are pure liability; a 90-day unused threshold (adjustable per environment) for automatic flagging and eventual revocation removes a large fraction of the standing attack surface with zero impact on legitimate operations.

The agentic AI wave adds urgency here. As organizations deploy autonomous AI agents — including agentic SOC and IT operations agents like those in Norra — those agents themselves become non-human identities with their own credentials, scopes, and action permissions. An AI agent with write access to a ticketing system, a cloud console, or a remediation pipeline is a new class of privileged non-human identity, and it needs the same JIT scoping, session monitoring, and behavioral baselining as any service account, arguably with tighter guardrails given the speed at which an agent can act. This is a governance problem organizations are only beginning to formalize, and it will be one of the fastest-growing categories of identity risk over the next several years.

Response and containment: from detection to action

Detection without fast, precise response only produces a well-documented breach. Identity response has a particular urgency profile: because a compromised credential can be used to pivot across dozens of connected systems within minutes, response actions need to be automatable and executed in seconds, not routed through a multi-approval change ticket. A mature ITDR response playbook typically includes graduated actions matched to risk score:

• Step-up authentication. For moderate-risk anomalies, force an additional MFA challenge or re-authentication rather than blocking outright — this preserves user experience for false positives while stopping an attacker who does not hold the second factor.
• Session termination. For confirmed high-risk activity, kill the active session and revoke associated tokens (access token, refresh token, SAML assertion) immediately — not just the password, since password reset alone does nothing against a stolen live session.
• Adaptive access restriction. Temporarily narrow the identity's effective permissions or require conditional access (managed device only, specific network location) rather than a full lockout, when the account needs to remain partially functional for business continuity.
• Credential rotation. For service accounts and API keys, automated rotation through the secrets manager or PAM vault, with the old credential invalidated the moment the new one is issued.
• Full account disable and quarantine. Reserved for confirmed compromise, paired with forensic session capture so investigators have the state of what was accessed before the account is fully locked.
• Blast-radius containment. Using attack-path graph data to identify and pre-emptively review or restrict other identities and systems reachable from the compromised account, rather than treating the incident as a single-account event.

Orchestrating these actions manually across an IdP, a PAM vault, three SaaS admin consoles, and a cloud IAM system is where most identity incident response actually breaks down under time pressure — not because the individual action is hard, but because assembling the right sequence of API calls across disparate platforms within the first ten minutes of a live compromise is exactly the kind of high-volume, well-defined, time-critical workflow that benefits from automation. SOAR-style playbooks tied directly to identity risk scores, executing through the same layer that already correlates alert triage across the environment, compress response time from the hours a manual process takes to the seconds an automated one takes, which is frequently the difference between a contained incident and a domain-wide breach.

Metrics that prove the program works

ITDR programs are frequently funded on qualitative risk narratives and then never measured against outcomes, which makes them the first thing cut when budgets tighten. A defensible program tracks a small set of concrete metrics tied to both security outcomes and operational efficiency:

• Mean time to detect (MTTD) identity compromise — from initial credential misuse to alert generation. Industry benchmarks for undetected identity compromise still frequently exceed 200 days in organizations without dedicated ITDR; mature programs push this into hours.
• Mean time to respond/contain (MTTR) — from alert to session termination or credential revocation. Automated playbooks should bring high-confidence containment actions under five minutes.
• Standing privileged account count — the raw number of accounts with always-on privileged access, tracked as a trend, with a target of continuous reduction as JIT adoption increases.
• Percentage of non-human identities with a named owner — a direct proxy for governance maturity; below 60% typically indicates significant undiscovered shadow-credential risk.
• False positive rate on identity risk alerts — tracked per detection rule, since an undifferentiated flood of low-fidelity alerts is the single most common reason SOC teams start ignoring identity signal entirely.
• Credential age distribution for API keys and service account secrets — the proportion older than the organization's rotation policy threshold, trending down over time.
• Dormant account closure rate — how quickly accounts flagged as unused past threshold are actually deprovisioned, since detection of dormancy without enforcement accomplishes nothing.

These metrics matter because they translate identity security from an abstract risk conversation into an operational scorecard leadership can track quarter over quarter, and they double as the evidence base needed for compliance frameworks (SOC 2, ISO 27001, NIST 800-53, and sector-specific mandates) that increasingly call out privileged access review and identity monitoring as explicit control requirements.

Architecture and deployment patterns for regulated and air-gapped environments

Not every organization can send identity telemetry to a cloud-hosted analytics service, and this is where ITDR architecture diverges most sharply across industries. Financial services, government, defense, and critical infrastructure operators frequently require identity detection to run entirely within a controlled boundary — on-premises, in a sovereign cloud region, or fully air-gapped with no external connectivity at all. A platform architecture built for this reality needs three properties that many cloud-native ITDR vendors do not offer: local behavioral model training and inference without a dependency on a vendor's cloud backend, self-contained threat intelligence and detection rule updates that can be delivered via controlled, offline update mechanisms, and full data residency guarantees so that authentication logs, session recordings, and risk scores never leave the customer's environment.

This is a deliberate design point across the Algomox platform: the same behavioral analytics and correlation engine that powers cloud-connected deployments runs equally in fully isolated environments, because identity telemetry is often the most sensitive data an organization generates — it is a complete map of who can reach what. Building detection logic that depends on an always-on cloud API call for every risk score computation is a non-starter for a submarine cable operator, a defense contractor, or a national utility, and the underlying AI-native stack is built to support both deployment models from the same codebase rather than maintaining a stripped-down on-prem variant as an afterthought.

The practical architecture pattern that works across both deployment models separates three layers: a collection layer (lightweight agents or log forwarders at the IdP, directory, cloud, and PAM boundary that normalize event schemas), an analytics layer (behavioral scoring, graph-based attack-path computation, and correlation running close to the data, whether that is a cloud region or an on-prem cluster), and a response layer (playbook execution against the same identity systems, gated by the same policy engine regardless of where the analytics ran). Keeping these layers architecturally separable — rather than a monolithic SaaS-only product — is what lets an organization run identical detection logic whether the deployment target is a public cloud tenant or an air-gapped data center.

A practical 90-day rollout plan

Organizations starting from limited identity visibility should resist the temptation to buy a platform and expect immediate coverage. A phased rollout produces defensible, incremental risk reduction:

Days 1–30: Visibility and inventory

Connect log sources from the primary IdP, directory service, and top three to five business-critical SaaS applications. In parallel, run a non-human identity discovery sweep across source repositories, cloud IAM, and secrets managers. The deliverable at day 30 is not detection — it is a complete, current inventory of every human and machine identity and every credential type in scope, because every subsequent phase depends on this baseline being accurate.

Days 31–60: Baseline and deterministic detection

Turn on the deterministic, signature-based detections first (impossible travel, Kerberoasting indicators, anomalous privilege escalation, MFA bypass attempts) since these have low false-positive rates and provide immediate value while behavioral baselines accumulate the 30-plus days of normal activity data they typically need to become statistically meaningful. Simultaneously begin the PAM integration for the highest-privilege account tier — domain admins, cloud root/org-admin accounts, database superusers — converting them to vaulted, JIT-brokered access.

Days 61–90: Behavioral analytics, response automation, and governance

Activate UEBA risk scoring once baselines are populated, tune alert thresholds against the false-positive metric, and stand up the first automated response playbooks — starting with low-risk actions like step-up authentication before graduating to automated session termination once confidence in detection accuracy is established. Close the loop with governance: assign owners to every discovered non-human identity, set dormancy thresholds, and schedule the first quarterly access review informed by the attack-path graph rather than a blind checklist.

Beyond day 90, the program shifts from rollout to continuous operation: expanding log source coverage to the long tail of SaaS applications, extending JIT access to the next privilege tier, and using the accumulated behavioral data to refine peer-group models as the organization's structure changes. This phased approach also maps naturally onto a broader continuous threat exposure management program, since identity attack paths are one of the highest-value categories of exposure that CTEM validation exercises should be testing against on an ongoing basis, and it should be run in lockstep with a unified NOC/SOC operating model so that identity alerts are triaged by the same 24/7 team handling every other detection stream, not siloed off to a part-time IAM reviewer.

Common pitfalls that undermine ITDR programs

Several recurring failure patterns show up across identity security programs regardless of the specific tooling chosen. The first is treating ITDR as a technology purchase rather than an operational capability — a platform generating risk scores that nobody has staffed to triage is strictly worse than no platform at all, because it creates a false sense of coverage. The second is incomplete log source coverage, particularly around non-human identities and third-party OAuth grants, which remain the least-monitored corner of most environments despite being one of the fastest-growing risk categories. The third is alert fatigue from poorly tuned behavioral models — a UEBA system that pages an analyst for every business traveler's first login from a new airport Wi-Fi network will train the team to ignore identity alerts within weeks. The fourth is stopping at detection without building the response automation to act on it, which leaves MTTR unacceptably high even when MTTD is excellent. And the fifth, perhaps the most consequential structurally, is organizational: keeping identity security owned entirely by the IAM/IGA team, disconnected from the SOC, so that a genuine identity attack in progress is sitting in a queue nobody with incident response authority is watching in real time.

Frequently asked questions