ITDR selection depends on cross-boundary identity coverage and session context

At a glance

What this is: This is an independent analysis of how to choose an ITDR solution, with the core finding that effective detection depends on cross-boundary identity correlation, high-fidelity sessions, and attribution for shared non-human identities.

Why it matters: It matters because IAM, NHI, and autonomous identity programmes all fail when detection cannot follow identity behaviour across systems, distinguish normal from malicious activity, or attribute actions when credentials are shared.

By the numbers:

• non-human identities (service accounts, API keys, secrets) now outnumber human identities in most organizations by 10:1 or more.

👉 Read Permiso Security's analysis of how to choose an ITDR solution

Context

ITDR, or Identity Threat Detection and Response, sits between preventive identity controls and incident response. It is designed to detect when valid credentials, shared secrets, or privileged access are being used in ways that do not match normal identity behaviour. For security teams, the key challenge is not whether identity is authenticated, but whether the resulting activity is credible across the full access path.

The selection problem is therefore an identity governance problem as much as a detection problem. If a platform cannot track a session from the IdP into cloud infrastructure and onward into SaaS, it will miss the chain that turns ordinary access into an attack path. That is why identity coverage, attribution, and context matter more than the size of a detection library.

For teams already dealing with service-account sprawl and expanding AI identity footprints, this is no longer a narrow SOC tool choice. It is part of how you govern who or what is using access, how reliably you can tell, and how quickly you can separate legitimate use from compromise.

Key questions

Q: How should security teams evaluate ITDR coverage across cloud and SaaS environments?

A: Test whether the platform correlates identity behaviour across your IdP, cloud infrastructure, SaaS applications, and on-premise systems as one session. If it only detects suspicious events inside a single product, it will miss the chain that turns valid access into lateral movement. The best evaluation is a walkthrough of one user journey end to end.

Q: Why do shared service accounts make ITDR harder to trust?

A: Shared service accounts remove the easy link between an action and a person, so attribution must come from behavioural context instead of login names. Without that, investigators cannot tell whether the same credentials were used by a developer, pipeline, or attacker. In environments with heavy NHI use, that attribution gap becomes a governance gap.

Q: What breaks when ITDR relies on atomic alerts instead of sessions?

A: Atomic alerts fragment the attack into unrelated events, which makes benign noise and real compromise look similar. Session-based detection reconstructs the identity journey and gives analysts the context needed to separate routine access from lateral movement or privilege abuse. Without that reconstruction, the SOC spends more time sorting alerts than proving threats.

Q: How do identity teams decide whether runtime detection or posture management should come first?

A: If your high-risk identities are already over-privileged or stale, posture work should start immediately because it reduces the attack surface. But posture alone will not catch active abuse, so mature programmes need runtime detection alongside it. The decision is not either or. It is whether you can fix misconfiguration and still detect compromise when prevention fails.

Technical breakdown

Cross-boundary identity correlation

Effective ITDR has to connect identity events across authentication boundaries, not just within a single platform. That means linking an IdP sign-in to cloud API activity, SaaS actions, and infrastructure changes as one session. Without that correlation, an attacker who moves from Okta to AWS to Slack looks like three unrelated events rather than one intrusion path. The architecture depends on identity graphing, log normalisation, and session reconstruction so the platform can understand context instead of isolated events.

Practical implication: Require proof that the platform correlates IdP, cloud, SaaS, and infrastructure activity into one investigation trail.

Session-based detection versus atomic alerts

Atomic alerts fire on single events such as a login from a new country or a permission change. Session-based detection assembles the full sequence, which is critical because a suspicious event may be normal inside a broader pattern of behaviour. This reduces false positives and gives analysts a defensible narrative for why the activity is unusual. In practice, the difference is between alert volume and usable detection fidelity, which directly affects whether the SOC can act on identity threats at scale.

Practical implication: Prioritise platforms that explain how they build sessions and measure the share of alerts that need real investigation.

Attribution for shared service accounts and API keys

Shared credentials break traditional user attribution because many people, pipelines, or services can act through the same identity. ITDR must therefore infer actor-level behaviour from patterns such as time of day, command sequences, resource choice, and cadence. This is especially relevant for non-human identities, where service accounts and API keys often carry more operational power than human logins. If attribution is weak, investigation and accountability both collapse, because the platform cannot reliably answer who did what.

Practical implication: Test whether the product can distinguish users behind shared identities before you rely on it for incident response.

Threat narrative

Attacker objective: The attacker aims to turn legitimate identity access into undetected cross-environment control and data access.

1. Entry occurs when an attacker uses stolen credentials to authenticate through normal identity boundaries, often without triggering basic access controls.
2. Escalation follows when the same identity is used for privilege escalation, lateral movement, or unusual resource access that matches legitimate workflows only at a surface level.
3. Impact lands when the attacker reaches sensitive SaaS data, cloud infrastructure, or administrative actions that were invisible to tools watching only one layer of the stack.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

ITDR is now a cross-boundary identity governance problem, not a point-product detection problem. The article's central point is that attackers do not stay inside a single control plane, so a tool that only watches one environment will systematically miss the compromise path. That makes identity correlation across IdP, cloud, and SaaS the real evaluation criterion. The practitioner conclusion is simple: if the platform cannot follow the identity, it cannot reliably detect the threat.

Identity blast radius is the right concept for selecting ITDR. The value of detection is no longer just alerting on compromise, but showing how far a valid identity can move once it is abused. Session-based correlation, shared-credential attribution, and posture awareness all reduce the blast radius of blind spots. The implication is that teams should judge ITDR by how much of the identity path it can reconstruct, not by how many detections it advertises.

Service accounts and API keys expose the limit of human-centric monitoring. Shared credentials outnumber individual logins in many environments, so an ITDR tool that assumes one person equals one identity will misattribute activity and overstate confidence. This is where NHI governance and runtime detection meet: if the platform cannot attribute actions behind a shared account, incident response and access governance both lose evidentiary value. The practitioner conclusion is to treat NHI attribution as a core ITDR requirement, not an optional extra.

Detection libraries matter less than whether the rules come from real attack behaviour. The article correctly elevates threat intelligence rooted in actual breaches over theoretical models, because identity attacks are often indistinguishable from routine administrator activity until context is applied. That also means the market is moving toward platforms that combine posture, runtime, and research-driven detections in one operating model. The practitioner conclusion is to validate rule provenance and operational fit before treating coverage claims as meaningful.

Agentic AI extends the ITDR problem into autonomous identity governance. The same detection logic that follows humans and NHIs across systems will be stressed further when AI agents begin making runtime decisions, selecting tools, and triggering actions without human approval. Existing IAM assumptions about stable, reviewable access become weaker as autonomy increases. The practitioner conclusion is that ITDR roadmaps now need to account for autonomous identity behaviour, not just service-account sprawl.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to The 2026 Infrastructure Identity Survey.
• 67% of security leaders agree identity management must fundamentally shift to address agentic AI systems.
• That governance shift should be read alongside the Ultimate Guide to NHIs , The NHI Market, which maps how identity tooling is fragmenting across human, machine, and agentic use cases.

What this signals

Identity threat response is becoming a programme-level design issue, not a tool selection exercise. Teams that still separate IAM, posture, and runtime detection will keep creating blind spots between authentication and investigation. The practical move is to align identity inventory, session visibility, and response workflows so one control plane can explain how access was used, not just who was allowed in.

The market is shifting toward platforms that can unify posture and runtime across human, machine, and agentic identities. With 70% of organisations already granting AI systems more access than they would give a human employee performing the exact same job, per The 2026 Infrastructure Identity Survey, the old divide between preventive and detective controls is no longer enough. Practitioners should expect ITDR evaluations to include NHI and agentic coverage as standard.

Identity blast radius: the amount of environment an identity can reach before a detection or governance control can explain it. As non-human and AI identities expand, the blast radius of weak attribution becomes larger than the blast radius of weak authentication, which means teams must design for investigation fidelity as much as prevention.

For practitioners

• Test cross-boundary session reconstruction Require a live demonstration that links IdP, cloud, SaaS, and infrastructure events into a single identity session. If the product cannot show one coherent path from authentication through action, it will miss lateral movement that spans multiple control planes.
• Measure alert quality against analyst workload Ask for the percentage of alerts that move from triage to investigation to confirmed threat. A platform that produces high volumes of atomic alerts without context will accelerate fatigue rather than improve identity threat response.
• Validate shared-credential attribution Use service accounts, API keys, and shared admin credentials in the evaluation. Confirm the platform can distinguish behaviour behind a shared identity using cadence, resource access, and command sequence rather than only user labels.
• Check coverage of NHI and AI identities together Map whether the platform treats service accounts, tokens, and AI identities as first-class subjects in the same detection model. This matters because the fastest-growing attack paths now cross human, machine, and agentic access patterns.

Key takeaways

• ITDR fails when it watches identities in isolation rather than following them across authentication boundaries and cloud services.
• Shared service accounts and API keys make attribution a governance requirement, not just a detection feature.
• Teams should evaluate ITDR by session fidelity, attribution quality, and coverage of NHI and AI identities, not by raw alert volume.

Key terms

• Identity Threat Detection and Response: Identity Threat Detection and Response is the practice of identifying malicious or unusual use of valid identities after access has been granted. It extends beyond authentication to behavioural monitoring, session reconstruction, and response actions that expose misuse across cloud, SaaS, and infrastructure.
• Session-Based Detection: Session-based detection groups related events into one identity journey so analysts can judge behaviour in context. Instead of firing on each suspicious action separately, it reconstructs the sequence across systems, which improves signal quality and reduces false positives in identity-heavy environments.
• Shared Credential Attribution: Shared credential attribution is the ability to infer who, or what, used a common identity such as a service account, API key, or token. It relies on behavioural patterns and operational context because the credential itself no longer identifies a single actor.
• Identity Blast Radius: Identity blast radius is the amount of systems, data, and actions an identity can reach before it is detected or contained. In practice, it is shaped by privilege scope, session visibility, and how well investigators can reconstruct identity behaviour after abuse begins.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or programme maturity, it is worth exploring.

This post draws on content published by Permiso Security: How to Choose the Best ITDR Solution for Your Organization. Read the original.