Identity threat detection and response is reshaping zero trust

At a glance

What this is: Permiso Security's guide explains how ITDR fits into zero trust by detecting identity abuse in real time after authentication, especially when compromised credentials, service accounts, or abnormal behaviour bypass preventive controls.

Why it matters: It matters because IAM, PAM, and NHI programmes cannot rely on sign-in checks alone when attackers act through legitimate identities inside the trust boundary.

By the numbers:

• With over 90% of breaches now involving compromised credentials, organizations are forced to treat identity monitoring as a runtime control rather than a login-only check.

Context

Identity threat detection and response, or ITDR, is a detection-and-response layer for identity behaviour rather than a replacement for authentication or access governance. The core problem is simple: credentials can be valid and still be abused, which means prevention alone leaves a blind spot inside the trusted session.

In zero trust environments, that blind spot matters because verification at sign-in does not tell you whether the identity behaves normally afterward. ITDR exists to watch post-authentication activity across user accounts, service accounts, and cloud identity providers, which makes it relevant to NHI governance as well as human IAM.

Permiso Security frames the topic through common practitioner questions, but the underlying issue is broader than any one product category. Organisations that already run PAM or IGA still need behavioural detection when attackers use legitimate access paths.

Key questions

Q: What breaks in zero trust when identity behaviour is not monitored after login?

A: Zero trust loses its runtime assurance. A valid credential can still be used maliciously once the session starts, so authentication alone cannot distinguish normal access from compromise. Without post-authentication monitoring, attackers can move through systems, abuse service accounts, or access sensitive resources while appearing legitimate.

Q: Why do compromised credentials create such a large breach risk in identity-led environments?

A: Because a stolen credential often appears legitimate to downstream systems, which means the attacker can blend into normal access flows. Once inside, they can escalate privilege, reuse sessions, and move laterally without tripping perimeter controls. In cloud and SaaS environments, the compromise of one identity can quickly become an enterprise-wide access problem.

Q: What signals indicate that a service account has been abused?

A: Interactive logons, unfamiliar source hosts, atypical time-of-day use, and sudden access bursts are the most useful signals. A service account should have a narrow behavioural pattern. When it starts acting like a person, or begins touching mailbox or cloud resources it never used before, treat that as compromise until proven otherwise.

Q: How should organisations combine ITDR with PAM and SIEM?

A: Use PAM to govern privileged access, SIEM to centralise and correlate logs, and ITDR to spot identity abuse in real time. The three controls solve different problems. PAM limits who can act, SIEM stores and correlates evidence, and ITDR detects when a trusted identity starts behaving like an attacker.

Technical breakdown

Post-authentication identity monitoring

ITDR focuses on what an identity does after it has been authenticated. That means monitoring authentication patterns, privilege use, resource access, and sequencing of actions rather than only checking whether the login succeeded. In zero trust terms, the trust decision is not finished at the door. The control has to observe whether the session remains consistent with expected behaviour, because stolen credentials, session hijacking, and misuse of valid accounts all look legitimate at the authentication layer. This is why ITDR complements, rather than replaces, access governance and PAM. It adds runtime visibility where preventive controls stop.

Practical implication: monitor identity behaviour continuously and treat post-login activity as part of the access decision, not an audit afterthought.

Service account abuse and identity baselines

Service accounts are especially difficult for traditional security tools because their behaviour is supposed to be narrow, repetitive, and predictable. ITDR uses that predictability to flag deviations such as interactive logons, unusual resource access, or account use from unexpected systems. The technical value is not just alerting on an anomaly. It is detecting when a non-human identity crosses the boundary between a narrow operational function and interactive misuse. That makes service account monitoring a core NHI use case, especially in cloud and hybrid environments where shared trust relationships can mask abuse.

Practical implication: establish behavioural baselines for non-human identities and investigate any interactive or out-of-pattern use immediately.

Correlating identity signals across hybrid environments

The article stresses that ITDR works best when it correlates identity signals across Active Directory, Azure AD, cloud platforms, PAM, and SIEM or SOAR tooling. Technically, that correlation is what turns isolated events into a threat pattern. A failed login, a suspicious location, and a privilege change may each look ordinary alone, but together they can indicate credential compromise or lateral movement. That is why ITDR is best understood as an identity control plane for detection and response, not as a single alert source. It depends on context enrichment and cross-platform correlation to reduce false positives and improve response timing.

Practical implication: integrate identity telemetry across platforms so behavioural anomalies are assessed in context, not as disconnected log events.

Threat narrative

Attacker objective: The attacker wants to turn trusted identity access into stealthy internal movement and unauthorized system access without triggering preventive controls.

1. Entry begins when an attacker uses compromised credentials or a valid identity to pass authentication checks and enter the environment.
2. Escalation follows when that identity is used outside its normal behavioural pattern, such as unusual privilege use, off-hours access, or movement into new systems.
3. Impact occurs when the attacker uses legitimate access paths to reach sensitive systems, move laterally, or operate service accounts for malicious activity before containment.

Breaches seen in the wild

• Codefinger S3 ransomware 2025: Codefinger used victims' compromised AWS keys to re-encrypt S3 buckets with SSE-C, set 7-day deletion and demanded ransom for the key.
• Storm-1283 OAuth apps abuse 2023: Storm-1283 added secrets to new and existing OAuth apps in Entra ID and used them to run Azure cryptomining VMs, costing victims up to $1.5 million.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

ITDR is the runtime layer zero trust was missing. Zero trust is strongest at authentication, but authentication alone does not govern what a valid identity does next. That gap matters because modern intrusions increasingly use legitimate identities rather than broken perimeter controls. Practitioners should treat ITDR as the control that extends identity verification into the live session.

Identity governance assumes a stable identity lifecycle, but attack behaviour is now session-based. Access reviews, certifications, and PAM approvals all assume an identity persists long enough for humans to observe and govern it. That assumption holds poorly when compromised credentials are used briefly, abused quickly, and abandoned before the next review cycle. The implication is that governance cannot depend on periodic inspection alone.

Service accounts are not a side case, they are a primary abuse surface. The article's own examples show that non-human identities are monitored for anomalies because they often have elevated or persistent access. That aligns with OWASP-NHI concerns around secret leakage, overprivilege, and improper offboarding. Practitioners should stop treating machine identities as operational exceptions and start treating them as governed identity subjects.

Identity threat detection and response narrows the distance between detection and containment. When identity abuse is the attack path, response has to be identity-specific as well. Session termination, access revocation, and step-up authentication only work if the signal arrives early enough and with enough context. That is why ITDR belongs beside SIEM and SOAR, not underneath them.

Identity blast radius is now a governance metric. The article shows that the real question is no longer whether an identity can authenticate, but how far it can move once trusted. ITDR turns behavioural visibility into a measure of blast radius across human accounts, service accounts, and cloud identities. Practitioners should use that lens to prioritise where identity controls need tighter runtime oversight.

From our research library:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
• Compromised credentials take an average of 246 days to identify and contain, according to IBM's 2025 Cost of a Data Breach Report.
• Read next: Identity Threat Detection and Response (ITDR) Guide

What this signals

ITDR shifts identity security from periodic governance to live behavioural control. That matters because access review cadences and certification workflows cannot reliably catch identities that are stolen, abused, and discarded inside a short attack window. For practitioners, the programme question is whether detection coverage exists at the point where trust is exercised, not just where it is granted.

Service accounts deserve the same runtime scrutiny as user accounts. When a non-human identity starts acting like a person, or a person account starts behaving like a service account, the signal usually means control boundaries have broken down. The useful lens is not just who owns the account, but whether the account's behaviour still matches its intended function.

Identity blast radius: the practical measure of how far a compromised identity can move before containment. ITDR reduces that blast radius by enriching identity signals and triggering response actions fast enough to interrupt abuse before it becomes a wider incident.

For practitioners

• Baseline post-authentication behaviour Define normal access patterns for human users, service accounts, and cloud identities so deviations can be detected as identity abuse rather than generic anomalies.
• Correlate identity events across platforms Feed Active Directory, cloud IAM, PAM, and SIEM telemetry into one detection path so a privilege change, unusual login, and resource access can be evaluated together.
• Prioritise service account monitoring Flag interactive logons, new resource paths, and unusual timings for service accounts, because those behaviours often indicate a compromise of a non-human identity.
• Automate containment for high-confidence identity abuse Use identity-specific response actions such as session termination, access revocation, or forced re-authentication when the behaviour pattern strongly indicates compromise.
• Align ITDR with zero trust controls Treat ITDR as the runtime detection layer that complements verification, conditional access, and privilege governance across hybrid environments.

Key takeaways

• ITDR matters because authenticated identities can still become attack paths, especially in environments where zero trust stops at sign-in and governance checks run on a slower cadence.
• The article frames service accounts and compromised credentials as the central abuse surface, which is why behavioural monitoring is becoming part of identity security rather than a separate SOC function.
• Practitioners should combine identity baselines, cross-platform correlation, and identity-specific containment so trust decisions continue after authentication, not just before it.

Key terms

• Identity Threat Detection and Response: Identity threat detection and response is the practice of finding misuse of credentials, unusual access patterns, and compromised identities across human and machine actors. For NHIs, it relies on telemetry from code, vaults, cloud services, and pipelines to detect abuse early enough to contain it.
• Post-Authentication Monitoring: Post-authentication monitoring is the practice of watching identity behaviour after a login, token exchange, or session start. It matters because successful authentication does not prove trustworthiness for the rest of the session, especially when attackers use valid credentials or trusted flows.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Service account anomaly: A service account anomaly is any behaviour that departs from the account's normal machine-like pattern, such as interactive login, unusual timing, or access to new resources. For non-human identities, small deviations are often more meaningful than they are for people.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.