Identity has quietly become the primary attack surface. Attackers rarely drop malware on a hardened endpoint anymore. They log in. They phish a session token, fatigue a user into approving a push, or abuse an OAuth consent grant, and from there they move laterally with valid credentials that look, to most of your tooling, exactly like a legitimate employee. Identity Threat Detection and Response (ITDR) is the discipline built to catch that activity. This guide explains what ITDR covers, why a traditional SIEM tends to miss identity attacks, and the detection content and hardening that make a real difference.
Why your SIEM misses identity attacks
A SIEM is excellent at correlating logs once you know what to look for. The problem with modern identity attacks is that the signal lives inside the identity provider (IdP), it is often subtle, and the malicious events are individually indistinguishable from normal ones. A successful sign-in from a new country is not inherently malicious. An OAuth app being granted mailbox read access is a daily occurrence in most organisations. A refresh token being used is the entire point of refresh tokens.
SIEM rules built on single events generate either too much noise or too little. The events that matter are sequences and relationships: a push approval that follows fourteen denied prompts, a token minted in Auckland and replayed from a hosting provider in another hemisphere ninety seconds later, a service principal that suddenly enumerates every group in the tenant. ITDR is purpose built to model identity behaviour, baseline it, and alert on the deviations that indicate compromise rather than on raw event volume.
What ITDR actually covers
ITDR is not a single product category so much as a set of detection and response capabilities focused on the identity fabric. In practice it covers the following.
Account takeover (ATO)
The detection goal is to catch a legitimate account being driven by an illegitimate operator. Useful signals include impossible travel that accounts for VPN egress, a sudden change in the user agent and device fingerprint, sign-ins from anonymising infrastructure, and a burst of activity that does not match the user's working hours or historical application set. ATO detections should fuse the authentication event with what happens next, because the strongest signal is often the post-login behaviour, not the login itself.
MFA fatigue and push bombing
When an attacker already holds a password, they spam MFA push prompts hoping the user eventually taps approve. The detection content is straightforward and high value: alert on a threshold of denied or unanswered MFA prompts within a short window, especially when followed by an approval. The durable fix is to move away from simple push approval to number matching, phishing resistant methods such as FIDO2 or passkeys, and to cap prompt frequency at the IdP.
Token and session theft
Phishing kits and infostealers increasingly steal the session or refresh token rather than the password, which sidesteps MFA entirely. The replayed token carries valid claims, so the abuse hides in plain sight. Detections worth building include token replay from a new IP or device that does not match the issuance context, anomalous use of long lived refresh tokens, and primary refresh token use that conflicts with device compliance state. Continuous access evaluation and token binding shorten the window in which a stolen token is useful.
OAuth consent and application abuse
An attacker who cannot beat MFA can instead trick a user (or an admin) into consenting to a malicious application that requests mail, file or directory scopes. Because the app holds its own grant, it persists even after the user resets their password. ITDR detections here include new high privilege consent grants, apps requesting offline access to sensitive scopes, and credentials being added to existing service principals. This is one of the highest value areas because it is frequently missed.
Lateral movement and privilege escalation
Once inside, attackers pivot. In Entra ID that looks like role assignments, adding owners to applications, or abusing directory roles. In Okta it looks like admin role grants and policy changes. In Google Workspace it looks like delegation and domain wide changes. ITDR baselines who normally performs administrative actions and flags out of pattern privilege changes, particularly when they cluster shortly after a suspicious sign-in.
Detection content across Entra, Okta and Workspace
Good ITDR is platform aware. Each IdP exposes the same broad threats through different telemetry, so detection engineering has to be tailored.
- Microsoft Entra ID: sign-in and audit logs, risky user and risky sign-in signals, conditional access evaluation results, and Graph activity. Watch consent grants, service principal credential additions, conditional access policy edits, and break glass account usage.
- Okta: the System Log is rich. Monitor for new factor enrolment that bypasses existing MFA, admin role grants, network zone changes, and rate limited authentication that signals brute force or push bombing.
- Google Workspace: admin audit, login audit and token audit logs. Watch for super admin grants, app passwords, third party app authorisations to sensitive scopes, and forwarding or delegation rules that exfiltrate mail.
The unifying principle is to centralise these logs, baseline normal identity behaviour per user and per service principal, and write detections that fire on sequences rather than isolated events. Our team builds this kind of detection content as part of a broader managed detection and response engagement. You can read more on our services page.
Hardening the identity provider
Detection without hardening is a treadmill. The controls that remove whole classes of identity attack are well understood and worth prioritising.
- Enforce phishing resistant MFA (FIDO2, passkeys, certificate based) for administrators first, then everyone.
- Use number matching and disable plain approval push to defeat fatigue attacks.
- Apply risk based conditional access and continuous access evaluation so that a change in risk revokes the session quickly.
- Restrict who can consent to applications, and require admin review for sensitive scopes.
- Place administrative roles behind privileged identity management with just in time elevation and approval.
- Protect break glass accounts, monitor them explicitly, and alert on any use.
- Bind tokens to devices and shorten session lifetimes for high risk applications.
Takeaways
ITDR exists because identity is now the breach. A SIEM that only correlates raw events will miss MFA fatigue, token replay and consent abuse because each underlying event looks legitimate. The answer is to baseline identity behaviour, write detections on sequences across Entra, Okta and Workspace, and harden the IdP so that the easiest attacks simply stop working. If you are unsure where your blind spots are, an identity focused assessment is the fastest way to find out. Get in touch through our contact page to scope one.
FAQ
Is ITDR a replacement for my SIEM? No. ITDR complements it. The SIEM remains the central correlation and storage layer. ITDR provides the identity specific baselining and detection content that generic SIEM rules struggle to produce.
We already have MFA. Are we covered? MFA raises the bar but does not stop token theft, consent abuse or fatigue attacks against weak push factors. Phishing resistant methods plus detection close those gaps.