ITDR in practice: detecting credential misuse before privilege escalation

Build the evidence pipeline before writing detections

Treat ITDR as an investigation and enforcement architecture, not a single alert feed. NIST’s zero trust model grants no implicit trust based on network location or asset ownership. Recommended implementation: centralize Entra user and service principal sign-in and audit logs, identity risk events, and relevant Office activity in a SIEM. Microsoft’s token theft playbook documents these investigation inputs. Correlate authentication evidence with subsequent resource activity and identity changes so analysts can investigate suspected misuse before reviewing potential privilege escalation.

Keep collection speed separate from detection speed. Entra ID Protection runs real-time detections during sign-in, but its catalog also includes offline detections. Microsoft documents risk-data export through diagnostic settings, including Event Hubs, and collection through Microsoft Graph APIs. Recommended engineering checks are to verify timestamps, measure ingestion delay, and test missing-event handling. Full risk reporting generally requires Entra ID P2; lower tiers expose limited information. Workload identity risk reports and detection tabs require Workload Identities Premium, so establish licensed visibility before promising coverage.

Evidence: What is Microsoft Entra ID Protection?, Zero Trust Architecture, What are risk detections?, Token theft playbook

Investigate token replay without treating anomalies as proof

A stolen token can provide resource access even after its legitimate user satisfied MFA. Entra’s Anomalous Token detection covers session and refresh tokens, identifying characteristics such as unusual lifetime or use from an unfamiliar location. It can be calculated in real time or offline. Microsoft explicitly warns that low- and medium-risk results retain a higher-than-normal false-positive likelihood. Treat the alert as an investigation trigger, not proof of replay, and compare application, IP address, user agent, location, and other available characteristics against expected activity.

Recommended triage should prioritize unfamiliar non-interactive user sign-ins, especially when suspicious devices are involved, as Microsoft’s playbook advises. Then inspect credential additions, device registrations, mailbox changes, and privileged-account changes after the trigger. Microsoft recommends Conditional Access policies requiring interactive phishing-resistant authentication for medium-or-higher sign-in risk and sensitive authentication-context actions, including configured PIM role activation. Access is denied if the attacker cannot reauthenticate. These controls depend on configuration and detection; they are not a guarantee that every stolen token will be identified or stopped.

Evidence: What are risk detections?, Protecting tokens in Microsoft Entra, Token theft playbook

Review service principal activity as a separate investigation

Microsoft’s token theft playbook requires access to service principal sign-in and audit logs and documents export categories including RiskyServicePrincipals and ServicePrincipalRiskEvents. The supplied evidence does not describe a built-in detector for every unusual service principal logon pattern. Recommended practice is therefore to build an operational baseline from available logs and owner-approved expectations: which workload authenticates, from where, and for what purpose. Validate available fields before writing rules, and distinguish observed deviations from Microsoft-generated workload risk detections in incident records.

Hypothetical example: a service principal normally used by an approved deployment workload begins authenticating from an unexpected source. That deviation should initiate review, not an automatic declaration of compromise. Recommended review order is to identify the application owner, compare the activity with authorized deployment changes, inspect associated audit events, and determine whether permissions or credentials changed. Escalate unexplained activity to incident response with the relevant evidence preserved. Do not apply a human MFA remediation procedure to a service principal without establishing an appropriate workload-specific response.

Evidence: What is Microsoft Entra ID Protection?, Token theft playbook

Use travel alerts in a sequenced response

Impossible Travel is an offline detection supplied through Microsoft Defender for Cloud Apps, not a native real-time travel verdict. It identifies geographically distant user activities occurring faster than travel between those locations would allow; it requires Entra ID P2 and qualifying Defender for Cloud Apps licensing. Atypical Travel is a separate offline detection comparing sign-ins with historical behavior. Its documented suppression of obvious VPN and organizational-location false positives, and its initial learning period, should not be attributed to Impossible Travel.

Recommended review sequence: confirm the detection type and timing, reconstruct the affected identity’s activity, validate unexpected locations or devices, inspect credential and privileged-account changes, then select containment and remediation. Correlate delayed travel findings with earlier sign-in signals rather than waiting for travel analysis before investigating. Microsoft documents near-real-time access revocation when high user risk is detected only for applications supporting continuous access evaluation. Finally, record why activity was confirmed legitimate or treated as compromise, and verify the configured response rather than assuming an alert completed containment.

Evidence: What are risk detections?, Protecting tokens in Microsoft Entra, Token theft playbook