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 now a primary SOC blind spot and that ITDR is needed to close gaps left by EDR and NDR.

Why it matters: It matters because IAM, NHI, and SOC teams increasingly need shared detection and response patterns for identities that behave like accounts, secrets, and access paths rather than endpoints.

👉 Watch Netwrix's on-demand session on closing the SOC's identity detection gap

Context

Identity threat detection and response, or ITDR, is the practice of spotting suspicious identity behaviour and turning it into response actions before access is abused further. The problem is that endpoint and network telemetry do not reliably show credential misuse, privilege escalation, or lateral movement through identity paths, so SOC teams end up seeing the attack too late.

As cloud adoption expands, the attack surface shifts toward accounts, tokens, and access relationships, including service identities and other non-human identities. That makes identity visibility a SOC requirement, not just an IAM concern, because the same trust gaps affect human logins, privileged access, and machine access alike.

Key questions

Q: How should security teams use ITDR in cloud and hybrid environments?

A: Security teams should use ITDR to correlate identity events, privilege use, and session behaviour into one detection and response path. The goal is not more alerts but faster containment of credential abuse, token misuse, and abnormal access. In cloud and hybrid environments, ITDR works best when it prioritises privileged identities, service accounts, and access to critical systems.

Q: Why do EDR and NDR miss many identity attacks?

A: EDR and NDR focus on endpoints and traffic, so they often miss abuse that happens through valid credentials, tokens, and delegated access. Identity attacks can look normal at the device and network layers while the attacker uses legitimate access paths. That is why identity telemetry must complement, not follow behind, endpoint and network monitoring.

Q: When should organisations prioritise ITDR over broader alert expansion?

A: Organisations should prioritise ITDR when identity is the dominant access path to cloud, SaaS, or privileged systems and existing tools are not explaining suspicious access. If incidents are already involving accounts, tokens, or privilege misuse, expanding generic detection usually adds noise. ITDR is the right move when response speed depends on understanding who accessed what and whether that access was legitimate.

Q: What should a SOC do immediately when identity abuse is suspected?

A: The SOC should move directly to containment by revoking tokens, ending active sessions, forcing reauthentication, and escalating privileged access review. Identity abuse can continue without malware or network anomalies, so waiting for endpoint confirmation wastes time. The fastest way to reduce impact is to interrupt the access path itself before the attacker expands privilege or reaches sensitive systems.

Background and context

Why EDR and NDR miss identity-led attack paths

EDR and NDR were built to observe hosts and traffic, not the identity decisions that authorize access across SaaS, cloud, and directory services. An attacker can use valid credentials, abuse tokens, or move through delegated access without creating obvious endpoint malware or suspicious network signatures. That is why identity-led attacks often look normal to traditional tools until privilege use, account behaviour, or access patterns diverge from baseline. ITDR adds identity telemetry, correlation, and behavioural signals so SOC teams can see abuse where the attack actually lives.

Practical implication: SOC teams need identity-aware detection rules, not just endpoint and network rules.

ITDR program design for cloud and hybrid identity

An ITDR programme sits across identity providers, directories, cloud control planes, SaaS audit logs, and privileged access workflows. Its job is to correlate login events, token use, role changes, and access anomalies into one response path. In practice, that means defining which identity events matter most, what constitutes suspicious privilege use, and how alerts flow into the SOC without creating untriaged noise. The better programmes map identity events to business-critical assets rather than treating every authentication as equal.

Practical implication: build correlation around privileged identities, service accounts, and access to critical systems first.

Embedding identity detection into SOC operations

ITDR only works when it is operationalized inside incident response, not run as a separate dashboard. The SOC needs playbooks that translate identity anomalies into containment steps such as disabling sessions, revoking tokens, forcing reauthentication, or escalating privileged access review. This is especially important in cloud and hybrid environments where identities are dynamic and access can be short-lived. A mature SOC treats identity alerts as high-confidence paths to blast-radius reduction, not as informational identity events.

Practical implication: connect identity alerts to response playbooks that can revoke access and interrupt abuse fast.

NHI Mgmt Group analysis

Identity is no longer a supporting signal in SOC operations. When cloud services, SaaS, and machine access become primary business dependencies, the identity layer becomes the path attackers use most often to bypass perimeter assumptions. EDR and NDR still matter, but they do not explain who should have access, who actually used it, or whether that use was legitimate. The practical conclusion is that identity telemetry must be treated as a first-class SOC data source.

ITDR is a control-plane problem, not a tool category problem. The article’s core message is not that another dashboard is needed, but that identity events must be correlated into detection and response workflows that can act on access state. That means linking authentication, privilege, and session data to response actions. Practitioners should judge ITDR by whether it changes containment speed and scope, not by whether it adds more alerts.

NHI exposure and human identity abuse now sit inside the same detection problem. Service accounts, tokens, API keys, and privileged human accounts can all be used to move quietly once trust has been established. That convergence means SOC, IAM, PAM, and NHI governance can no longer operate as separate silos. The practitioner takeaway is to build shared visibility across both human and non-human identities.

Runtime identity behaviour is the named concept that matters here. Static inventory tells you what identities exist, but runtime behaviour tells you whether those identities are being used in ways that match their expected purpose. This is the point where identity security becomes operational rather than administrative. Teams should focus on observable behaviour, not just access records.

Identity-led detection changes the boundary of incident response. When access is the attack path, response has to reach into identity providers, token stores, and privileged sessions, not just hosts and packets. That forces security leaders to align SOC process ownership with IAM and PAM controls. The field should now treat identity response as part of core detection engineering.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• From our research: Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• For a deeper governance lens: Read Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for the rotation, offboarding, and review controls that underpin identity response.

What this signals

With 5.7% of organisations having full visibility into their service accounts, according to the Ultimate Guide to NHIs, most SOCs are still trying to detect identity abuse through incomplete inventory and partial logs. That creates a structural blind spot for both human and non-human identities, and it is why ITDR has become a governance issue as much as a detection issue.

Identity telemetry debt: when organisations cannot reliably see service accounts, tokens, and delegated access, they cannot reliably respond to abuse inside those identities. Teams should expect ITDR rollouts to fail where identity data is fragmented, ownership is unclear, or privileged access lives outside the SOC operating model.

For practitioners

• Map identity telemetry into SOC triage paths Prioritise logs from identity providers, cloud control planes, SaaS audit trails, and privileged access workflows so analysts can correlate authentication, session, and role changes in one view.
• Define identity-specific containment playbooks Create response steps for token revocation, session termination, forced reauthentication, and privileged access review so identity alerts lead to immediate blast-radius reduction.
• Separate high-value identity signals from noise Triage privileged accounts, service accounts, and access to critical systems before broadening detection scope, because not every login event deserves the same response depth.
• Tie ITDR output to IAM and PAM ownership Make sure identity anomalies trigger owned actions in IAM and PAM teams, not only SOC tickets, so access state can be corrected where it lives.

Key takeaways

• Identity-led attacks bypass endpoint and network assumptions because the abuse happens through legitimate access paths, not obvious malware or traffic anomalies.
• Our research shows that 91.6% of secrets remain valid five days after notification, which helps explain why identity response windows are so often too slow.
• SOCs need identity telemetry, containment playbooks, and IAM or PAM ownership if ITDR is going to reduce blast radius rather than just add alerts.

Key terms

• Identity Threat Detection and Response: Identity Threat Detection and Response is the practice of detecting suspicious behaviour in identity systems and turning it into containment actions. It focuses on authentication, privilege use, tokens, and session activity, so security teams can respond to abuse where access is actually happening rather than only at the endpoint or network layer.
• Identity telemetry: Identity telemetry is the log and event data generated by identity providers, directories, cloud control planes, and privileged access systems. It includes sign-ins, token use, role changes, and session events. In practice, it gives SOC and IAM teams the evidence needed to distinguish normal access from abuse.
• Runtime identity behaviour: Runtime identity behaviour is what an account, token, or service identity does while it is being used, not just what permissions it was given. It matters because identity abuse often appears legitimate on paper. For security teams, behaviour at runtime is the signal that access is being misused.

Deepen your knowledge

Identity Threat Detection and Response is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your SOC is trying to close the gap between endpoint telemetry and identity abuse, this is a relevant starting point.

This post draws on content published by Netwrix: Strengthen Your SOC with ITDR, closing the gaps left by EDR and NDR. Read the original.