ITDR for the Cloud: Identity Threat Detection and Response Explained

Key Takeaways

• ITDR (Identity Threat Detection and Response) is a security discipline, coined by Gartner in 2022, that detects and responds to attacks against identities: stolen credentials, abused tokens, anomalous role assumption, and hijacked accounts that prevention tools let through.
• Identity is now the primary cloud attack surface. CrowdStrike’s 2026 Global Threat Report found that 82% of detected intrusions were malware-free, reflecting attackers’ growing reliance on stolen credentials and legitimate identity abuse rather than malware.
• In the cloud, the identities under attack are increasingly machines: service accounts, access keys, OAuth apps, and workload identities that cannot pass an MFA prompt and that no human watches.
• ITDR is not IAM, PAM, EDR, or CIEM. It works on the identity plane at runtime, assuming credentials will be compromised, and it detects abuse of legitimate-but-stolen access that authentication and posture tools cannot catch.
• CIEM and ITDR are complementary halves of cloud identity security: CIEM hardens the attack surface (posture), and ITDR defends it when an identity is abused (runtime). Orca runs both on one agentless data model, so an identity threat is scored by the sensitive data and resources it can actually reach.

ITDR (Identity Threat Detection and Response) detects and responds to identity-based attacks in real time: credential theft, token abuse, anomalous privilege use, and account takeover. Gartner introduced the term in 2022 to describe the gap between authentication and runtime identity abuse. IAM may decide who gets in, but ITDR monitors how a legitimate-looking identity behaves once it is inside.

The category matters because identity has become a primary cloud attack surface. Attackers increasingly rely on stolen credentials, trusted identities, and legitimate administration tools rather than traditional malware, shifting the defensive focus from preventing initial access to detecting misuse after authentication. In the cloud, the twist is that most identities are not people. Service accounts, access keys, and OAuth grants outnumber human users, and they carry the standing access attackers want.

This article defines ITDR, explains why identity became a cloud attack vector, walks through how ITDR works, covers machine and non-human identities, shows common cloud attack patterns, and distinguishes ITDR from IAM, PAM, EDR, and cloud infrastructure entitlement management. 

What Is ITDR (Identity Threat Detection and Response)?

ITDR stands for Identity Threat Detection and Response. It is a security discipline that monitors identities and their behavior for signs of compromise, then detects, alerts on, and responds to identity-based attacks as they happen. Gartner coined the term in 2022 to describe tools and practices that protect the identity infrastructure itself, after a run of breaches showed that attackers were targeting identity systems directly rather than exploiting software vulnerabilities.

The defining assumption separates ITDR from everything around it. Identity and access management decides whether a login is allowed. ITDR assumes that decision can be fooled because a phished password or stolen access key can produce a login that looks completely legitimate. So ITDR watches what happens after authentication: which APIs an identity calls, which roles it assumes, where it connects from, and whether any of that matches how the identity normally behaves. When the behavior breaks the pattern, ITDR treats it as a possible identity attack and can respond before the attacker reaches the data.

Why identity became the primary cloud attack vector

Identity became the main way into cloud environments because it is cheaper to steal a credential than to develop an exploit. Four mechanisms drive most of it. Credential theft harvests passwords and long-lived access keys from phishing pages, info-stealer malware, and public code repositories. MFA fatigue attacks spam a user with push notifications until one gets approved. Token theft lifts an active session or OAuth token so the attacker skips authentication entirely. And over-permissioned roles mean that once any of those works, the access is broad.

The cloud amplifies each one. A single leaked AWS access key can call hundreds of APIs across services, and unlike a stolen laptop, the theft leaves no physical trace. Access keys often live for months because no one rotates them, sessions can be replayed from anywhere, and the blast radius of one compromised identity depends entirely on its permissions. That last point is why posture matters, and why over-permissioned identities turn a routine credential leak into a major incident.

ITDR in the cloud vs. traditional (AD/endpoint) ITDR

Most ITDR content describes a different problem: protecting on-premises Active Directory and the human credentials inside it. Traditional ITDR watches for Kerberoasting, golden-ticket forgery, DCSync, and lateral movement between domain-joined endpoints. The identity store is AD, the attacks are AD-specific, and the telemetry comes from domain controllers and endpoint agents.

Cloud ITDR works on a different plane. The identity store is the CSP control plane (AWS IAM, Entra ID, Google Cloud IAM), the attacks target API calls and role assumption rather than domain tickets, and most of the identities are machines, not employees. The telemetry comes from cloud audit logs such as CloudTrail, Azure Activity Logs, and Google Cloud audit logs, not from agents on hosts. An AD-trained team that assumes ITDR means watching domain controllers will miss the cloud version of the problem entirely, because a cloud identity attack often never touches an endpoint. It happens through legitimate API calls made with stolen keys.

Why ITDR Matters for Cloud Security

ITDR matters because prevention leaves a runtime gap that cloud teams cannot close with authentication alone. MFA, strong passwords, and least-privilege roles all reduce the odds of compromise, but none of them detect a valid credential being used by the wrong person. When an attacker logs in with a real key, every preventive control has already done its job and waved them through. Something has to watch what the identity does next, and that is the job ITDR owns.

The stakes are specific to how the cloud works. An identity attack does not need malware, does not trip endpoint detection, and does not require a single exploit. It is a sequence of authorized-looking API calls: list the buckets, assume a role, read the secrets, copy the data. Each call is individually legitimate, which is exactly why signature-based and endpoint tools stay quiet. ITDR catches the pattern, the unusual sequence and context that no single event reveals, and that detection-on-behavior is the difference between catching an intrusion in minutes and finding it in the breach report months later.

How ITDR Works: Core Components

ITDR works as a continuous lifecycle: inventory the identities, baseline their normal behavior, enrich anomalies with threat intelligence, alert and contain in real time, then investigate and remediate. The components below run as a loop, not a one-time scan, because identity attacks unfold over minutes and the response has to keep pace.

Identity inventory and contextual visibility

The first step is knowing which identities exist and what each can reach. ITDR builds an inventory of every human user, service account, role, access key, and federated identity across AWS, Azure, and Google Cloud, then maps the permissions and resources behind each one. Without that map, an alert about an identity is just a name. With it, the same alert carries context: this key belongs to a CI service account that can read a production database holding customer records.

This visibility is what turns detection into prioritization. An anomaly on an identity that can reach sensitive data is an emergency; the same anomaly on an identity scoped to a sandbox is noise. Mapping the identity attack path ahead of time is what lets ITDR rank the few alerts that matter.

Behavioral baselining and anomaly detection

ITDR learns what normal looks like for each identity, then flags deviations. The baseline comes from audit logs: which APIs the identity usually calls, from which regions and IP ranges, at which times, and which roles it typically assumes. Once that pattern is established, the detections become concrete. An access key that has only ever called read APIs from one region suddenly calling IAM write APIs from another country is a strong signal of compromise.

The highest-value detections in the cloud are behavioral rather than signature-based. Impossible travel flags a login from two distant locations within a window too short to be physical. Unusual role assumption catches an identity calling AssumeRole on a role it has never used. Privilege escalation detection watches for an identity granting itself or another principal new permissions. Each of these is a behavior an attacker needs but a legitimate user rarely produces.

Threat intelligence and risk-based prioritization

Behavioral anomalies get sharper when ITDR enriches them with external context. Threat intelligence feeds known-malicious IPs, Tor exit nodes, anonymizing VPNs, and credentials that have appeared in public leaks. An anomalous API call from an IP already tied to a known threat actor jumps the queue. Mapping observed behavior to the MITRE ATT&CK framework also tells responders which technique they are looking at, such as valid-account abuse or token impersonation.

Prioritization then combines two axes: how suspicious the behavior is and how much the identity can reach. Risk-based scoring puts a credible anomaly on a high-privilege identity at the top, so a small team spends its attention on the alerts that could become breaches rather than triaging every login from a new coffee shop.

Real-time alerting, automated response and containment

Detection only helps if the response is fast enough to matter, so ITDR pairs alerts with automated containment. When a high-confidence identity threat fires, the platform can revoke active sessions, disable or rotate the compromised access key, quarantine the identity by stripping its permissions, or block the source IP. The point is to cut the attacker’s access in seconds, before the API calls reach the data.

Automation has to be calibrated to consequence. Auto-revoking a session for a clear impossible-travel-plus-privilege-escalation event is safe and reversible. Tearing down a production service account on a weaker signal can cause an outage, so mature programs gate the most disruptive actions behind confidence thresholds and human approval. The design goal is to contain fast where the signal is strong and escalate to a person where it is ambiguous.

Investigation and remediation

After containment, ITDR supports the cleanup that closes the incident. Investigation reconstructs the full session: every API call the compromised identity made, every role it assumed, and every resource it touched, assembled from audit logs into a timeline a responder can follow. That scope assessment answers the question that decides the whole response, which is what the attacker actually reached.

Remediation removes the lingering access attackers leave behind. A common pattern is to use one stolen credential to create a second one, a backdoor IAM user or an extra access key, so revoking the original is not enough. Thorough remediation hunts for those artifacts, rotates affected secrets, and tightens the permissions that made the identity worth attacking, which feeds back into the posture work cloud infrastructure entitlement management (CIEM) owns. Pairing this with a tested incident response process keeps the cleanup disciplined under pressure.

ITDR for Machine and Non-Human Identities

The cloud-specific reason ITDR matters is that most cloud identities are not people. Service accounts, access keys, OAuth applications, CI/CD pipeline identities, and workload identities all authenticate, hold permissions, and call APIs, and they vastly outnumber human users in a typical environment. They are also the harder identities to defend, which makes them the ones attackers prefer.

Non-human identities break the controls built for people. A service account cannot answer an MFA prompt, so the strongest preventive control for human accounts does not apply. Their credentials are often long-lived keys checked into config files or pipeline variables rather than passwords rotated on a schedule. And no one notices when a machine identity behaves oddly, because there is no user to report that their account “feels off.” A stolen employee password might get flagged when the real employee logs in from their actual location; a stolen service-account key can run for weeks in silence.

That silence is exactly why behavioral ITDR is the right defense for machine identities. A service account is, in one sense, easier to baseline than a human: it does a narrow, repetitive job, calling the same handful of APIs from the same infrastructure. Any departure from that tight pattern, a new API, a new region, a new role, stands out sharply. ITDR turns the predictability of machine identities into a detection advantage, watching for the deviation that a human-centric tool would never think to look for. 

Cloud ITDR Use Cases and Real-World Attacks

The clearest way to see ITDR is through the cloud attacks it catches. The patterns below are the identity-driven incidents that define modern cloud intrusions, and each one is a sequence of legitimate-looking actions that only behavioral detection exposes.

CSP credential and access-key compromise

The most common cloud identity attack starts with a leaked long-lived credential. A developer commits an AWS access key to a public GitHub repository, or an info-stealer pulls it from a workstation, and within minutes automated scanners find it. The attacker then calls the cloud API directly: enumerate permissions, list S3 buckets, and copy data out, all from infrastructure the key has never been used from before.

ITDR catches this on behavior, not on the leak itself. The key’s first call from a new ASN, followed by a burst of enumeration APIs it has never issued, breaks its baseline immediately. A response action rotates the key and revokes its sessions before the data exfiltration completes, turning a breach into a contained event.

Anomalous IAM role assumption and privilege escalation

Cloud attackers rarely stay on the identity they first compromised. They use it to assume more powerful roles and widen their reach, the cloud version of lateral movement. The technique chains native IAM features: a compromised principal calls AssumeRole to pivot into a higher-privilege role, or abuses an iam:PassRole permission to hand a high-privilege role to a service it controls, such as a Lambda function or EC2 instance, then acts with that role’s permissions to take over the account.

These moves are invisible to endpoint and network tools because they are pure control-plane API calls. ITDR flags them as a behavioral chain: an identity assuming a role it has never assumed, then immediately issuing IAM write calls, then granting new permissions. The sequence, not any single call, is the detection, and it maps cleanly to the privilege-escalation tactics in MITRE ATT&CK.

Insider threat and account takeover

Account takeover and insider abuse produce the same hard problem: a real identity doing something harmful. In a takeover, an attacker who phished an employee or won an MFA-fatigue prompt logs in as that user and acts with their full permissions. In an insider case, the credentials were never stolen at all. Either way, authentication succeeds and access controls approve every action.

ITDR detects these through behavioral context that authentication cannot see. A user account that logs in at an unusual hour from a new device, then accesses data stores it has never touched and starts a bulk download, deviates from its own baseline even though every credential is valid. The detection is the change in behavior, and the response can step up verification or suspend the session while a human reviews it.

OAuth/OIDC token and federation abuse

The most modern cloud identity attacks skip passwords entirely by abusing tokens and trust. In consent phishing, an attacker tricks a user into authorizing a malicious OAuth application. The application then receives a token granting standing access to mail and files without ever needing the password again or triggering MFA. In federation abuse, an attacker who compromises an identity provider or a federation trust mints tokens that downstream cloud services accept as legitimate.

These attacks are dangerous precisely because the resulting access looks authorized. ITDR addresses them by monitoring for the tells: a new OAuth grant with broad scopes to an unknown application, a token used from an anomalous location, or authentication patterns that suggest a forged or replayed token. Catching token abuse requires watching the identity layer itself, which is the plane endpoint tools never observe.

ITDR vs. IAM vs. PAM vs. EDR vs. CIEM

ITDR is easy to confuse with the tools around it, so the distinction is worth drawing precisely. Identity and access management and privileged access management are preventive: they decide who may access what. EDR detects threats, but on endpoints. CIEM manages cloud entitlements as a posture problem. ITDR is the runtime detection-and-response layer for the identity plane, and it assumes the others will sometimes fail. The table below shows where each fits.

Category	Plane	Primary Job	Timing	Catches a stolen-but-valid credential?
IAM	Identity	Authenticate and authorize access	Prevention	No. It grants the valid login
PAM	Privileged identity	Vault and broker privileged access	Prevention	Partially, only for managed privileged accounts
EDR	Endpoint	Detect and respond to host threats	Runtime, endpoint	No. Identity API abuse never touches a host
CIEM	Cloud entitlements	Right-size permissions, cut excess access	Posture	No. It reduces blast radius, not abuse
ITDR	Identity	Detect and respond to identity abuse	Runtime, identity	Yes. This is its core job

ITDR vs. IAM

IAM is the front door, ITDR is the camera inside. IAM authenticates an identity and enforces what it is allowed to do, which is essential and entirely preventive. The moment a valid credential is used by an attacker, IAM is satisfied, because the login is legitimate by every check it runs. ITDR starts where IAM stops, watching the authenticated session for behavior that suggests the credential is in the wrong hands. You need both: IAM to minimize who gets in, ITDR to catch the ones who get in anyway.

ITDR vs. EDR

ITDR and EDR are the same idea on different planes. EDR (Endpoint Detection and Response) watches processes, files, and memory on hosts and is excellent at catching malware and endpoint intrusions. But a cloud identity attack made of API calls with a stolen key never executes anything on an endpoint, so EDR never sees it. ITDR watches the identity plane, the logins, tokens, and API behavior that EDR has no visibility into. The decision rule is simple: use EDR for threats that run on a machine, use ITDR for threats that act as an identity, and run both because cloud attacks increasingly do the latter.

ITDR vs. CIEM: posture vs. runtime

This is the pairing that defines cloud identity security, and the two halves are complementary rather than competing. CIEM is posture: it inventories entitlements, finds over-permissioned and unused access, and right-sizes permissions so that any single identity can do less damage if compromised. ITDR is runtime: it assumes an identity will be compromised despite good posture and detects the abuse when it happens.

The relationship is cause and effect. CIEM reduces the blast radius, so when ITDR catches a stolen credential, the attacker has less to reach. ITDR provides runtime visibility into which identities are actually being targeted. CIEM hardens the attack surface; ITDR defends it in real time. Least-privilege work, entitlement-sprawl cleanup, and CIEM tooling all live on the posture side and reduce the surface this article’s runtime layer has to defend. Together they close the loop that either one alone leaves open.

What to Look For in an ITDR Solution

A cloud ITDR solution is only as good as its visibility, its detections, and its ability to act. When evaluating ITDR tools and vendors, weigh these capabilities against your actual cloud estate rather than a generic feature list.

• Multi-cloud control-plane coverage. It should ingest identity telemetry from AWS, Azure, and Google Cloud, not just one provider or on-prem Active Directory.
• Machine and non-human identity support. Service accounts, access keys, OAuth apps, and workload identities must be first-class, since they are most of your identities and the hardest to defend.
• Behavioral analytics, not just rules. Look for per-identity baselining that catches impossible travel, anomalous role assumption, and privilege escalation, beyond static signatures.
• Context and attack-path awareness. Detections should be enriched with what each identity can reach, so alerts are prioritized by blast radius rather than fired flat.
• Real-time automated response. The tool should revoke sessions, rotate or disable keys, and quarantine identities, with confidence thresholds gating the disruptive actions.
• Threat-intelligence enrichment. Known-bad IPs, leaked-credential feeds, and MITRE ATT&CK mapping sharpen detection and speed triage.
• Integration with the SOC. Findings should flow into your SIEM and incident workflows, not sit in another isolated console.

The common thread is choosing an ITDR solution that shares context with your posture tooling. An ITDR product that knows nothing about your entitlements produces alerts without blast-radius context, which is the difference between a ranked shortlist and an unprioritized flood.

How Orca Approaches Cloud ITDR

Cloud ITDR is only as useful as the context behind each alert, and context is where most identity tools fall short. An alert that says “this access key made an unusual call” is a starting point. An alert that says “this access key can reach a database of customer PII and just made an unusual call from a new country” is a decision. The difference is whether the platform knows what the identity can actually reach.

The Orca Cloud Security Platform builds that context with agentless SideScanning™, which inventories every identity, permission, and resource across a multi-cloud estate without deploying agents. Because Orca runs ITDR on the same unified data model as its cloud infrastructure entitlement management, an identity threat is scored against the real attack path it opens, from compromised identity to reachable sensitive data, and prioritized by exploitability and blast radius rather than by alert severity alone. The posture side reduces the attack surface, the runtime side defends it, and both read from one graph. Detections feed automated response, so a confirmed identity threat can have its sessions revoked and its keys rotated before the attacker reaches the data.

To see how agentless, full-stack context turns identity alerts into prioritized, contained incidents, get a demo.

Frequently asked questions about ITDR for the Cloud