Identity threats are outpacing EDR and NDR in the SOC

At a glance

What this is: This on-demand webinar argues that identity threats are being missed by EDR and NDR because SOC programmes still rely too heavily on endpoint and network signals.

Why it matters: For IAM, IGA, PAM, and SOC teams, the practical issue is that identity abuse often happens without an obvious endpoint or network indicator, so detection and response must be built around identity context.

Context

Identity is now the control plane where access is granted, abused, and revoked, so a SOC that depends mainly on endpoint and network telemetry will miss part of the attack surface. That is the governance gap this session addresses: detection logic built for hosts and packets does not fully see identity-driven abuse.

This on-demand webinar frames Identity Threat Detection and Response as the missing layer between traditional security monitoring and identity governance. The message is straightforward: if identity is where attackers move, then identity must also be where the SOC detects and responds.

Key questions

Q: What breaks when SOC teams rely on EDR and NDR for identity threats?

A: They miss abuse that happens through legitimate identities, because endpoint and network telemetry can look normal while access is being misused. Identity threats often show up in authentication context, privilege use, and session behaviour, so the detection model has to include identity signals. Without that layer, the SOC sees activity but not the control-plane misuse behind it.

Q: Why do identity-based attacks create blind spots in the SOC?

A: Because many identity attacks do not depend on malware or unusual traffic. Attackers can use valid accounts, tokens, or privileged sessions, which means the event may appear ordinary unless the SOC is watching for behavioural deviations in identity data. That is why identity threat detection must sit alongside, not behind, endpoint and network monitoring.

Q: What are the signs that identity detection is too weak?

A: Common warning signs include alerts that arrive only after access has already expanded, too many false positives from broad telemetry, and blind spots around service accounts or privileged sessions. If your tooling sees activity but cannot explain whether the identity is behaving normally, detection is too shallow.

Q: How should teams respond when identity abuse is visible but EDR and NDR stay quiet?

A: Treat the identity event as a primary incident signal, not a secondary anomaly. Investigate the account or session, review recent privilege use, invalidate exposed credentials if needed, and determine whether the access path should be suspended before further movement occurs. The response should be driven by identity context, not by waiting for an endpoint alert.

Background and context

Why EDR and NDR miss identity threats

EDR is built to observe activity on endpoints, while NDR watches traffic patterns across the network. Both are useful, but neither is designed to understand whether a legitimate session, token, or credential is being abused in a way that looks normal at the host or network layer. Identity threats often occur without malware, noisy traffic, or obvious process anomalies, which means the attack signal sits in access behaviour, authentication context, and privilege use rather than in device telemetry alone. That is why identity has become a distinct detection domain inside the SOC.

Practical implication: SOC teams need identity telemetry alongside endpoint and network data, not as a later enrichment step.

What ITDR adds to SOC detection logic

Identity Threat Detection and Response focuses on suspicious identity behaviour such as abnormal authentication patterns, privilege misuse, and access that does not fit expected user or service-account behaviour. In practice, ITDR extends SOC logic into identity context so analysts can connect who or what accessed a resource, when the access happened, and whether the pattern is consistent with normal governance. The value is not replacing EDR or NDR, but filling the blind spot where access abuse does not produce a clear device or network alert. That shifts identity from a supporting signal to a primary detection surface.

Practical implication: SOCs should define identity-specific detection rules and response playbooks instead of waiting for endpoint alerts to surface access abuse.

Embedding identity context into SOC workflows

An ITDR programme only works when identity signals are operationalised inside SOC workflows, not held in a separate identity team queue. That means correlating authentication events, privileged actions, and access anomalies with incident triage so analysts can see whether an identity issue is part of a broader intrusion path. It also means the SOC must decide which identity events are high-confidence indicators, which need investigation, and which should trigger containment before access spreads further. Without that operational bridge, identity detection remains theoretical while the attacker moves through approved accounts and sessions.

Practical implication: build triage and escalation paths that let identity events trigger containment decisions inside the SOC.

NHI Mgmt Group analysis

Identity telemetry is becoming a first-class SOC input, not a niche IAM feed. The traditional split between endpoint detection, network detection, and identity governance no longer matches how access is abused in cloud-heavy environments. When the attack path is a valid account, token, or privileged session, the SOC needs identity context at the same priority as host and network data. The practitioner conclusion is that identity detection cannot remain downstream of conventional telemetry.

ITDR is the operational layer that turns identity governance into detection. Governance tells you who should have access, but ITDR helps surface when actual behaviour diverges from that expectation. That distinction matters because many identity threats do not begin with compromised infrastructure, they begin with legitimate access used in the wrong way. The practitioner conclusion is that governance and detection must be designed together.

Legacy SOC coverage creates an identity blind spot when attackers stay within approved channels. If access abuse looks like normal sign-in, normal API usage, or normal privilege execution, EDR and NDR can register activity without understanding intent. That is why identity needs its own detection model rather than being treated as a second-order alert source. The practitioner conclusion is that SOC coverage has to be rebuilt around identity behaviour, not just device behaviour.

Identity detection is now part of the SOC’s control architecture, not just an investigation aid. The closer identity monitoring gets to triage and containment, the more it changes how organisations respond to abuse, privilege misuse, and account takeover. This is the point where ITDR stops being a concept and becomes an operating requirement. The practitioner conclusion is to treat identity as a control surface, not an after-the-fact forensic feed.

What this signals

Identity visibility is becoming a SOC design requirement. Teams that keep identity events outside their primary detection and response workflow will continue to overestimate coverage, because access abuse can remain invisible to endpoint and network telemetry. The operational shift is to treat identity as part of the incident path, not a separate admin concern.

ITDR closes a control gap that legacy monitoring cannot solve on its own. The practical question is no longer whether EDR and NDR matter, but whether they are sufficient when the attacker stays inside legitimate access channels. If the answer is no, identity telemetry has to move into the same triage path as other high-confidence SOC signals.

For practitioners

• Embed identity signals into SOC triage Correlate authentication, privilege use, and access anomalies with endpoint and network alerts so analysts can see identity abuse in context.
• Define identity-specific detection logic Write detections for abnormal sign-ins, privilege misuse, token abuse, and unusual service-account behaviour rather than relying only on host-based indicators.
• Create identity containment playbooks Map the response steps for suspicious account activity, including credential invalidation, session review, and privileged access suspension.
• Prioritise high-risk identity sources Start with the identity stores, federation points, and privileged accounts that can affect the widest access paths across the environment.
• Align IAM and SOC ownership Assign clear operational responsibility for identity alerts so SOC analysts know when to escalate and IAM teams know when to intervene.

Key takeaways

• Identity threats can evade endpoint and network-centric monitoring when attackers operate through valid accounts, sessions, or tokens.
• The article’s central argument is that SOCs need identity context, not just more telemetry, to spot misuse at the access layer.
• ITDR matters because it turns identity behaviour into a detection and response surface instead of leaving it as an IAM-only concern.

Key terms

• Identity Threat Detection and Response: Identity threat detection and response is the practice of finding misuse of credentials, unusual access patterns, and compromised identities across human and machine actors. For NHIs, it relies on telemetry from code, vaults, cloud services, and pipelines to detect abuse early enough to contain it.
• Identity Telemetry: Identity telemetry is the collection of signals generated by authentication, session, and access events across human and non-human identities. It becomes useful for governance when teams can baseline normal behavior and detect drift in source, privilege, or access frequency.
• Identity Control Plane: An identity control plane is the governance layer that decides who or what can access systems and under what conditions. In practice, it coordinates authentication, authorization, privilege review, and lifecycle management across human and machine identities so access policy is enforced consistently across environments.
• Identity Blind Spot: An identity blind spot is any gap where an organisation cannot fully see, inventory, or govern an identity and its access rights. Blind spots are especially dangerous for NHIs because they often live in code, pipelines, or third-party integrations outside normal review cycles.

Deepen your knowledge

NHI governance, machine identity security, and identity lifecycle management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or security operations programme, it is worth exploring.