Building an Identity Threat Detection Program

Every intrusion narrative from the last five years converges on the same sentence: the attacker authenticated. Not exploited a zero-day, not dropped a novel implant — logged in, using a credential, a token, a service principal, or a session cookie that the environment trusted. This article is a builder’s guide to standing up an identity threat detection and response (ITDR) program that treats identity as the primary control plane, with concrete architecture, detection logic, PAM integration, and governance workflows you can actually implement.

Why identity is the control plane now

Perimeter-centric security assumed that the network boundary was the chokepoint worth instrumenting. That assumption collapsed once workloads moved to SaaS and IaaS, workforces went remote, and machine-to-machine traffic overtook human traffic inside most estates. What remains as the one artifact present in every access decision — on-prem, cloud, hybrid, or air-gapped — is identity: a human user, a service account, an API key, a workload identity, an OAuth application, or a certificate-bound machine. If you can see and govern identity, you can see and govern access, regardless of where the resource physically lives.

This is why attackers have shifted so hard toward identity-based initial access and lateral movement. Credential phishing kits with real-time MFA relay (adversary-in-the-middle proxies like Evilginx-style toolkits), infostealer malware harvesting browser session tokens, business email compromise via OAuth consent grants, and SIM-swap-enabled MFA bypass are now the dominant initial access techniques tracked across incident response caseloads. None of these require a memory corruption bug. They require an identity to misuse.

The practical consequence for engineering teams is that identity telemetry — authentication logs, directory change events, token issuance and refresh events, entitlement grants, PAM check-outs, and session behavior — has to be treated with the same rigor as endpoint telemetry (EDR) and network telemetry (NDR). ITDR is the third leg of the detection stool, and for most estates today it is the leg most likely to be missing or immature. Building it deliberately, rather than bolting a few SIEM rules onto directory logs, is what separates programs that catch identity compromise in minutes from those that discover it in a ransomware note.

Building the identity inventory: human and non-human

You cannot detect anomalies in a population you have not enumerated. The first engineering task in any ITDR program is building — and continuously reconciling — an authoritative identity inventory across every identity provider (IdP), directory, cloud IAM system, PAM vault, and SaaS admin console in the estate. This sounds administrative; it is actually the hardest part of the program, because identity sprawl is worse than almost any team expects until they measure it.

Human identities

Human identity inventory covers employees, contractors, partners, and customers where applicable. The inventory needs to capture: the identity’s home directory (Active Directory, Entra ID, Okta, Ping, or a homegrown LDAP), every downstream federated application it can reach via SSO, its authentication factors (password, FIDO2 key, TOTP, push, SMS — and which of those are phishing-resistant versus not), its privilege level in each system it touches, and its lifecycle state (active, dormant, offboarded-but-not-deprovisioned). That last state is where a disproportionate share of real incidents originate: accounts belonging to departed employees or contractors that were disabled in the HR system of record but never actually removed from a dozen downstream SaaS tools with local credential stores.

Non-human identities

Non-human identity (NHI) inventory is the newer and messier discipline. It includes service accounts, API keys, OAuth applications and their granted scopes, workload identities (Kubernetes service accounts, cloud IAM roles assumed by compute), CI/CD pipeline credentials, database service accounts, IoT/OT device certificates, and RPA bot credentials. Non-human identities now outnumber human identities by a wide margin in most cloud-native estates — ratios of 10:1 or higher are common once you count every Lambda execution role, every Kubernetes service account token, and every third-party OAuth grant a user clicked “Allow” on. NHIs are attractive to attackers precisely because they are usually unmonitored, long-lived, over-privileged, and never subject to MFA or conditional access policy because they are not human.

A workable inventory schema tags every identity record with: identity type (human, service account, workload identity, OAuth app, API key, certificate), owning system, business owner (a named human accountable for it, not a mailbox), creation date, last authentication timestamp, credential type and rotation cadence, privilege tier, and network/cloud reachability scope. Reconciling this across ten or twenty source systems is a data engineering problem before it is a security problem — expect to build or buy an identity data lake that ingests directory exports, cloud IAM policy dumps, and PAM vault inventories on a scheduled basis and correlates them by principal name, email, or a stable identifier where one exists.

ITDR reference architecture

An ITDR capability is not a single product category the way EDR is; it is a composition of data sources, a correlation layer, and response automation stitched to the identity providers themselves. The reference architecture below reflects what mature programs converge on regardless of vendor stack.

The foundation layer is the identity fabric itself: the directories, PAM vault, cloud IAM systems, and identity governance and administration (IGA) platform that issue and manage credentials and entitlements. Above that sits telemetry ingestion, which must capture not just success/failure authentication events but the full context of each event — source IP, device fingerprint, user agent, geolocation, authentication method used, token type issued, and the specific resource or API scope requested. Most IdP audit logs default to a thin event schema; the first engineering task is usually turning on verbose logging (Entra ID’s sign-in logs with device details, Okta’s System Log API, AWS CloudTrail with data events, AD’s advanced audit policy for Kerberos ticket events) because default logging misses the fields detections depend on.

The correlation layer is where an identity graph gets built: nodes are identities, resources, and sessions; edges are entitlements, group memberships, and observed access events. This graph is what lets a detection engine answer questions like “has this service account ever authenticated from this ASN before,” or “does this user’s current entitlement set match what their role-based access control (RBAC) assignment says it should be.” Session stitching — tying a single authentication event through subsequent token refreshes, impersonation hops, and downstream API calls — is what turns disconnected log lines into a coherent attack narrative, and it is the single most technically demanding piece of the architecture to build correctly, because token lifetimes, refresh flows, and delegation (OAuth on-behalf-of, AD Kerberos delegation, cloud IAM AssumeRole chains) all break naive session models.

Detection and response sits on top: UEBA baselining, rule-based ITDR detections, and SOAR-driven automated containment (forced session revocation, credential rotation, account disable, conditional access policy tightening). This is the layer most vendors market under the ITDR label, but it is only as good as the fidelity of what is underneath it. A platform like Algomox CyberMox’s identity security capability is explicitly built to sit across this whole stack rather than just the top analytics layer, because identity detections that ignore PAM check-out context or entitlement drift produce too many false positives to be operationally useful.

Core detection mechanisms and the mechanics behind them

Concrete detection logic is where most ITDR write-ups go vague. Below are the mechanisms that actually catch identity compromise in production, with the underlying signal and why it works.

Impossible travel and velocity anomalies

Impossible travel compares the geolocation of consecutive authentication events for the same identity against the elapsed time between them, flagging pairs that would require physical travel faster than commercially possible. The naive version produces heavy false positives from VPN egress changes, mobile carrier IP reassignment, and corporate proxy exit nodes that rotate geolocation. A workable version needs an allow-list of known corporate egress ranges, ASN-level grouping (treat all of a known VPN provider’s exit nodes as one location), and a graduated severity model rather than binary block/allow — flag as medium severity if the ASN is known-but-new-to-this-user, high severity if the ASN and country are both unseen for that identity in the trailing 90 days.

Kerberoasting and AS-REP roasting detection

Kerberoasting exploits the fact that any authenticated domain user can request a service ticket (TGS) for any service principal name (SPN) in Active Directory, and that ticket is encrypted with the service account’s password hash, which can then be cracked offline. The detection mechanism is volumetric: a single user account requesting TGS tickets for an unusually large number of distinct SPNs in a short window, especially SPNs tied to service accounts with high privilege, is a strong Kerberoasting indicator. This requires Windows Event ID 4769 (Kerberos service ticket requested) with the ticket encryption type field enabled, because legacy encryption types (RC4) are what makes offline cracking feasible — a parallel and important control is simply eliminating RC4-eligible service accounts, which removes the attack surface rather than just detecting it. AS-REP roasting is the sibling technique against accounts with Kerberos pre-authentication disabled; the detection is simpler, since pre-auth-disabled accounts should be a known, small, and monitored set, and any AS-REQ against them from an unexpected source should alert immediately.

Golden Ticket and Silver Ticket forgery

Golden Tickets forge Kerberos TGTs using a stolen krbtgt account hash, granting attacker-controlled, arbitrarily long-lived domain admin equivalence without touching the domain controller’s authentication path again. Detection relies on inconsistencies a forged ticket introduces: TGTs with unusually long lifetimes (beyond the domain’s configured maximum), tickets presented for users that do not exist or were recently deleted, and TGS requests that arrive without a corresponding, logged AS-REQ from that DC. Because Golden Tickets bypass normal authentication, the strongest mitigating control is not detection at all but prevention: rotating the krbtgt password twice (required due to password history) on any suspected domain compromise, and tightly restricting which accounts can read domain controller memory (mitigating DCSync-style extraction that harvests the krbtgt hash in the first place).

DCSync and directory replication abuse

DCSync abuses the Directory Replication Service protocol to impersonate a domain controller and pull password hashes for any account, including krbtgt, without ever touching a real DC’s disk. The detection signal is Event ID 4662 with the specific replication-related GUIDs, generated by an account that is not one of the actual registered domain controllers. Because so few legitimate principals should ever exercise DS-Replication-Get-Changes-All rights, this is one of the highest-fidelity, lowest-false-positive detections available in the entire identity stack — any hit deserves an immediate page, not a queued ticket.

Pass-the-Hash, Pass-the-Ticket, and token theft

These lateral movement techniques replay captured NTLM hashes or Kerberos tickets to authenticate without knowing the plaintext credential. Detection depends on correlating logon type 3 (network) or logon type 9 (new credentials) events against the identity’s normal source host population, combined with EDR-side process lineage showing credential-dumping tool signatures (LSASS access patterns) preceding the anomalous logon. This is a case where identity telemetry alone is insufficient — the highest-confidence detections fuse EDR process telemetry with directory authentication logs, which is exactly the correlation an agentic SOC workflow is designed to automate rather than leaving to manual cross-referencing during an incident.

OAuth consent phishing and application abuse

Rather than stealing a password, attackers register a malicious OAuth application and phish users into granting it consent — mail read/send scopes, file access, or directory read permissions — which then persists independent of password resets or even MFA re-enrollment. Detection requires monitoring app consent grant events for scope combinations that are unusual for the tenant (mail.read plus offline_access is a classic persistence combo), newly registered applications with no corporate publisher verification, and consent grants happening in rapid succession across many users (indicating a phishing campaign in progress). Cloud IdPs increasingly expose admin consent workflows specifically to close this gap; if your tenant still allows user consent for third-party apps by default, that is a policy gap worth closing before it is a detection gap.

Session token theft and adversary-in-the-middle

Modern phishing kits proxy the entire login flow, capturing not just credentials but the resulting session cookie or token after MFA completes, then replaying it from attacker infrastructure. Because the MFA challenge was legitimately satisfied by the victim, this bypasses traditional MFA entirely. Detection depends on token binding checks (has the token’s claimed device fingerprint changed mid-session), continuous access evaluation (re-validating conditional access policy on live tokens rather than only at issuance), and behavioral session anomalies — a token used from an IP or device inconsistent with where it was issued, especially within minutes of issuance. This is precisely why phishing-resistant authentication (FIDO2/WebAuthn, which cryptographically binds the assertion to the origin) closes an entire detection gap by prevention rather than requiring you to catch the replay after the fact.

PAM as the enforcement layer, not just a vault

Privileged access management is frequently deployed as a password vault and stops there: rotate the passwords, require check-out, call it done. Mature programs use PAM as an active enforcement and detection surface, which requires a few specific capabilities beyond vaulting.

Just-in-time (JIT) privilege elevation grants standing-zero privileged access by default and elevates on request, time-boxed, with an approval workflow and automatic revocation. This shrinks the window during which a compromised privileged credential is actually privileged — if an account only holds domain admin rights for the twenty minutes of an approved change window, a credential theft outside that window yields nothing. Session recording and command brokering for privileged sessions (SSH, RDP, database consoles) gives you a forensic record and, more importantly, a real-time inspection point where anomalous command sequences (dumping a credential store, disabling logging, creating a new privileged account) can be flagged or killed mid-session rather than discovered after the fact.

Credential rotation cadence matters more for service accounts than for humans, because service account credentials are frequently embedded in configuration files, scheduled tasks, and CI/CD pipelines where nobody notices staleness. A PAM program should track rotation coverage as a hard metric: what percentage of privileged service accounts are on automated rotation versus manual, and what is the actual rotation interval achieved versus the policy target. It is common to find policy documents mandating 90-day rotation while the actual observed rotation, measured from vault logs, is closer to 400 days because a manual process silently stalled.

PAM check-out events are also a detection source in their own right: a check-out for a credential immediately followed by usage from an unexpected host, a check-out outside the approver’s expected working hours, or a check-out with no corresponding change ticket reference are all legitimate ITDR signals that should flow into the same correlation layer as directory authentication logs, not sit isolated in the PAM vendor’s own console. Our identity and PAM solution guidance treats vault telemetry as a first-class ITDR input for exactly this reason — a PAM deployment that never talks to the detection stack is only half deployed.

Governance: entitlement drift, access reviews, and least privilege at scale

Detection catches misuse of existing access; governance is what keeps the existing access defensible in the first place. The two disciplines are complementary and frequently owned by different teams, which is a coordination failure mode worth naming early: if IGA and ITDR report into separate leaders with no shared data plane, you end up detecting anomalies against an entitlement baseline nobody is actively maintaining.

Entitlement drift is the gradual divergence between an identity’s actual access and what its role or job function justifies. It accumulates through project-based temporary grants that never get revoked, role changes where old-role access is additive rather than replaced, and manual exception approvals that become permanent by default. Left unmanaged, drift produces the condition auditors call “privilege creep,” and it is the single largest contributor to blast radius when any one account is compromised, because the attacker inherits whatever access has accumulated, not just what the role nominally requires.

Access certification campaigns (periodic manager or resource-owner attestation of who has access to what) are the traditional governance control, but run quarterly or annually they are far too slow relative to how fast entitlements actually change in cloud environments. The more effective pattern is continuous, risk-triggered micro-certifications: an automatic review is generated whenever an entitlement grant crosses a risk threshold (new access to a crown-jewel system, a grant that creates a toxic combination with existing access, a dormant entitlement unused for 60+ days) rather than waiting for a calendar date. This requires the governance system to consume the same identity graph and usage telemetry the detection layer uses — another argument for a unified identity data plane rather than siloed IGA and ITDR tooling.

Separation-of-duties (SoD) and toxic combination analysis deserves specific engineering attention for non-human identities, which are usually excluded from SoD rulesets that were designed around human job functions. A CI/CD service account that can both approve a deployment and push to production, or a cloud automation role that can modify its own IAM policy, is a toxic combination regardless of whether a human or a pipeline holds it. Extending SoD analysis to NHIs is one of the highest-leverage, most commonly skipped governance tasks.

The identity graph and UEBA analytics in practice

User and entity behavior analytics is the analytics engine most vendors point to as “the ITDR product,” but its output quality is entirely downstream of the graph and baseline it operates on. A workable identity graph models three entity types — identities, resources, and sessions — connected by edges representing entitlement (identity can access resource), activity (identity did access resource, at time T, via method M), and delegation (identity A can act as identity B, covering service account impersonation, OAuth on-behalf-of, and cloud role assumption chains).

Baselining needs a per-identity behavioral profile, not a single global threshold. A finance controller who logs in from three regional offices during business hours has a legitimately different baseline than a build-automation service account that should only ever authenticate from a fixed set of CI runner IP ranges at any hour. Effective baselines track: typical source IP ranges/ASNs, typical authentication times (by day-of-week and hour), typical resource access patterns (which applications, which API scopes), typical device fingerprints, and typical peer group behavior (comparing an identity against others with the same role, to catch cases where the individual’s own history has already been slowly poisoned by an ongoing low-and-slow compromise).

Peer group analysis matters more than most programs initially budget for, because it catches exactly the pattern that pure self-baselining misses: an attacker who has held a foothold for weeks and is authenticating in a way that is now “normal” relative to the compromised account’s own recent history, but wildly abnormal relative to every other account with the same job title and access profile. Building peer groups requires HR or directory role/title data joined against the identity graph, which is one more reason identity data engineering is the unglamorous but load-bearing work underneath any ITDR analytics claim.

Risk scoring should combine multiple weak signals rather than relying on any single detection firing at high confidence, because most real identity compromise produces a scatter of medium-confidence anomalies (new ASN, slightly unusual resource access, a new device) rather than one glaring signal. A additive or Bayesian scoring model that raises an identity’s risk score across a sliding window, with automated response thresholds tied to cumulative score rather than any single rule, catches the low-and-slow cases that single-rule detection reliably misses. This scoring approach is also what makes automated response defensible: a SOAR playbook that forces step-up authentication at a moderate score and forces full session revocation plus credential rotation at a high score gives you graduated response rather than an all-or-nothing block that either under-reacts to real compromise or over-reacts to a legitimate but unusual login.

Non-human identity analytics specifics

NHI behavior analytics needs different baseline dimensions than human analytics: rather than time-of-day and geography, the meaningful signals are API call volume and pattern (a service account suddenly enumerating every object in a data store it normally reads one record at a time from), scope escalation (an OAuth app or IAM role being granted broader permissions than its historical usage justified), and credential usage from an unexpected compute context (a Lambda execution role’s credentials being used outside the AWS account boundary, which is a strong signal of exfiltrated STS tokens). Because NHIs don’t experience “impossible travel” in any meaningful sense, programs that copy human UEBA logic onto service accounts without adapting the feature set produce weak detection coverage exactly where the exposure is largest.

Response orchestration: from alert to contained

Detection without fast, correct response is a dashboard, not a security program. Identity incidents have a specific characteristic that shapes response design: the blast radius grows with time far faster than in most other incident classes, because a live session or valid token keeps working until it is explicitly revoked, independent of whether the underlying password gets changed.

The response playbook for a confirmed or high-confidence identity compromise needs to execute, in order and largely automated: force session/token revocation across every federated relying party (not just the IdP itself — a revoked IdP session does not always kill already-issued SAML assertions or OAuth refresh tokens downstream), force credential rotation (password, and any API keys or certificates tied to the identity), disable or suspend the account pending investigation, revoke any active PAM check-outs held by the identity, and pull the identity’s recent activity history (last 30–90 days of authentication and resource access events) into the case for the analyst, rather than making the analyst query five separate consoles under time pressure.

Time-to-revoke is a metric worth measuring explicitly and separately from time-to-detect, because a program can have excellent detection latency and still lose the race if revocation requires a human to manually click through four different admin consoles. Automating the revocation step end-to-end, gated by a confidence threshold that allows genuinely ambiguous cases to route to human approval first, is the single highest-return investment most ITDR programs can make in their first year, because it converts detection speed into actual containment speed.

Coordinating this response across EDR, network controls, and identity systems is exactly the cross-domain orchestration problem an AI-driven XDR and alert triage capability is meant to solve — correlating the identity alert with any concurrent endpoint or network signal so the SOC analyst gets one enriched case rather than three disconnected tickets that each look low-severity in isolation but together describe an active intrusion.

Metrics and a maturity model to run the program against

An ITDR program needs metrics that a security leader can defend to a board and an engineer can use to prioritize the next sprint. The following set covers both purposes without requiring you to boil the ocean:

• Identity inventory coverage — percentage of known identity sources (directories, cloud IAM, SaaS admin consoles) actually feeding the identity graph, versus the total count discovered through periodic discovery scans.
• Dormant/orphaned account count and age — accounts with no authentication activity in 60+ days, and specifically accounts tied to departed personnel that remain active past their offboarding date.
• Standing privileged access ratio — percentage of privileged entitlements held as standing access versus granted via JIT elevation; the trend line matters more than the absolute number.
• Credential rotation compliance — actual observed rotation interval for privileged and service account credentials, measured from vault logs, against policy target.
• Phishing-resistant MFA coverage — percentage of privileged and high-risk identities enrolled in FIDO2/WebAuthn versus weaker factors (SMS, voice, push without number matching).
• Mean time to detect (MTTD) and mean time to revoke (MTTR-revoke) for confirmed identity incidents, tracked separately as noted above.
• False positive rate per detection rule — tracked per rule, not in aggregate, so noisy rules can be tuned or retired without degrading the high-fidelity ones.
• Entitlement drift rate — rate of access grants that fail a periodic re-justification check during micro-certification reviews.

A simple four-stage maturity model helps sequence investment. Stage one is visibility: identity inventory exists across major sources, basic authentication logging is centralized, and there is no behavioral analytics yet — most organizations that have never run a dedicated ITDR initiative sit here even if they have a mature EDR/SIEM program. Stage two is detection: UEBA baselining is live for at least the highest-privilege identity population, the core high-fidelity detections (DCSync, Golden Ticket anomalies, impossible travel) are tuned and alerting, and PAM telemetry feeds the same correlation layer as directory logs. Stage three is response automation: session revocation, credential rotation, and account suspension are automated for high-confidence cases with SOAR playbooks, and MTTR-revoke is tracked and improving quarter over quarter. Stage four is continuous governance: entitlement drift and toxic combinations are caught by continuous risk-triggered review rather than calendar-based certification, non-human identities carry the same lifecycle and SoD rigor as human identities, and the identity graph feeds proactive exposure management — a natural extension into continuous threat exposure management, where identity attack paths (not just vulnerabilities) are modeled and prioritized before they are ever exploited.

Special considerations for air-gapped, sovereign, and hybrid environments

A meaningful share of regulated and government-adjacent estates cannot rely on cloud-hosted UEBA or a SaaS IdP’s built-in risk scoring, either because the environment is fully air-gapped or because data sovereignty requirements prohibit identity telemetry from leaving a jurisdiction. This does not remove the need for ITDR; it changes the architecture. Detection analytics, the identity graph, and the correlation engine all need to run entirely within the sovereign boundary, ingesting from an on-prem AD/LDAP directory, a local PAM vault, and on-prem application logs, with no dependency on a cloud vendor’s hosted risk engine.

This is a genuine architectural constraint, not a checkbox: many ITDR and UEBA products are built cloud-first and either cannot deploy fully on-prem or lose material functionality (threat intelligence enrichment, cross-tenant anomaly comparison) when run disconnected. Programs in this position need to budget for either a vendor with a true on-prem/air-gapped deployment model or a longer internal build to replicate the baselining and correlation logic locally. Algomox’s AI-native platform is built with this deployment flexibility as a first-class requirement precisely because a meaningful share of the customer base operates under exactly these constraints, and identity detection quality should not degrade just because the environment cannot phone home.

Threat intelligence feed freshness is the other practical casualty in air-gapped environments — IP reputation lists, known-malicious ASN data, and phishing kit infrastructure indicators all go stale without a live feed. The mitigation is a scheduled, manually reviewed intelligence import process (even a weekly sneakernet update) rather than assuming the detection layer can operate with zero external threat context indefinitely; pure behavioral baselining without any external enrichment still catches a large share of identity misuse, but it will miss known-bad infrastructure reuse that a live feed would have caught immediately.

A practical 90-day rollout sequence

Programs that try to build every capability described above simultaneously tend to stall. A sequenced rollout that produces working detection within the first quarter looks like this:

1. Weeks 1–2: Enumerate every identity source system (directories, IdPs, cloud IAM accounts, PAM vaults, major SaaS admin consoles) and confirm verbose audit logging is enabled on each — this alone surfaces gaps that block everything downstream.
2. Weeks 3–5: Stand up centralized log ingestion for authentication and directory change events; build the initial identity inventory reconciled across sources by email/UPN and a stable principal ID.
3. Weeks 6–8: Implement the highest-fidelity, lowest-noise detections first — DCSync/replication abuse, Golden Ticket anomalies, AS-REP roasting against known pre-auth-disabled accounts — and route them to immediate paging, since these have near-zero false positive rates and immediate response value.
4. Weeks 9–11: Layer in volumetric and behavioral detections (Kerberoasting velocity, impossible travel with ASN allow-listing, OAuth consent anomalies) routed to a scored analyst queue rather than direct paging, to avoid overwhelming the SOC before tuning is complete.
5. Weeks 12–13: Build and rehearse the automated response playbook for session revocation, credential rotation, and account suspension; run a tabletop exercise measuring MTTR-revoke against a simulated compromised-credential scenario before declaring the capability production-ready.

Running this sequence deliberately, with explicit go/no-go criteria at each stage (log coverage above a threshold before moving to detection, false positive rate below a threshold before enabling auto-response), keeps the program from either stalling in perpetual data-engineering mode or shipping noisy detections that erode analyst trust before the tuning work is done.

Frequently asked questions