Key points
- ITDR watches what accounts do after they sign in. It reads sign-in logs, directory audit events and app audit events.
- It catches attacks such as password spray, MFA fatigue, consent phishing and mail forwarding rules, each mapped to a MITRE ATT&CK technique.
- Correlation is the core of it. Five weak alerts on one account, in order, are one attack and one investigation.
- Your identity provider decides who gets in. A SIEM stores logs for you to query. EDR watches devices. ITDR judges what accounts do with access.
- Judge a tool on the logs it reads, the logic you can see, how it correlates, and who presses the button in a response.
What is ITDR?
Identity threat detection and response (ITDR) is the practice of watching what accounts do after they sign in. It looks for the patterns of known attacks, and it helps you contain an account that someone else controls.
Gartner introduced the term in its 2022 security trends. It said "credential misuse is now a primary attack vector." Three years later the data agrees. In the Verizon 2025 Data Breach Investigations Report, credential abuse was the leading way in, at 22% of breaches.
An attacker with a working password needs no exploit. Your identity provider sees a valid sign-in and lets them through. ITDR exists for what happens next.
What does an ITDR tool watch?
ITDR reads three kinds of log. Each one answers a different question about an account.
- Sign-in logs. Who signed in, from where, with which app and which authentication method. Microsoft Entra ID records interactive and non-interactive user sign-ins, plus service principal and managed identity sign-ins. The last two matter, because app registrations sign in too.
- Directory audit events. Changes to the tenant: a role assigned, a password reset, an MFA method added, an app granted consent.
- App audit events. What happened inside the apps. In Microsoft 365, the audit log covers sharing links, file access and mailbox rules across Exchange, SharePoint, OneDrive and Teams.
A SaaS-first team has no domain controller to watch. The identity provider and the apps are the perimeter. Their logs are the ground ITDR covers.
Two details from Microsoft's Office 365 Management Activity API reference matter here. Unified audit logging must be on before any of this data flows. And events in the feed "will not necessarily appear in the order in which they occurred." A tool has to sort by event time before it can read a sequence.
Which attacks does ITDR catch?
Most identity attacks on a SaaS estate leave a mark in one of those three logs. The table maps common ones to the MITRE ATT&CK technique a good tool will name.
| Attack | What you see in the logs | MITRE ATT&CK technique |
|---|---|---|
| Sign-in with a stolen password | A sign-in from a new country, or travel no person could make | T1078.004 (Valid Accounts: Cloud Accounts) |
| Password spray | One address failing once or twice on many accounts | T1110.003 (Brute Force: Password Spraying) |
| MFA fatigue | A burst of push prompts, then one approval | T1621 (Multi-Factor Authentication Request Generation) |
| Consent phishing | A new OAuth grant to an unknown app that asks for mail or files | T1528 (Steal Application Access Token) |
| Privilege grab | A directory role added to an ordinary account | T1098.003 (Account Manipulation: Additional Cloud Roles) |
| Mail forwarding | A new inbox rule that sends mail outside the company | T1114.003 (Email Collection: Email Forwarding Rule) |
The technique ID matters for more than tidiness. Your analysts can look it up, compare coverage between tools, and report on it in the same terms as the rest of the industry.
Why does correlation matter more than any single alert?
One odd sign-in is common. People travel, use a VPN, or switch phones. Alone, most identity alerts are weak.
Take Jaime Rivera. At 02:11 his phone shows six MFA prompts in a row. At 02:14 he approves one, and his account signs in from a new country. At 02:21 an unknown app gets consent to read his mail. At 02:38 a new inbox rule forwards invoices outside the company. Four alerts in four queues look like noise. On one account, in that order, inside half an hour, they are one attack.
Correlation has a second axis. A password spray never trips an account-level threshold, because each account fails only once. Group the failures by source address instead, and one address working through ten accounts stands out.
A good ITDR tool correlates on both axes. It turns each group into one investigation with a timeline, and it shows what the account can reach.
What does the response look like?
Response starts with containment, then moves to scope and record. For Jaime's account, the steps run in this order.
- Revoke his sessions and refresh tokens, and block sign-in while you work.
- Reset his password, and remove any MFA method the attacker added.
- Remove the inbox rule, the OAuth grant and any role that changed.
- Check what the account could reach: groups, apps, shared mailboxes and files.
- Search for the same source address on other accounts.
- Record what you found, what you changed, and who decided.
Revoking sessions does not end every token at once. Microsoft's guidance on revoking access notes that access tokens last one hour by default. It also says Entra ID "can't directly revoke a session token issued by an application." What the attacker set up outlives the session too. The inbox rule keeps forwarding mail, and the consent grant stays in the tenant, until someone removes them.
The steps should arrive with the alert. At 2am, the person on call may never have seen this rule fire before.
How is ITDR different from SIEM, EDR and IAM?
Each tool watches a different layer, and each one has an identity blind spot.
| Tool | What it watches | The question it answers | Where identity attacks slip past |
|---|---|---|---|
| IAM and the identity provider | The sign-in itself | Should this sign-in get through? | A valid password with an approved MFA prompt looks legitimate |
| SIEM | Logs from everywhere | What happened, if you write the query? | Identity detections are only as good as the rules your team writes and tunes |
| EDR | Processes on laptops and servers | Is this device running something malicious? | A stolen token used from the attacker's own machine never touches your devices |
| ITDR | Sign-ins, directory changes and app audit events | Is someone misusing this account right now? | It needs the right logs connected, and it does not see device activity |
ITDR does not replace the others. Many teams run all four. The question is whether identity attacks get a tool built to read identity data, or a backlog of SIEM rules nobody has time to write.
How should you evaluate an ITDR tool?
Ask a vendor these questions, and ask to see each answer in the product.
- Which logs does it read today? Name the identity provider, the sign-in types, and the app audit sources.
- Can you read the detection logic? You should see what a rule matches, which technique it maps to, and how to exclude known-good activity.
- How does it correlate? On the account, on the source address, and in event-time order.
- What does an investigation show? A timeline, the path the attacker took, and what the account can reach.
- What arrives with an alert? Triage questions, escalation criteria and ordered response steps.
- Who presses the button? Find out what the tool changes in your tenant, and whether a person approves it first.
- Does it cover non-human identities? Service principals and app registrations sign in and hold grants too.
How EnscureX Detect does ITDR
Detect connects to Entra ID as your identity provider and reads its sign-in and audit events. It also reads Microsoft 365 audit content across Exchange, SharePoint and OneDrive, Teams, Intune, Power Platform and Purview DLP.
Rules are written in a Sigma-compatible schema and mapped to MITRE ATT&CK, with false-positive and exclusion blocks for tuning. Correlation runs on the identity and on the source address, and on time, order and repetition. Related alerts become one investigation with a severity, an assignee, the timeline, the attack path and the blast radius.
Each rule ships its own response steps: the triage questions and the criteria for escalating. A person runs them. Detect records how each alert was closed, and it never changes your tenant because a rule fired.
Frequently asked questions
Is ITDR only about Active Directory?
No. Many ITDR guides cover attacks on on-premises Active Directory, such as Kerberoasting. A team with no domain controllers still has an identity provider and SaaS apps to protect, and their logs are where ITDR looks.
Does ITDR replace MFA or conditional access?
No. MFA and conditional access decide whether a sign-in gets through. ITDR watches for the attacks that get past them, such as an approved MFA prompt or a stolen session.
Do you need a SOC to run ITDR?
A full SOC helps, but correlation matters more for a small team. If five alerts arrive as one investigation, one person can work the queue in a morning.
What is the difference between ITDR and XDR?
XDR joins detection across endpoints, networks, email and cloud, and identity is one input among many. ITDR goes deeper on identity data alone: sign-ins, consents, roles and mailbox changes.
Where this work happens in EnscureX
Sources
- Gartner, Gartner Identifies Top Security and Risk Management Trends for 2022 (Mar 7, 2022)
- Verizon 2025 Data Breach Investigations Report
- Microsoft Learn, Sign-in logs in Microsoft Entra ID
- Microsoft Learn, Office 365 Management Activity API reference
- Microsoft Learn, Revoke user access in an emergency in Microsoft Entra ID
- MITRE ATT&CK, T1078.004 (Valid Accounts: Cloud Accounts)
- MITRE ATT&CK, T1110.003 (Brute Force: Password Spraying)
- MITRE ATT&CK, T1621 (Multi-Factor Authentication Request Generation)
- MITRE ATT&CK, T1528 (Steal Application Access Token)
- MITRE ATT&CK, T1098.003 (Account Manipulation: Additional Cloud Roles)
- MITRE ATT&CK, T1114.003 (Email Collection: Email Forwarding Rule)