TL;DR: Identity threat detection and response focuses on runtime abuse of stolen credentials, token misuse, anomalous role assumption, and account takeover because cloud attackers increasingly rely on legitimate identity activity rather than malware, according to Orca Security. The operating assumption has shifted: prevention is necessary, but detection must catch what a valid identity does after authentication fails.
NHIMG editorial — based on content published by Orca Security: ITDR for the Cloud
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- Pre-authorise containment for high-confidence abuse Define in advance when your platform can revoke sessions, disable keys, quarantine identities, or block source context.
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.
👉 Read Orca Security's analysis of ITDR for cloud identity threats →
Cloud ITDR and NHI abuse: what IAM teams need to know?
Explore further
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: ITDR for cloud identities: runtime detection for NHI abuse