How do security teams decide whether ITDR is working?

Why This Matters for Security Teams

ITDR is not judged by how many identity alerts appear, but by whether responders can identify the owning identity, confirm the misuse path, and contain it quickly. That matters because identity attacks now span service accounts, API keys, OAuth grants, and SaaS entitlements, which means a slow or fragmented response leaves attackers with a longer window to move laterally. NIST’s NIST Cybersecurity Framework 2.0 frames this as a governance and response problem, not just a detection problem.

NHIMG research shows why maturity is often overstated: only 5.7% of organisations have full visibility into their service accounts, and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. That means a team can have good tooling and still fail at the operational test if identity ownership, revocation, and correlation are unclear. The Ultimate Guide to NHIs also highlights that 97% of NHIs carry excessive privileges, which makes containment harder once misuse begins.

In practice, many security teams discover ITDR gaps only after a compromised credential has already been used to escalate access or exfiltrate data, rather than through intentional validation of response readiness.

How It Works in Practice

Security teams decide ITDR is working by testing the full path from alert to action. The strongest signal is not a single detection score, but whether an analyst can answer four questions quickly: what identity is involved, what changed, what it can access, and how to revoke or constrain it without breaking production. That requires good asset-to-identity mapping, ownership metadata, and response playbooks that cover human and non-human identities.

Operationally, mature ITDR programmes measure:

• time to triage, from alert receipt to confirmed identity context
• time to contain, from confirmation to token revocation, session termination, or account disablement
• percentage of alerts resolved without manual data gathering across multiple consoles
• coverage of privileged, federated, and third-party identities
• rate of false positives that waste responder time without improving confidence

In an ITDR workflow, identity telemetry should tell analysts whether the event came from an interactive user, a service account, or a workload credential. The State of Non-Human Identity Security reports that only 1.5 out of 10 organisations are highly confident in securing NHIs, which is a strong indicator that visibility and response remain weak in many environments. For baseline control design, teams often align alerting and response to NIST Cybersecurity Framework 2.0 so detection, analysis, and containment are linked instead of siloed.

Where this becomes practical is in incident drills: responders should be able to trace the identity, identify the owner, pull the applicable entitlement or secret source, and execute revocation through a documented path. If they must reconstruct the answer from SIEM, IAM, cloud logs, and a secrets manager with no shared identity graph, the programme is still immature. These controls tend to break down in heavily federated environments where ownership is distributed across teams and third-party integrations because revocation paths are inconsistent and telemetry is incomplete.

Common Variations and Edge Cases

Tighter ITDR metrics often increase operational overhead, requiring organisations to balance faster containment against the risk of disrupting legitimate automation. That tradeoff matters most when service accounts, CI/CD pipelines, and SaaS integrations depend on persistent credentials or shared ownership.

Current guidance suggests that ITDR should be assessed differently for human logins and machine identities. For human accounts, rapid lockout may be acceptable. For non-human identities, immediate disabling can break production, so teams increasingly rely on step-down actions such as scoped token revocation, key rotation, or temporary policy restriction. Best practice is evolving here, and there is no universal standard for how much containment automation is safe across all workloads.

Edge cases also include third-party OAuth applications, headless jobs, and cloud-native workloads that rarely authenticate in a traditional sign-in pattern. In these cases, alert quality depends on context, not just anomaly detection. NHIMG data shows 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which means ownership and blast radius often remain unclear until after an event. The JetBrains GitHub plugin token exposure is a useful reminder that a single exposed token can turn a software integration into an enterprise incident. Security teams should treat ITDR as working only when the playbook still holds under these messy, mixed-identity scenarios.

Related resources from NHI Mgmt Group

• How should security teams measure whether NHI secret controls are working?
• How do security teams know whether identity posture management is working?
• How can security teams tell whether NHI governance is actually working?
• How do teams know whether model governance is working?