Notifications
Clear all
Topic starter
24/06/2026 7:44 pm
TL;DR: XDR is strongest at detecting active threats, but identity attack surface management adds the missing posture context needed to separate noisy alerts from real risk, according to Hydden. The governance issue is not visibility alone, but whether SOC teams can see standing privilege, toxic combinations, and blast radius before an alert becomes an incident.
NHIMG editorial — based on content published by Hydden: Identity attack surface management fills XDR identity blind spots
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
Questions worth separating out
Q: How should security teams combine XDR with identity attack surface management?
A: Security teams should use XDR for live threat detection and IASM for identity posture context.
Q: Why do service accounts create more triage risk than user accounts in XDR?
A: Service accounts often have standing access, broader reach, and weaker human oversight than user accounts.
Q: What should teams measure to know if identity context is improving SOC decisions?
A: Teams should measure how often identity-enriched alerts change severity, reduce false positives, or shorten time to containment.
Practitioner guidance
- Enrich XDR alerts with identity posture data Feed ownership, privilege depth, rotation state, and asset reach into SOC workflows so analysts see whether an alert involves a low-impact account or a high-risk identity with production access.
- Build blast-radius scoring into triage rules Assign severity based on what an identity can reach, modify, or exfiltrate, and use that score to route alerts before manual investigation begins.
- Separate service accounts from user-like accounts in detection logic Tag non-human identities explicitly so logon anomalies, location changes, and usage patterns are interpreted against the account’s intended operating model.
What's in the full article
Hydden's full blog post covers the operational detail this post intentionally leaves for the source:
- How the IASM-to-XDR enrichment flow is structured for SOC use cases
- The specific identity attributes the vendor says matter most for alert prioritisation
- Examples of anomalous identity patterns and how they change triage priority
- How identity context is used to reduce false positives in practice
👉 Read Hydden's analysis of how IASM changes XDR identity triage →
XDR identity blind spots: what IASM changes for SOC teams?
Explore further
25/06/2026 5:09 am
Identity attack surface management is the structural layer XDR needs, not another signal source. XDR is built to catch active threat behaviour, while IASM is built to expose the preconditions that make identity compromise valuable in the first place. The point is not volume, it is decision quality. When SOC teams can see privilege, ownership, and reach, they stop treating every identity alert as an isolated event and start recognising which identities deserve immediate containment.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
A question worth separating out:
Q: Who should own identity context for incident response and SOC operations?
A: Ownership should be shared across SOC, IAM, and platform teams, with clear accountability for identity inventory, privilege classification, and response routing. When no one owns identity context, XDR remains event-driven while the organisation stays blind to the access conditions behind the event.
👉 Read our full editorial: Identity attack surface management fills XDR identity blind spots
