ITDR for cloud identities: runtime detection for NHI abuse

At a glance

What this is: ITDR is runtime detection and response for identity abuse in cloud environments, with a particular focus on stolen credentials, token misuse, role abuse, and compromised non-human identities.

Why it matters: It matters because IAM, PAM, and posture controls can approve access that later turns malicious, so practitioners need behavioural detection and fast containment across human, NHI, and autonomous identity programmes.

By the numbers:

• 82% of detected intrusions were malware-free, reflecting attackers’ growing reliance on stolen credentials and legitimate identity abuse rather than malware.
• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities.

👉 Read Orca Security's analysis of ITDR for cloud identity threats

Context

Identity threat detection and response, or ITDR, closes the gap between a successful login and a secure session. In cloud environments, the identity is often a service account, access key, OAuth grant, or workload identity, so the question is not only who authenticated, but what that identity starts doing once it is inside.

Cloud IAM, PAM, and CIEM reduce exposure, but they do not by themselves catch legitimate-looking API activity after a credential is abused. That makes runtime behavioural monitoring central to cloud identity security, especially where machine identities outnumber human users and can operate without any visible user interaction.

Orca Security frames ITDR around cloud runtime abuse, and that lens aligns with the broader NHI challenge: controls built for login events do not automatically govern post-authentication behaviour. For practitioners, the operational problem is not just access approval, but detecting when an identity’s actions no longer fit its normal scope.

Key questions

Q: What breaks when cloud identities are treated as if login security is enough?

A: When teams stop at authentication, they miss the malicious activity that happens after a valid login. A stolen key, abused token, or compromised service account can still enumerate resources, assume roles, and exfiltrate data while every preventive control appears to have worked. Runtime detection is what closes that gap.

Q: Why do service accounts and access keys increase cloud identity risk?

A: They are powerful because they are non-interactive, persistent, and often tied to high-value cloud permissions. Once stolen, they can be used directly through APIs without MFA prompts or user visibility, which means the attacker can behave like a legitimate workload while moving toward larger blast radius.

Q: How do teams know whether cloud identity detection is actually working?

A: Look for detections that combine behavioural drift, attack-path context, and containment outcomes. If alerts tell you an identity did something unusual but cannot show what that identity can reach, the programme is still operating as a noisy logging layer rather than a response capability.

Q: What should organisations do when a cloud identity is suspected of abuse?

A: Contain the identity first by revoking sessions, disabling or rotating keys, and stripping unnecessary permissions before the attacker completes the sequence. Then reconstruct the full API timeline to see what the identity touched and close any backdoor credentials or extra roles created during the incident.

Technical breakdown

Identity inventory and attack-path context

ITDR begins with a complete inventory of identities, permissions, and reachable assets across cloud platforms. That context matters because an alert about an access key is only actionable when you know whether it can touch a sandbox or production data. By linking identities to the resources they can reach, the tool can rank risk by blast radius rather than by raw alert volume. This is what turns cloud identity telemetry into prioritised response.

Practical implication: Map every identity to its reachable resources before relying on runtime detections.

Behavioural baselines for cloud identities

Cloud ITDR relies on learning the normal API and role-assumption pattern for each identity. The strongest detections are not static indicators, but deviations such as new regions, new principals, unusual write actions, or impossible travel paired with privilege use. For machine identities, the baseline is often narrow, which makes drift easier to spot than it is for human users. The value is in spotting when a legitimate credential starts behaving like an attacker tool.

Practical implication: Baseline identity behaviour from cloud audit logs, then alert on drift in API sequence, geography, and privilege use.

Real-time containment of compromised identities

Once suspicious behaviour crosses a confidence threshold, ITDR should act on the identity directly. Typical responses include revoking sessions, rotating or disabling keys, quarantining the principal by stripping permissions, and blocking the source context. Because cloud attacks often unfold entirely through control-plane calls, response has to happen before the sequence reaches data exfiltration or lateral movement. Automation needs thresholds because a bad response can also disrupt production workloads.

Practical implication: Predefine containment actions by confidence level so runtime abuse can be stopped without overcorrecting.

Threat narrative

Attacker objective: The attacker wants to turn legitimate cloud identity access into broad control-plane reach, then extract data or expand privileges without triggering traditional defences.

1. Entry occurs when an attacker obtains a valid cloud credential, token, or federated identity and uses it to enter through the control plane rather than through malware.
2. Escalation follows when the compromised identity calls role-assumption APIs, adds permissions, or chains native cloud actions to widen access without tripping endpoint controls.
3. Impact arrives when the attacker uses that legitimate-looking access to enumerate resources, read secrets, and exfiltrate data or take over additional cloud assets.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.

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

NHI Mgmt Group analysis

Identity abuse is now a runtime problem, not just an authentication problem. ITDR matters because the decisive security question has shifted from whether a principal can log in to what it does after it logs in. Cloud attackers increasingly use valid credentials, legitimate APIs, and normal control-plane features to move toward impact. For practitioners, that means access approval is no longer the finish line; runtime behaviour is where compromise becomes visible.

Non-human identities expose the limits of people-centric identity controls. Service accounts, tokens, access keys, and workload identities cannot be managed as if they were users waiting for MFA or a help desk reset. Their behaviour is narrower, more repetitive, and often invisible to humans, which makes behavioural monitoring more valuable than prompt-based prevention. The governance implication is simple: programmes that still treat machine identity as a subset of human IAM will miss the attack surface that matters most.

Runtime identity security is becoming a control-plane discipline. The most citable shift here is that the identity attack path now sits inside the cloud fabric itself, where API calls can be both legitimate and malicious at the same time. Identity does not stay safe because it is authenticated; it stays safe only if its runtime actions remain inside a governed blast radius. That is the concept practitioners should carry forward when they evaluate detection, containment, and entitlement design.

ITDR and CIEM are complementary, but they solve different failure modes. CIEM reduces excessive permissions before abuse occurs, while ITDR detects the abuse once the identity is active. The field-level mistake is to treat posture as if it solved runtime and runtime as if it could compensate for entitlement sprawl. Practitioners need both views because cloud identity compromise is a lifecycle problem, not a single control problem.

From our research:

• Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks, according to The 2024 ESG Report: Managing Non-Human Identities.
• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, which underlines how common identity compromise has become in machine-heavy environments.
• For a broader NHI governance baseline, see NHI Lifecycle Management Guide, which is the natural next step for teams building lifecycle controls around identities that now need runtime monitoring too.

What this signals

Identity runtime monitoring is becoming the default control layer for cloud environments. Teams that only invest in posture will keep finding that legitimate access is the easiest path to compromise, especially when machine identities dominate the estate. The practical shift is to treat behavioural telemetry as an operational input, not a luxury add-on, and to connect it to response workflows that can act before exfiltration completes.

Service accounts and workload identities need separate governance treatment from human users. Their failure modes are different, their activity patterns are narrower, and their compromise can remain invisible for longer because there is no person to notice a suspicious login. That means access review, offboarding, and entitlement governance have to reflect the identity type, not just the system of record.

Runtime containment only works when entitlement design has already reduced the blast radius. If an identity can reach too much, every detection becomes harder to triage and every response becomes more disruptive. The programme signal to watch is whether your cloud identity model can tell responders, in minutes, what a compromised principal can actually touch.

For practitioners

• Inventory every cloud identity with reachable context Build a live map of users, service accounts, roles, access keys, and federated identities, then tie each one to the resources it can actually reach. Alerts without attack-path context are hard to prioritise and easy to ignore.
• Baseline behaviour from cloud audit logs Use CloudTrail, Azure Activity Logs, and Google Cloud audit logs to define normal API sequences, role assumptions, and source locations for each identity. Treat unusual region changes, rare write actions, and new role targets as detection candidates.
• Pre-authorise containment for high-confidence abuse Define in advance when your platform can revoke sessions, disable keys, quarantine identities, or block source context. Pair each action with confidence thresholds so automation can stop clear compromise without causing avoidable outages.
• Separate posture gaps from runtime detections Use CIEM to reduce over-permissioned identities and ITDR to catch abuse after authentication. That split keeps entitlement review, behavioural detection, and incident response from collapsing into a single undifferentiated control tower.

Key takeaways

• ITDR addresses the gap between a legitimate login and malicious post-authentication behaviour, which is where most cloud identity abuse now happens.
• The evidence points to a crowded attack surface, with machine identities, stolen credentials, and role abuse combining to make runtime detection a core cloud control.
• Practitioners need both entitlement reduction and behavioural containment, because posture and runtime answer different parts of the same identity threat problem.

Key terms

• Identity Threat Detection and Response: ITDR is the practice of detecting and responding to abuse of identities after authentication has succeeded. In cloud environments, it focuses on behaviour such as unusual API calls, suspicious role assumption, token misuse, and account takeover across both human and machine identities.
• Attack-path context: Attack-path context is the mapping between an identity and the data, services, and permissions it can actually reach. It turns an alert from a vague signal into a risk decision by showing whether a suspicious identity can touch sensitive assets or only low-impact resources.
• Runtime identity abuse: Runtime identity abuse is the misuse of a valid credential, token, or role during an active session. The identity may be technically authenticated, but its actions fall outside normal behaviour and are driven by an attacker using legitimate control-plane access.
• Machine identity: A machine identity is a non-human credential or principal used by software, workloads, services, or automation to authenticate and call resources. These identities often have persistent permissions and limited human oversight, which makes runtime monitoring and lifecycle governance especially important.

What's in the full article

Orca Security's full article covers the operational detail this post intentionally leaves for the source:

• A deeper walkthrough of ITDR mechanics across identity inventory, anomaly scoring, alerting, and containment.
• A practical comparison of ITDR with IAM, PAM, EDR, and CIEM for teams deciding which control owns which failure mode.
• Examples of cloud identity attack patterns, including access-key compromise, role escalation, and token abuse.
• Guidance on what to look for in an ITDR solution when you need runtime visibility rather than posture alone.

👉 Orca Security's full article covers cloud ITDR mechanics, use cases, and comparison points in more implementation detail.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.