ITDR Explained: What Identity Detection Can See—and Who Responds

Picture this: no alarms, no malware alerts, no strange files. Just an employee’s account quietly logging in at 2 a.m., creating a mail rule that forwards invoices to an outside address, and registering a new “backup” MFA device. Every step used valid credentials. Every step looked like normal administration.

This is what most modern breaches actually look like. Attackers don’t break in anymore—they log in. Industry incident reports consistently show that stolen or abused credentials are the leading way attackers get a foothold. Which raises an uncomfortable question: if the attacker looks exactly like your employee, what’s watching for that?

The answer is ITDR—Identity Threat Detection and Response.

What ITDR actually is

You may already have EDR (Endpoint Detection and Response) watching your laptops and servers for malicious behavior. ITDR applies the same idea to identities. Instead of watching devices, it watches accounts: logins, MFA events, permission changes, token activity, and the small configuration tweaks attackers make to stay hidden.

Where EDR asks “is this device doing something malicious?”, ITDR asks “is this person really this person—and should this account be doing that?”

What ITDR catches that other tools miss

• Impossible travel and improbable logins—a sign-in from Denver at 4:55 p.m. and Kyiv at 5:10 p.m. is not a business trip.

• MFA fatigue attacks, where an attacker spams push notifications until a tired employee taps Approve.

• Session token theft, which lets attackers skip the password and MFA entirely by stealing an already-authenticated session.

• Malicious inbox rules and OAuth app grants—the quiet persistence tricks used in business email compromise.

• Privilege escalation, like a standard user suddenly being added to an admin role at midnight.

• Dormant and orphaned accounts that come back to life—often a former employee’s access being exploited.

Why prevention alone isn’t enough

MFA, conditional access, and strong passwords are essential—and determined attackers still get past them through phishing kits that proxy logins in real time, token theft, and simple human error. Prevention lowers the odds; it can’t make them zero. ITDR is the safety net for when someone gets through: detection measured in minutes instead of the weeks it typically takes to discover a compromised account.

That time gap is the whole story. An attacker inside a mailbox for an hour is an incident. An attacker inside a mailbox for three weeks is wire fraud, data theft, and a very awkward call to your customers.

What response looks like

Detection without response is just a more stressful newsletter. Real ITDR closes the loop automatically: revoke the active session, force a password reset, block the suspicious sign-in, disable the malicious mail rule, and alert a human to investigate. Done well, the account is contained before the attacker finishes their coffee.

Where to start

• Turn on the identity protection features already included in your Microsoft 365 licensing—many businesses own them and have never enabled them.

• Review who holds admin roles and remove standing privileges nobody uses.

• Alert on new inbox rules, new MFA device registrations, and consent grants to third-party apps.

• Feed identity alerts to someone who actually watches them—a dashboard nobody reads is not detection.

• Test it: simulate a suspicious login and time how long it takes anyone to notice.

Identity is the new perimeter, and for most businesses it’s the least-watched one. Entice builds ITDR into our managed security stack—monitored around the clock, with response measured in minutes. If you’re not sure what would happen if one of your accounts were compromised tonight, that’s exactly the conversation to have with us this week.

ITDR—identity threat detection and response—focuses on suspicious activity around accounts, authentication, access changes, and identity-connected services. It is not a single product or a guarantee of a particular response outcome.

Identity activity versus endpoint activity

Endpoint security looks primarily at device behavior: processes, files, persistence, network activity, and device health. Identity monitoring focuses on account and access activity: sign-ins, authentication events, role changes, consent grants, mailbox rules, session use, and other changes that may warrant investigation. These domains overlap, but neither replaces the other.

Microsoft Entra ID Protection is one example of an identity-risk capability. Microsoft describes it as helping organizations detect, investigate, and remediate identity-based risks; its available reports, policies, and remediation options depend on configuration, roles, and licensing.

What ITDR can contribute—and what still needs an owner

Four identity signals that need context

Unexpected sign-in location

A sign-in from a new geography or network can be meaningful, but travel, VPN use, mobile routing, and cloud egress can create false positives.

Repeated MFA prompts

A burst of prompts can indicate an attack or a broken application, an enrollment change, or a user repeatedly retrying a sign-in.

New mailbox rule or consent grant

A forwarding rule or new application consent can be suspicious, but some changes are legitimate administrative or workflow activity.

Privilege or recovery change

A new privileged role, MFA method, or recovery action deserves scrutiny, but its meaning depends on approved change records and the actor’s role.

Automated action, human review, and response authority

Depending on the tooling, permissions, confidence, and approved runbooks, ITDR may automate selected containment actions or alert an authorized responder for review. A policy may require stronger authentication, block access, or prompt a reset; another event may need context before anyone acts. The decision path should be documented before an alert occurs.

Dependencies that determine the outcome

• Identity provider and connected identity systems

• Log coverage and retention

• Licensing and enabled capabilities

• Device state and endpoint telemetry where relevant

• Permissions to investigate or contain

• Response authority and change controls

• Approved runbooks and escalation paths

• After-hours scope and service agreement terms

Start with the license and configuration inventory

First confirm which Entra and Microsoft 365 identity-protection capabilities your licenses include and which require additional licensing or configuration. Then confirm which logs are available, which actions are permitted, and who owns the response decision.

Questions to ask an MSP or security provider

• Which identity systems, users, workload identities, and event types are in scope?

• Which alerts are automated, which are routed for review, and which require customer approval?

• Who can disable an account, revoke a session, reset credentials, or alter access?

• What logs are retained, and where are they reviewed?

• Which licenses, roles, and configuration steps are prerequisites?

• What is included during business hours, after hours, and during an incident?

• Which response commitments are written into the selected service agreement?

Entice scope caveat

The signed agreement and selected service level control what Entice provides, including any monitoring, alert handling, escalation, after-hours activity, and response actions. Confirm those details with the applicable service owner before relying on an operational assumption.

Microsoft Entra ID Protection overview — Microsoft. Updated February 10, 2026.