Why Most ITDR Automation Strategies Either Fail Silently—or Break the Business
Most organizations still approach Identity Threat Detection and Response (ITDR) as if it were just another version of endpoint detection: Detect something suspicious, isolate it, remediate it. That logic works when something is infected, but it fails when nothing is broken, because most identity attacks do not rely on malware or exploitation. They rely on valid credentials, stolen tokens, and legitimate authentication flows.
When such an attack happens, everything may look normal from the system’s perspective. The core challenge for a security team should become determining when trusted behavior can no longer be trusted. However, it often doesn’t.
This article discusses why ITDR automation tends to either fail silently or become overly disruptive, and what steps could help ensure that organizations strike the right balance between security effectiveness and operational stability.
Failure Mode One: Silent Failure
When detection thresholds are tuned conservatively to avoid disruption, attackers operate undetected for days or weeks inside a perfectly functional identity environment. Nothing trips. Nothing stops them.
The 2022 Lapsus$ intrusion into Okta’s support infrastructure illustrated this precisely. Attackers used valid credentials belonging to a third-party support engineer to access internal tooling with superuser-level visibility across customer tenants. There was no malware, just a legitimate session doing things a legitimate session would do. The access window lasted five days before any session was terminated, and the breach only became public knowledge two months later when Lapsus$ published screenshots on Telegram.
That is the silent failure pattern. The ITDR system was not wrong. It simply lacked the decision model to recognize that trust had been abused, because the credentials were valid and the behavior looked permissible.
Failure Mode Two: Self-Inflicted Disruption
The opposite failure is equally costly and far more visible. Security teams enable aggressive policies, automate account actions, and respond quickly to risk signals, only to find themselves locking out legitimate users or breaking access to critical services. At that point, the system is technically secure but also unusable.
In environments with high-volume identity activity, overly aggressive ITDR triggers will generate false positives at scale. A developer pushing code from a new machine trips a geolocation anomaly. A support analyst working an overnight shift matches a behavioral outlier. An automated account pulling service tokens at volume looks like credential stuffing. Any of those scenarios can trigger an automated lockout that halts work and erodes trust in the security function itself.
What Both Failures Share
The failure in most environments is decision-making. Most models implicitly consider how confident a signal is and how quickly a response can be executed. What they overlook is what actually matters in real environments: what breaks if the action is wrong, and what the identity can access right now.
An alert tied to a low-impact user is not the same as one tied to an identity with access to sensitive data or critical systems. Without that context, automation operates blindly, and blind automation is either ineffective or genuinely dangerous.
Gradual Trust Reduction
The objective of ITDR is often described as stopping identity-based attacks. That framing sets an unrealistic bar. Attackers do not need persistent access. They need just enough time to move laterally, escalate privileges, or reach sensitive data.
Effective ITDR automation should work by gradual trust reduction. When risk is detected, the first move should be to challenge that trust: force reauthentication, require stronger proof of identity, or cut off active sessions. These actions interrupt attacker activity without assuming full compromise.
The real goal is to reduce attacker trust faster than they can use it.
Practical Recommendations
For security specialists looking to make sure their ITDR is properly automated, here are a few suggestions:
- Map identity blast radius before automating responses. But do not treat blast radius as a static label. Identity risk changes with privilege elevation, new group membership, token scope, session context, device trust, and recent behavioral deviations. An account that can reach domain controllers or financial systems should trigger a different response than a contractor account limited to one SaaS app, and that response should also depend on whether the access is persistent or just-in-time, newly changed, actively exercised, or part of a suspicious chain of escalation.
- Build a graduated response ladder rather than a binary policy. The difference between a reauthentication prompt and an account lockout is enormous in operational impact, and that difference should reflect different levels of certainty in the threat signal. Low-confidence signals prompt friction. High-confidence signals tied to high-impact identities justify disruption. Everything between those two points should have an explicit, documented rung, with clear criteria for escalation.
- Integrate with SIEM and SOAR infrastructure early, not as an afterthought. ITDR does not operate well in isolation. Correlating identity signals with endpoint and network telemetry is what separates high-fidelity detections from noise. Automated playbooks should be triggered by enriched, multi-signal detections, not single-source anomalies.
- Address identity debt before tuning response thresholds. Dormant accounts, shadow admins, over-privileged service accounts, and orphaned OAuth tokens are exploitable attack paths that will generate false positives and miss real attacker activity in equal measure. Tooling to surface and remediate excessive permissions, outdated accounts, and stale credentials should run continuously. Establishing least privilege and running regular access attestation are foundational steps that need to happen before tuning automated response rules.
- Use deception-based detection as a high-confidence signal layer. Honeytokens and decoy accounts in Active Directory or Entra ID produce near-zero false positive rates. Any interaction with a decoy identity is by definition suspicious, and that signal can safely trigger more aggressive automated responses than behavioral anomalies alone would warrant. It is particularly effective for catching lateral movement and privilege escalation attempts before they gain traction.
- Test playbooks against your operations, not only against simulated attacks. Response automation should be validated through exercises that simulate real-world identity attack patterns, but equally by testing what happens to legitimate operations when those playbooks trigger. If an automated lockout policy would block a critical service account during a known operational window, that needs to be discovered in a tabletop exercise, not a production incident.
- Clarify ownership between identity administrators and SOC teams. If the identity team owns provisioning and the SOC owns response but neither owns the decision model that connects them, automation defaults to whatever is easiest to configure. The boundary needs explicit ownership and a shared playbook that both teams have signed off on.
Where This Actually Breaks Down
Security teams that have invested seriously in ITDR tooling and still end up in one of these two failure modes tend to share one characteristic: they treated deployment as the finish line. What they have not built is a coherent position on how much disruption is acceptable at each level of certainty, mapped against the actual access each identity holds.
The truth is, getting ITDR right does not require the most sophisticated tooling on the market. It requires someone asking the harder question before the automation runs: If this fires on a real user doing a real job, what happens next, and is that outcome we can defend?
