Identity as an XDR Telemetry Source

Every major breach post-mortem from the last three years converges on the same uncomfortable fact: the attacker authenticated. They did not smash a window; they used a key — a phished token, a stale service account, a session cookie lifted from an infostealer log, an over-permissioned SaaS OAuth grant. Yet most XDR platforms still treat identity as a lookup field — a username stapled to a process event — rather than as a first-class telemetry stream with its own sensors, its own signal grammar, and its own correlation logic. This article is about closing that gap: how to architect identity as a native XDR telemetry source, wire it into endpoint, network, and cloud detections, and operate the resulting fusion at SOC scale.

Why identity telemetry changes the detection equation

Endpoint detection and response was built to answer "what did this process do?" Network detection and response was built to answer "what talked to what?" Both are necessary and both are blind to the question that actually matters in most modern intrusions: "was this the right person doing the right thing through the right path?" Identity providers (IdPs), directory services, and privileged access management (PAM) systems are the only components in the estate that can answer that question, because they are the only components that hold the ground truth of who a credential is supposed to represent, what it is authorized to touch, and what its normal behavioral envelope looks like.

Treating identity as a telemetry source means instrumenting authentication, authorization, entitlement, and session lifecycle events with the same rigor traditionally reserved for EDR process trees and NDR flow records. That means capturing not just success/failure of a login, but the full context: authentication method used, device posture at time of auth, token issuance and refresh chain, conditional access policy evaluation results, group and role membership deltas, and privileged session start/stop boundaries with command-level activity where PAM brokers support it.

The blind spot this closes

Consider a classic lateral movement chain: an adversary compromises a low-privilege workstation, harvests a cached Kerberos ticket, and uses pass-the-ticket to authenticate to a file server as a domain admin service account that has never logged in from that host before. Endpoint telemetry sees a legitimate-looking LSASS read (increasingly common with tooling and difficult to distinguish from benign diagnostics) and a normal SMB session. Network telemetry sees an SMB flow to a server that is a routine destination for many hosts. Neither is anomalous in isolation. Identity telemetry, by contrast, sees a Kerberos service ticket request (TGS-REQ) for a highly privileged principal originating from an authentication source (the workstation) that has zero authentication history for that principal, occurring outside the account's established access pattern, and immediately followed by a change in effective group membership evaluation. That is the signal an XDR correlation engine needs, and it only exists in identity telemetry.

A taxonomy of identity telemetry sources

Before building correlation logic, catalog what identity telemetry actually consists of, because the signal quality and latency vary enormously by source. Engineers who bolt on "identity" as a single generic connector routinely end up with either an unusable firehose or a dangerously incomplete picture.

• IdP authentication logs — Okta System Log, Entra ID sign-in logs, Ping, OneLogin. Carry authentication method, risk score, conditional access decision, client app, IP/ASN, device compliance flag, and session token lifetime.
• Directory service audit logs — Active Directory Security Event Log (4624/4625/4768/4769/4776), Entra ID audit logs, LDAP bind logs. Carry Kerberos ticket requests, NTLM fallback events, group membership changes, and object ACL modifications.
• PAM/vaulting session records — CyberArk, BeyondTrust, HashiCorp Vault, Delinea. Carry privileged session checkout, session recording metadata, command-level keystroke logs on brokered sessions, and vault credential rotation events.
• Cloud IAM and entitlement logs — AWS CloudTrail (AssumeRole, GetSessionToken), Azure Activity Log, GCP Cloud Audit Logs, plus CIEM (cloud infrastructure entitlement management) drift reports.
• SaaS OAuth/token telemetry — grant approvals, refresh token issuance, scope escalation, and third-party app consent events from Microsoft Graph, Google Workspace, and SaaS security posture (SSPM) tooling.
• Identity Threat Detection and Response (ITDR) engines — purpose-built anomaly detectors that already score sign-ins for impossible travel, token replay, and session hijack indicators, which XDR should ingest as pre-scored evidence rather than reprocessing raw logs.
• Endpoint-resident identity artifacts — LSASS access attempts, credential vault (DPAPI, Keychain) reads, cached ticket enumeration tool execution (Mimikatz-class), and browser session token theft indicators.

Each of these sources has a different event rate, a different schema stability profile, and a different trust level. An Entra ID sign-in log entry is a structured, well-documented event with strong schema guarantees. A PAM session recording metadata event might arrive minutes late and use vendor-specific field names that shift between product versions. Design your ingestion pipeline to normalize schema at write time into a common identity event model, not at query time — every analytic downstream depends on consistent fields being present.

Reference architecture: identity as a peer telemetry plane

The architectural mistake most organizations make is bolting identity data onto an existing SIEM/XDR pipeline as an afterthought — a connector added a year after endpoint and network pipelines were already mature. The result is an identity plane with worse retention, worse normalization, and worse correlation hooks than the other planes, which guarantees identity-driven detections lag behind the rest of the platform in both coverage and quality. Instead, design identity ingestion, normalization, and correlation as a peer plane from day one.

The common identity event model

Every identity event, regardless of source, should be normalized into a schema that captures at minimum: principal_id (a stable identifier that survives across UPN changes and aliasing), principal_type (human, service account, machine identity, workload identity), authentication_method, target_resource, source_ip_and_asn, device_id_and_posture, session_id, risk_signals (an array, since multiple risk engines may score the same event differently), privilege_context (standing privilege vs. just-in-time elevation), and outcome. The session_id field is the single most important join key in the entire model — it is what lets you stitch an initial authentication event to every subsequent action taken under that session's token, across IdP, cloud, and SaaS boundaries, which is exactly what you need to detect token replay and session hijacking after the fact.

Latency budgets by source

Not every identity signal needs to be real time, but some detections are worthless if they are not. Kerberoasting detection needs directory audit events within seconds; a quarterly access-review drift report can tolerate hours of latency. Set explicit latency SLAs per source and route high-value, low-latency sources (IdP sign-in, directory ticket requests, PAM session start/stop) through a streaming path, while entitlement and posture data (group memberships, CIEM drift, SaaS app inventories) can ride a batch path that refreshes the graph context on a shorter cycle without needing sub-second delivery.

Correlation patterns that require identity as a peer signal

The value of identity telemetry is not in the individual identity alert — ITDR products already generate those. The value is in the composite detections that become possible only when identity, endpoint, network, and cloud events are correlated on shared keys in a single graph. Below are patterns worth building explicitly rather than hoping a generic anomaly model discovers them.

Pattern 1: Impossible session continuation

An IdP records a sign-in from Country A. Within the token's lifetime, the endpoint agent on a device the user has never used records a process spawning a browser session that presents a valid access token issued from that sign-in, from a device in Country B, with no corresponding IdP sign-in event for that device. This is the signature of session token theft (cookie/token exfiltration via infostealer or adversary-in-the-middle phishing kit) rather than credential theft, and it is invisible unless you join the IdP session ID to the endpoint's observed token usage.

Pattern 2: Privilege-escalating lateral movement

Directory audit shows a TGS-REQ for a privileged service principal from a host with no authentication history for that principal (as in the earlier example). Correlate this against endpoint telemetry for credential-access technique indicators (LSASS handle requests, ticket-dumping tool signatures) on the same host in the preceding minutes, and against network telemetry for the destination the new ticket is subsequently used against. Three weak-to-moderate signals in three different planes become a high-confidence composite detection when joined on host identity and time window.

Pattern 3: Cloud privilege chaining

CloudTrail records a sequence of AssumeRole calls that hop across three roles in quick succession, each with progressively broader permissions, terminating in a role capable of modifying IAM policy or exfiltrating data from a storage bucket. Individually, none of these AssumeRole calls looks abnormal — role chaining is a completely legitimate pattern in complex cloud environments. What makes it a detection is correlating the chain's terminal identity against CIEM-derived entitlement graphs (is this the shortest path to a toxic combination the principal should never reach?) and against whether the originating credential's authentication event carried any risk signal from the IdP layer.

Pattern 4: Standing privilege drift as a leading indicator

Rather than waiting for an incident, use identity telemetry to detect entitlement drift proactively: a service account whose group membership silently grew from "read-only file share" to "domain admin equivalent" is a finding worth surfacing to continuous threat exposure management workflows well before it is ever abused, because closing that gap before exploitation is strictly cheaper than detecting the exploitation after the fact.

Baselining identity behavior without drowning in false positives

Identity behavioral baselining is harder than endpoint or network baselining because human behavior is inherently more variable than machine behavior, and because the population you are baselining (every human and non-human identity in the estate) is orders of magnitude larger than the population of monitored endpoints. A naive per-user statistical model (flag anything more than N standard deviations from historical login time/location) generates enormous noise during onboarding, travel, role changes, and routine IT operations. Structure the baselining problem in layers instead.

1. Population-level baselines for coarse anomalies: does this authentication method, ASN, or client app appear anywhere in the tenant's history? This catches genuinely novel infrastructure (new C2 IP ranges, new phishing kit fingerprints) cheaply, with low false-positive risk because the comparison set is the whole organization, not one user.
2. Peer-group baselines for role-appropriate behavior: compare a user against others with the same job function, department, and access tier rather than only against their own history, which catches account takeover faster than waiting to accumulate enough individual history and handles new hires gracefully.
3. Individual behavioral baselines for fine-grained deviation once sufficient history exists (typically 2–4 weeks): normal working hours, typical resource access sequences, typical device set, typical MFA method used.
4. Entity-relationship baselines for non-human identities: service accounts and workload identities should have extremely tight behavioral envelopes because, unlike humans, they have no legitimate reason for behavioral variance — a service account authenticating from a new source or accessing a new resource type is a much stronger signal than the equivalent event for a human.

Fuse the outputs of these layers with a weighted composite risk score rather than an OR-gate across independent thresholds. An OR-gate approach (alert if any single model exceeds its threshold) is what produces alert fatigue; a composite score that only escalates when multiple weak signals from different layers co-occur produces the high-precision alerts that actually get investigated. This is the same design principle that governs endpoint EDR analytic engines and should be treated identically for identity, not as a special case requiring bespoke tooling.

Privileged access management as a sensor network, not just a control

Organizations frequently deploy PAM purely as an access control — a vault that checks out credentials and brokers sessions — without treating the session telemetry PAM generates as a detection asset. This is a missed opportunity, because PAM sits at exactly the chokepoint where the highest-blast-radius actions occur, and brokered session recordings often include command-level or keystroke-level detail that no other telemetry source captures.

What to extract from PAM for XDR correlation

• Session checkout anomalies — credential checkout at unusual hours, checkout by an approver who does not normally request that specific credential, or checkout without an associated change ticket where change-linkage is enforced.
• In-session command telemetry — for SSH/RDP proxy-based PAM, the broker can extract executed commands or window titles; feed high-risk command patterns (disabling logging, dumping credential stores, modifying firewall rules) directly into the correlation engine as first-class events, not just into a session recording archive that a human has to watch after the fact.
• Standing privilege vs. just-in-time (JIT) elevation ratio — track what fraction of privileged access in the estate still uses standing (always-on) privilege versus JIT elevation with time-bound grants; this ratio is both a detection input (standing privilege sessions carry higher inherent risk and deserve tighter behavioral monitoring) and a governance metric worth reporting to leadership.
• Vault credential rotation failures — a credential that fails to rotate on schedule is itself a finding, since a static credential sitting past its rotation window is exactly the kind of artifact adversaries hunt for.

Route PAM telemetry into the same correlation graph as everything else using the session ID join key described earlier, so that a privileged session opened via PAM can be automatically stitched to any endpoint or network activity that occurs on the target host during that session window. This is what lets an analyst answer "was this specific database modification made through an authorized, recorded privileged session, or through an out-of-band path?" in seconds rather than by manually cross-referencing three consoles.

Cloud and SaaS identity: the expanding perimeter

Identity telemetry cannot stop at the directory and endpoint boundary; cloud IAM and SaaS OAuth grants are now a primary initial-access and persistence vector, and they generate their own distinct telemetry that must be correlated with the same rigor. Two failure modes recur across organizations we have worked with.

First, teams instrument CloudTrail or Azure Activity Log ingestion but stop at raw event collection, never building the entitlement graph context (what does each role actually grant, transitively, including resource-based policies and cross-account trust) needed to score an AssumeRole chain's severity. Without that graph, a correlation engine can detect that role chaining happened but cannot tell you whether it reached anything that matters, which means every chain looks equally alarming and analysts learn to ignore the alert type entirely.

Second, teams monitor first-party OAuth grants closely but ignore third-party app consent, which is precisely where a large share of real SaaS compromises originate: an attacker phishes a user into approving a malicious OAuth app with mail-read or file-read scope, and that grant persists as a standing backdoor that survives password resets and even MFA re-enrollment, because it is a token grant, not a credential. Any identity telemetry pipeline for a SaaS-heavy estate needs an explicit consent-and-scope-change event stream, correlated against a baseline of which third-party apps are sanctioned, with automatic flagging of any grant that includes mail, file, or directory-read scopes from an app not on the sanctioned list.

Operationalizing identity correlation in the SOC

Architecture without operational integration is shelfware. Identity-aware XDR changes SOC workflow in three concrete ways that engineers should design for explicitly rather than leaving to ad hoc analyst habit.

Triage ordering

When an identity-tagged composite alert fires, the first triage question should never be "is this alert real?" in isolation — it should be "what is the blast radius of this principal's current entitlements?" A compromised help-desk account and a compromised domain admin service account can trigger structurally identical anomaly signatures, but the response urgency differs by orders of magnitude. Pull entitlement context (ideally pre-computed from the CIEM/entitlement graph, not queried live under incident pressure) into the alert as a first-class field, and use it to drive queue prioritization automatically, not just as reference material an analyst reads after opening the ticket.

Automated containment actions scoped to identity

Because identity is the pivot point for lateral movement, containment playbooks should default to identity-scoped actions (force session revocation, step-up MFA challenge, temporary entitlement suspension) as the fastest available containment lever, often faster to execute and less disruptive than host isolation, especially for cloud and SaaS-native incidents where there is no host to isolate. Design your SOAR playbooks so that session/token revocation via the IdP is a first-tier automated response for high-confidence identity-driven detections, with host isolation and network segmentation as complementary, not substitute, actions. This is the kind of workflow that benefits from an agentic SOC approach, where an AI-driven response agent can execute the identity-scoped containment step within seconds of alert generation, ahead of human triage, for alert classes that meet a defined confidence threshold.

Feedback loop into exposure management

Every confirmed identity-driven incident should generate a structured finding back into your exposure management program: which entitlement made this possible, and should it exist at all? This closes the loop between detection and the underlying attack surface reduction work tracked in continuous threat exposure management programs, converting reactive incident response into a durable reduction in standing risk rather than a one-off cleanup.

Worked example: tracing a business email compromise through the identity plane

Walk through a concrete incident to see the architecture in action. A finance department employee receives a phishing email with a link to a fake Microsoft 365 login page hosted on a lookalike domain. The page is an adversary-in-the-middle (AiTM) proxy that relays credentials and the MFA challenge in real time, then captures the resulting session token.

1. T+0: IdP sign-in log records a successful authentication, MFA satisfied, from an IP/ASN never previously associated with this user, using a client app fingerprint that matches known AiTM proxy tooling. Population-level baseline flags the ASN as novel to the tenant; this alone is a low-confidence signal.
2. T+2 min: The stolen session token is replayed by the attacker from separate infrastructure. IdP session telemetry shows a second, geographically implausible IP using the same session ID as the T+0 sign-in — the impossible session continuation pattern from earlier. Confidence rises sharply because this pattern has essentially no benign explanation given MFA was already satisfied on the original sign-in.
3. T+5 min: Correlation engine joins this session ID to subsequent Microsoft Graph API activity: a new mail forwarding rule is created, and a third-party OAuth app with mail-read scope is granted consent. Both are classic BEC persistence techniques and both are captured purely as identity-plane telemetry (no endpoint or network signal exists for either action, since the attacker never touched the victim's device).
4. T+6 min: Composite risk score crosses the automated response threshold. SOAR playbook executes identity-scoped containment: the session is revoked at the IdP, the user is forced through step-up re-authentication, the malicious OAuth grant is revoked, and the mail forwarding rule is disabled — all before a human analyst has picked up the ticket.
5. T+15 min: Analyst reviews the auto-contained incident, confirms the classification, and files a finding: this user's mailbox permitted third-party app consent without administrative approval, which should be tightened tenant-wide. That finding routes into the exposure management backlog as a policy hardening action, closing the loop described above.

Notice that at no point did endpoint or network telemetry contribute a single event to this detection — the entire chain lived in the identity plane, from IdP sign-in through Graph API activity. An XDR platform that treats identity as a secondary enrichment source rather than a primary detection surface would have missed this incident entirely until the financial fraud downstream of the mail rule was discovered, likely days or weeks later.

Buyer guidance: evaluating identity telemetry in an XDR platform

When evaluating XDR platforms or building an internal correlation layer, use the following criteria specifically to test whether identity is architected as a peer plane or bolted on as enrichment.

• Session-ID stitching across boundaries — can the platform join an IdP sign-in's session/token identifier to subsequent activity in cloud APIs, SaaS Graph calls, and endpoint token usage? If the vendor cannot describe how session IDs propagate and get joined, identity is enrichment, not a peer signal.
• Non-human identity coverage — does the baselining model explicitly separate service accounts, workload identities, and API keys from human behavioral models, or is everything run through one generic user-behavior analytics model tuned for humans?
• PAM session ingestion depth — is only session start/stop metadata ingested, or is command/keystroke-level telemetry from brokered sessions available as structured, correlatable events?
• Entitlement graph, not just event logs — can the platform answer "what is the blast radius of this principal" using a precomputed entitlement graph, or does it only show raw historical events with no notion of current effective privilege?
• Native identity-scoped response actions — can the platform natively execute session revocation, step-up MFA, and entitlement suspension as automated playbook actions, or does every identity containment step require a manual hop into the IdP admin console?
• Latency transparency — does the vendor publish or disclose per-source ingestion latency, so you can validate that high-value sources (directory audit, IdP sign-in) meet the seconds-level SLA that lateral movement detection requires?

Platforms built around an AI-native stack have an advantage here specifically because the entitlement graph and behavioral baselining problems described above are graph-reasoning and anomaly-modeling problems well suited to machine learning pipelines that continuously retrain against fresh telemetry, rather than static correlation rules that require manual tuning as the entitlement landscape shifts. This matters most for the peer-group and individual baseline layers, which degrade quickly if not retrained on a rolling basis as roles, teams, and access patterns change.

Deployment considerations across environments

Identity telemetry architecture must adapt to deployment model, and this is a place where generic XDR guidance often breaks down for regulated or air-gapped environments.

Cloud and hybrid

Most identity telemetry sources (Entra ID, Okta, AWS CloudTrail) are natively cloud services with well-documented streaming export APIs; the main engineering effort is normalization and correlation graph construction, not collection plumbing.

On-premises and sovereign/air-gapped

Air-gapped environments typically run on-premises Active Directory as the sole identity authority, with no cloud IdP to draw risk-scored sign-in telemetry from. This means the identity plane must derive its own risk scoring purely from directory audit logs (4624/4625/4768/4769 event codes) and PAM session data, without the benefit of vendor-maintained ASN reputation feeds or cross-tenant anomaly models that cloud IdPs provide. Budget engineering time specifically for building and maintaining local behavioral baselines and threat intelligence feeds that would otherwise be inherited for free from a cloud IdP's global visibility. This is a real capability gap that sovereign deployments must plan for explicitly, not an incidental detail — solutions like ITMox and CyberMox that support air-gapped operation need identity correlation logic that does not assume cloud IdP telemetry is available.

Multi-tenant MSP and MSSP contexts

Service providers monitoring multiple customer identity estates must keep peer-group and population baselines scoped per tenant, never pooled across customers, both for data isolation reasons and because cross-tenant pooling would corrupt the baseline (what is normal for one customer's user population is not normal for another's). Ensure your data model carries a tenant-scoping key through every layer of the identity pipeline, from raw ingestion through the correlation graph.

Governance metrics engineering teams should own

Beyond detection, identity telemetry is a rich source of governance metrics that SOC and identity teams should jointly own and report, because they quantify the standing risk that detection has to work against. These are not soft compliance metrics — they are leading indicators of how much detection burden the identity plane is carrying.

Publish these alongside traditional SOC KPIs in the same operating review, because identity governance debt is operational risk that detection engineering has to compensate for. A SOC that halves its false-positive rate on identity alerts but never reduces standing privilege ratio is treating symptoms, not the underlying exposure — the two workstreams, handled respectively by identity and privileged access management and detection engineering, need to be run as a single program with shared metrics, not two teams that only talk during postmortems.

Where AI-driven triage earns its keep

Identity correlation produces exactly the kind of multi-signal, cross-plane evidence that benefits most from AI-assisted alert triage, because the reasoning required — is this entitlement chain unusual given this principal's role, does this session ID's cross-plane activity pattern match known account-takeover sequences, how does this compare to the last ninety days of this peer group's behavior — is exactly the kind of contextual synthesis that rule-based correlation logic handles poorly at scale but that a properly grounded AI triage layer, such as the approach described in AI-driven XDR alert triage, is built to do: pull the entitlement graph, the peer-group baseline, the session-ID cross-plane trace, and the relevant threat intelligence into a single coherent narrative an analyst can act on in under a minute instead of twenty. Products like Norra extend this further by allowing an AI workforce agent to execute the identity-scoped containment steps automatically once triage confidence crosses the defined threshold, closing the loop from detection to containment without waiting on human bandwidth during off-hours or high-volume periods. None of this replaces human judgment on ambiguous or high-stakes cases — it compresses the mechanical evidence-gathering step so analysts spend their time on the judgment calls that actually require it.

Frequently asked questions