Identity Threat Detection and Response: Wiring Identity into the SOC
Identity is now the primary attack vector, yet most SOCs still treat it as an afterthought. ITDR is about making identity signals first-class citizens in detection and response.
The uncomfortable truth of modern intrusions is that attackers increasingly don't break in — they log in. Phished credentials, token theft, MFA fatigue, abuse of standing privilege: the attack has moved to identity, while much of the security operations centre is still tuned for malware and network anomalies. Identity Threat Detection and Response (ITDR) is the discipline of closing that gap — treating identity as a first-class telemetry source and a first-class response surface.
The detection signals that matter
Identity generates rich signals that, correlated, tell a clear story. The ones I prioritise feeding into detection:
- Authentication anomalies — impossible travel, new-device sign-ins, MFA fatigue patterns (repeated push prompts), and authentication from anomalous locations or ASNs.
- Privilege events — elevation requests, new admin role assignments, changes to high-value groups, and use of privileged accounts outside normal patterns.
- Directory changes — creation of accounts, modification of trusts, changes to authentication policy, and tampering with logging.
- Token and session anomalies — session hijacking indicators, token replay, and refresh-token use from unexpected contexts.
Posture is half the battle
ITDR is not only detection — it is also identity posture management: continuously finding the weaknesses attackers exploit before they do. Dormant privileged accounts, accounts without MFA, excessive standing privilege, misconfigured trusts, shadow admin paths (accounts that can become admin through a chain of permissions even if they aren't admins directly). Closing these is detection's best friend, because every gap you close is an attack path you no longer have to detect.
ITDR is where the IAM team and the SOC have to actually integrate, not just coexist. IAM knows what normal identity behaviour looks like and owns the response levers; the SOC owns detection and incident process. Neither succeeds at identity threats alone.
Response: own the levers, rehearse the playbook
Detecting an identity attack is worthless if you can't respond decisively. The identity team owns the response levers the SOC needs in an incident: disable an account, force re-authentication, revoke all active sessions and tokens, reset credentials, and quarantine privileged access. These need to be fast, well-documented, and rehearsed — because in a live token-theft incident, the difference between revoking sessions in five minutes versus fifty is the difference between containment and a bad week. Build the playbooks before you need them.
Centralise and retain identity logs
None of this works if identity logs are scattered across the directory, the IdP, the PAM platform, and a dozen applications, each with its own retention. Centralise identity telemetry into the SIEM, retain it long enough to support investigation and your regulatory notification obligations, and protect it from tampering — because disabling or clearing logs is one of the first things a competent attacker does. Queryable, immutable, centralised identity logging is the substrate everything else in ITDR stands on.
Identity is the new battleground, and ITDR is how the identity team earns its seat in the SOC. The organisations treating identity signals as first-class — for both detection and response — are the ones that will catch the login-not-break-in attacks that increasingly define real incidents.
Looking for an IAM lead who thinks this way?
I help regulated enterprises govern identity at scale — from SailPoint to PAM to audit.
Get in touch