ITDR vs UEBA: Identity Context vs Behavioural Baselines

ITDR and UEBA both promise to catch attackers who log in with valid accounts, but they reach that goal from opposite directions and fail in different ways. Identity threat detection and response (ITDR) starts from the identity infrastructure: directories, identity providers, federation, tokens and the privileged objects inside them, and it is built to contain a compromised identity quickly. User and entity behaviour analytics (UEBA) starts from activity: it learns what normal looks like for each user, host, application and service account and scores deviations. This guide compares the two threat models, how each is built, where each breaks, how they cover non-human identities, and how to decide which to lead with. It is for SOC managers, identity leads and architects splitting budget and ownership.

Key takeaways

• ITDR is identity-centred, UEBA is behaviour-centred. ITDR knows what an identity is and watches attacks on it; UEBA knows how an entity usually behaves and flags change.
• Their best-fit threats differ. ITDR is strongest against credential compromise and attacks on identity infrastructure; UEBA is strongest against misuse of legitimate access, including insiders, where nothing about the identity itself changes.
• Response is the sharpest difference. ITDR products ship containment actions such as disabling accounts and revoking sessions; most UEBA output is a score and an investigation lead that needs a SOAR playbook or an analyst to act.
• Machine identities break naive baselines. Bursty deployment pipelines and autoscaling workloads look anomalous to user-style models; both approaches need workload-aware baselines and an owner per service account.
• Most estates need both, sharing context. Posture and privilege data from ITDR should weight UEBA scores, and UEBA anomalies on tier zero identities should trigger ITDR containment.

The short answer

Choose ITDR first when your main risk is someone stealing or forging an identity: password spraying, MFA fatigue, help desk social engineering, token theft, Kerberoasting, new federation trusts or credentials added to service principals. ITDR watches the identity plane and acts on it. Choose UEBA first when your main risk is someone with legitimate access doing something they should not: a support agent browsing records outside their tickets, an engineer bulk downloading a repository before leaving, or a service account calling APIs it never used before. UEBA watches the activity plane and ranks deviations for investigation.

Products blur the line, so ask which problem a tool solves well, not which label it carries. The live ITDR Guide and UEBA Guide cover each discipline on its own; this page concentrates on the boundary and the decision.

ITDR and UEBA side by side

Threat models: credential compromise versus legitimate access misuse

What ITDR is designed to stop

The ITDR threat model assumes an outsider is trying to become an insider by acquiring an identity. The attack chain runs through the identity plane: obtaining credentials (Password Spraying, T1110.003; Multi-Factor Authentication Request Generation, T1621; Kerberoasting, T1558.003), escalating within the directory (DCSync, T1003.006), and persisting through identity objects (Additional Cloud Credentials, T1098.001). Each step leaves evidence in identity infrastructure that a technique-aware sensor can recognise without a long baseline: a burst of RC4 service tickets, replication requests from a host that is not a domain controller, a new secret on an application registration. Microsoft groups Defender for Identity detections by attack stage, up to domain dominance such as DCShadow and Golden Ticket activity.

What UEBA is designed to stop

The UEBA threat model assumes the identity may be completely legitimate. A bribed support agent, a disgruntled administrator or an attacker who already holds a valid session all present correct credentials and use permitted actions. The only signal is that the pattern of activity changes: more records, different resources, unusual hours, a new API family. The Coinbase Insider Breach 2025 shows the shape: support staff used their own accounts and permissions to copy customer records over time, so each lookup looked like routine work, and although monitoring had flagged access without business need in the preceding months, the full picture emerged with an extortion email on 11 May 2025. UEBA catches this through peer comparison and access unrelated to assigned work. MITRE D3FEND catalogues this family as User Behavior Analysis (D3-UBA), with Job Function Access Pattern Analysis (D3-JFAPA) and Resource Access Pattern Analysis (D3-RAPA) among its children.

Where the threat models meet

Valid Accounts (T1078) sits in both. Once an attacker has a working session, the remaining evidence is behavioural: what the session does next. Conversely, UEBA rarely models Kerberos ticket encryption types or federation trust changes, so it misses the infrastructure attacks ITDR is built around. The joint living off the land guidance from CISA, NSA, FBI and international partners addresses exactly this class of activity, where attackers rely on built-in tools and valid accounts.

How each is built

ITDR architecture in words

An ITDR deployment usually has three layers. First, collection close to the identity infrastructure: sensors on domain controllers and identity servers that parse authentication traffic and Windows events locally, plus API connectors to cloud identity providers. Microsoft describes Defender for Identity this way, with sensors on the identity infrastructure and API connectors that integrate external identity systems, using Okta as its example. Second, an identity graph that knows privilege tiers, group nesting, lateral movement paths and which accounts are sensitive, which is where posture findings come from. Third, a response layer with write access to the directory and IdP. Defender for Identity's documented remediation actions include Disable, Enable, Revoke session, Mark as compromised and Force password change, run through the sensor's local system account on a domain controller for Active Directory and through a Microsoft-managed enterprise application for Entra ID. Okta Identity Threat Protection describes the same pattern from the IdP side: continuous evaluation of users and sessions, entity risk from first-party and shared signals, and entity risk policies that can terminate sessions, prompt for MFA or run Universal Logout across supported apps.

UEBA architecture in words

UEBA lives where logs are centralised, typically inside a SIEM or data lake. It resolves identities across sources (a UPN, an email address, an AWS role session name and a SaaS user ID for the same person), builds per-entity profiles, computes peer groups, and scores each event or window against them. Amazon GuardDuty, for example, ships UEBA-style AnomalousBehavior finding types (such as Persistence:IAMUser/AnomalousBehavior on calls such as CreateAccessKey, and DefenseEvasion:IAMUser/AnomalousBehavior on calls such as StopLogging), generated by a model that tracks the calling identity, the request location and the specific API. Microsoft Sentinel's UEBA writes enriched events to a BehaviorAnalytics table with an InvestigationPriority score from 0 to 10 combining entity rarity with a time series score, keeps a UserPeerAnalytics table with the top 20 peers calculated with TF-IDF so smaller groups carry more weight, and records machine learning detections in an Anomalies table with a score from 0 to 1. The documented outputs are investigation and hunting aids: anomalies on user pages, "Go hunt" queries and workbook integration.

Platforms named in this guide are listed alphabetically as examples of documented behaviour; the order is not a ranking and this is not a recommendation of any product.

Non-human identity coverage

Service accounts, service principals, IAM roles and API keys are the identities where the two approaches converge most, because a machine identity's behaviour should be narrow and its identity object is where persistence hides. Coverage questions to ask of either approach:

• Does it see the workload identity at all? Microsoft Entra ID Protection's workload identity risk detections cover single-tenant, multitenant and non-Microsoft SaaS applications, but managed identities are documented as out of scope. Know which machine identities fall outside every detector.
• Does it baseline per identity? Entra's Suspicious sign-ins detection for service principals learns properties such as IP address and ASN, target resource, user agent, IP country and credential type over 2 to 60 days, and notes that authorised configuration changes can trigger it. That is UEBA logic inside an ITDR-style product.
• Does it watch the identity object? New secrets or certificates on an application, admin consent to high-impact scopes and new role assignments are ITDR territory and need no baseline to be suspicious.
• Can it contain a machine identity? Entra documents Disable service principal and risk-based Conditional Access for single-tenant service principals, plus a remediation sequence: inventory credentials, add a new credential (certificates recommended), remove the compromised ones and rotate Key Vault secrets the principal can reach.

For baselining design detail per platform see the Service Account Behavioural Baselining Guide, and for agents the AI Agent Behaviour Baselining and Anomaly Detection Guide.

Failure modes of each approach

Controls each approach needs around it

• Posture checks: fix what detection would otherwise have to catch. MFA gaps, standing privilege, dormant accounts and long-lived service principal secrets shrink both alert volume and attacker options. See the ISPM vs ITDR comparison for that split.
• Automated response with guard rails: session revocation, account disable and credential rotation through ITDR or SOAR, with allow lists for break-glass and critical service accounts, and propagation to applications through standards such as the Shared Signals Framework.
• Identity context feed: owner, privilege tier, employment status and expected behaviour for every human and machine identity, maintained by IGA and NHI inventories and consumed by both tools.
• Protection of the tools themselves: an ITDR tool that can disable any account is itself a privileged identity. Monitor its action accounts and restrict who can trigger actions; Defender for Identity, for example, requires a Response (manage) permission in Defender unified RBAC. See Securing the ITDR Tool.

Decision criteria

Small organisations on one cloud IdP often get most ITDR value from the IdP's own risk detections and response policies, plus UEBA features bundled in their SIEM. Large hybrid estates with on-premises Active Directory, several clouds and thousands of NHIs usually need dedicated ITDR for the identity plane and UEBA across the data plane, joined by a shared identity inventory. For evaluation questions see the ITDR Buyer's Guide and the UEBA Buyer's Guide.

Worked scenario: one compromise, two lenses

A finance company runs hybrid Active Directory synced to a cloud IdP, a SIEM with UEBA, and CI that deploys through a service principal.

1. Day 0, credential theft: an attacker phishes a developer's password and approves MFA after a run of pushes. ITDR fires on the push burst followed by an approval (T1621) and on a sign-in from an unfamiliar ASN. UEBA also scores the new location, but without the MFA pattern its score is moderate.
2. Day 0, persistence: the attacker adds a client secret to the CI service principal (T1098.001). ITDR flags the credential addition by a user who never manages that application. UEBA has no baseline for "secret added" and stays quiet.
3. Day 1, use of the service principal: the attacker signs in as the service principal from a VPS and lists storage. The workload risk detection notices unfamiliar IP and credential type. UEBA sees the service principal call storage listing APIs it has never used and raises a high anomaly.
4. Response: the ITDR playbook revokes the developer's sessions, forces a password reset and disables the service principal. Because the principal deploys production, the action needs the platform owner's approval, which the identity tag routes automatically. The team then rotates credentials using the documented sequence and checks storage access logs for collection (T1530).
5. Lesson: ITDR caught the identity plane steps and owned containment; UEBA added the strongest signal once the attacker used the access.

If the actor were instead a contractor with legitimate CI access copying data over weeks, no identity technique would fire and only UEBA's volume and peer anomalies would show it. See the Insider Data Theft Guide.

How to implement both without duplication

1. Inventory identities and tiers first: list tier zero accounts, privileged roles, service principals, cloud roles and API keys with owners. Both tools depend on this.
2. Close telemetry gaps: ITDR sensors or connectors on domain controllers and IdPs; for UEBA, IdP sign-ins, cloud control plane, SaaS audit and data access logs with retention long enough to scope slow intrusions.
3. Turn on technique detections before behaviour: ITDR detections need little learning time and catch the commonest initial access. Run UEBA in observe mode during its learning period.
4. Tune UEBA on real investigations: label machine identities, join change and deployment calendars, and set thresholds against the alerts analysts actually confirmed.
5. Join the outputs: feed ITDR privilege and posture context into UEBA scoring, and route high UEBA anomalies on tier zero or critical NHIs into ITDR containment. Avoid two tools alerting on the same sign-in event separately.
6. Automate response in rings: start with session revocation for high-confidence detections on standard users, then privileged users with approval, then NHIs with owner approval. Test rollback (re-enable, restore credentials) in a non-production tenant first.
7. Validate continuously: run safe simulations of priority techniques and of insider-style access in a test environment and confirm each fires. See ITDR validation.

Detection and measurement

• Technique coverage: percentage of your priority identity techniques (for example T1110.003, T1621, T1558.003, T1003.006, T1098.001) with a tested ITDR detection.
• Entity coverage: percentage of human and machine identities with a UEBA baseline, and the count of identities outside every detector (for example managed identities, unconnected SaaS).
• Time to contain an identity: median minutes from a confirmed identity alert to sessions revoked and credentials reset.
• UEBA precision: share of high-priority anomalies that analysts confirm as true or useful, tracked separately for people and NHIs.
• Machine identity noise: anomalies per service account per week; a rising number usually means missing deployment context, not more attacks.
• Automated response safety: number of automated actions reverted because they hit a legitimate or critical identity.

Framework mapping

Common failure patterns

• Buying UEBA to solve identity attacks it cannot see: without domain controller and IdP audit telemetry, Kerberoasting and federation changes never reach the model.
• Treating ITDR as complete insider coverage: correct credentials used for the wrong purpose rarely trip identity technique detections, as the Coinbase case shows.
• One baseline model for people and machines: CI runners and autoscaling services drown the queue, and analysts start ignoring all service account anomalies, which is exactly where a stolen key would hide.
• No alert on unusual machine identity activity: in the Capital One Breach 2019 a firewall's cloud role listed and read many storage buckets and the bulk reads went unnoticed for months; a role behaving outside its narrow job is the textbook UEBA signal for NHIs.
• Automation that ignores blast radius: auto-disabling a shared production service account during a false positive teaches the business to demand automation be switched off.

Practitioner checklist

• Write down your top five identity threats and mark each as identity plane (ITDR) or activity plane (UEBA).
• Confirm ITDR telemetry from every domain controller, identity server and cloud IdP, and list identities no detector covers.
• Confirm UEBA receives sign-in, cloud control plane, SaaS and data access logs with identity resolution across them.
• Label every service account and workload identity with owner, tier and expected behaviour, and baseline them separately from people.
• Join deployment and change calendars to UEBA to suppress expected bursts.
• Pre-approve containment playbooks for session revocation and account disable, with approval gates for tier zero and critical NHIs.
• Feed posture and privilege context into UEBA scoring and route tier zero anomalies to ITDR containment.
• Test priority techniques and an insider-style scenario quarterly and record which tool fired.

Standards and references

• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0
• MITRE D3FEND: User Behavior Analysis
• MITRE ATT&CK: Valid Accounts
• CISA: Identifying and Mitigating Living Off the Land Techniques
• AWS: GuardDuty IAM finding types
• Microsoft: Securing workload identities with ID Protection
• Okta: Identity Threat Protection overview

Related NHI Mgmt Group resources: ITDR Guide, UEBA Guide, ISPM vs ITDR, Service Account Behavioural Baselining Guide, Identity Incident Response Playbook.