Why do XDR platforms still miss some identity attacks?

XDR often sees the event but not the identity context. It can correlate endpoint, network, and cloud signals, yet still miss whether a login, token use, or access request is unusual for that identity. Without entitlements, lifecycle state, and behavioural history, XDR may classify identity abuse as routine activity.

Why This Matters for Security Teams

XDR is strong at stitching together endpoint, network, and cloud telemetry, but identity attacks often succeed in the gap between signal and context. A token replay, service account login, or API key use can look routine unless the platform knows the identity’s normal purpose, entitlements, lifecycle state, and peer group. NHI Management Group’s Ultimate Guide to NHIs shows why this matters: 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.

That gap is especially visible when attackers abuse long-lived secrets or blend into automated workflows. Public reporting from Anthropic — first AI-orchestrated cyber espionage campaign report and threat guidance from CISA cyber threat advisories both reinforce the same operational reality: identity abuse now blends into normal machine activity faster than perimeter-style detection can classify it. In practice, many security teams encounter this only after a compromised credential has already been used for lateral movement, rather than through intentional identity monitoring.

How It Works in Practice

XDR platforms usually detect identity attacks best when they can enrich raw events with identity context from IAM, PAM, directory services, and cloud control planes. The missing piece is not more telemetry alone, but whether the platform can answer four questions at decision time: Is this identity expected to do this action? Is the credential still valid for this task? Does the access match the identity’s lifecycle and entitlements? Does the behaviour fit the baseline for this workload or user?

For service accounts, API keys, and agent identities, that means pairing XDR with NHI inventory, secret rotation, and workload identity controls. The operational model described in NHI Management Group’s Ultimate Guide to NHIs — Key Challenges and Risks and 52 NHI Breaches Analysis points to a common pattern: detection improves when identity telemetry is mapped to actual privilege and purpose, not just to login events. Current best practice usually includes:

• Binding alerts to identity metadata such as owner, workload, application, and environment.
• Tracking secret age, rotation status, and last-used time so stale credentials are treated as higher risk.
• Correlating unusual token use with privilege escalation, new geo-location, or abnormal tool chaining.
• Using policy-driven allow/deny rules at request time rather than relying only on static detections after the fact.

OWASP, MITRE ATLAS, and CISA all point toward the same defensive direction: identity-aware analytics works best when paired with tightly governed credentials and runtime policy evaluation, not when it is left to infer intent from logs alone. These controls tend to break down when organisations have fragmented identity inventories and no reliable way to connect a credential to a specific workload or owner.

Common Variations and Edge Cases

Tighter identity control often increases operational overhead, requiring organisations to balance detection fidelity against workflow friction. That tradeoff is most visible in CI/CD pipelines, ephemeral compute, and autonomous agents, where credentials may be short-lived, rotated frequently, or issued dynamically by orchestration systems. Guidance is still evolving here, but current practice suggests that static allowlists and fixed user-like baselines do not map cleanly to machine identities that change shape by the hour.

One edge case is shared service accounts. XDR may see one account acting across many systems, but that does not tell analysts whether the behaviour is normal, delegated, or compromised. Another is agentic AI workloads, where the identity may be a workload token rather than a human-style principal. In those environments, the better question is whether the action was authorised for that specific task, not whether the login looked familiar. The Ultimate Guide to NHIs — What are Non-Human Identities is useful for distinguishing these machine identities from human accounts, while MITRE ATLAS adversarial AI threat matrix helps frame how adversaries exploit automated workflows and AI-enabled systems. The practical limitation is that XDR still struggles where identity data is stale, ownership is unclear, or access is granted through indirect tooling such as orchestration layers and CI/CD secrets.

Related resources from NHI Mgmt Group

• Why do DNS attacks still matter when organisations already use modern IAM?
• Why do email impersonation attacks still work in Zero Trust programmes?
• How should mobility platforms reduce fake identity abuse without slowing legitimate users?
• What breaks when identity verification is too shallow in NFT platforms?