How does ITDR differ from IAM and PAM?

IAM (Identity and Access Management) is the prevention layer: it provisions identities, authenticates users, federates with applications, enforces MFA, and tracks role and group membership. PAM (Privileged Access Management) is the elevation-and-control layer for privileged identities: it vaults credentials, brokers sessions, records elevated activity, and enforces just-in-time elevation. ITDR sits on top of both as the detection-and-response layer: it consumes identity events from the IAM and PAM platforms (sign-ins, MFA challenges, password changes, group adds, role grants, vault access, session recordings) and combines them with directory service events, SaaS session telemetry, federation traffic, and endpoint identity signals to detect identity-targeted attacks and orchestrate response. The three are adjacent rather than substitutes. IAM and PAM prevent and control; ITDR detects when prevention has failed and drives the response. Mature programmes run all three with each owning its layer and feeding identity context to the next.

How does ITDR differ from EDR, XDR, and SIEM?

EDR (Endpoint Detection and Response) is anchored on the endpoint: process telemetry, file system activity, memory artefacts, and network connections from the device. XDR (Extended Detection and Response) widens the lens to multiple telemetry sources (endpoint, email, identity, network, cloud) with correlation between them. SIEM (Security Information and Event Management) is the broader log collection, retention, search, and rule-engine platform. ITDR is anchored specifically on the identity surface: identity provider events, directory service events (Active Directory, Entra ID, LDAP), privileged access events, SaaS session and OAuth grant events, federation trust events, and the human and non-human identity inventory. ITDR overlaps with XDR on identity content (an XDR with strong identity detection content carries ITDR features inside it) and with SIEM on retention and search (an ITDR built on SIEM uses SIEM as the storage layer). The category exists as a distinct label because identity-targeted attacks (kerberoasting, golden ticket, OAuth token theft, federation trust abuse, MFA bombing, consent phishing) cannot be detected reliably from endpoint or network telemetry alone; they require directory and identity provider telemetry with identity-specific detection content built on top.

How does ITDR differ from ISPM and CIEM?

ISPM (Identity Security Posture Management) is the posture cousin of ITDR. ISPM observes the standing identity posture against a baseline policy (orphaned accounts, dormant accounts, over-privileged accounts, missing MFA, weak conditional access policies, identity provider misconfiguration, federation trust misconfiguration) and tracks drift on the posture record. ITDR observes the active attack surface and triggers when an identity is being targeted. CIEM (Cloud Infrastructure Entitlement Management) is the cloud-control-plane sibling: CIEM observes who can do what against AWS, Azure, and Google Cloud resources, with a strong emphasis on machine and workload identities and least-privilege enforcement. The three sit on adjacent anchors. ISPM is the posture record, ITDR is the detection record, and CIEM is the cloud-control-plane entitlement record. Mature enterprise identity programmes run all three with ISPM owning the standing posture, ITDR owning detection and response on identity attacks, and CIEM owning the cloud entitlement detail. Vendors increasingly bundle two or all three into a unified identity security platform; the operating disciplines remain distinct even when the user interface collapses them.

When should an enterprise adopt ITDR?

The signals that ITDR is the next investment include: incidents that started with credential theft, MFA bypass, OAuth token theft, or session hijack and that the SOC could not detect from endpoint or network telemetry alone; auditors and customers asking which identity attacks the team can detect and how the response is run; the identity provider footprint has grown into multiple tenants (Active Directory plus Entra ID, Okta plus Auth0 plus an SaaS-side directory, multiple federated tenants for acquisitions); the non-human identity count (service accounts, OAuth integrations, workload identities, API keys) materially exceeds the human identity count; privileged access events are reviewed only by sample rather than by detection content; the SOC has limited identity content in the SIEM or XDR and identity-specific alerts dominate the noise; cyber insurance, SEC disclosure, NIS2 Article 21, or DORA Articles 5 through 16 require demonstrable identity-attack detection and response. Programmes that operate a small, single-tenant identity footprint with strong MFA, strong conditional access, and a small set of privileged users may not need a dedicated ITDR platform yet; the detection content can live inside the wider XDR or SIEM. Programmes with multi-tenant identity footprints, material non-human identity exposure, or recurring identity-attack incidents are the ones for which ITDR pays back.

Does SecPortal function as an ITDR platform?

SecPortal does not market itself as a dedicated ITDR platform with native identity provider connectors, real-time identity event streaming, directory service detection content, OAuth and session telemetry ingestion, or behavioural analytics on identity activity. SecPortal does provide the operating record an internal security, identity, SOC, AppSec, vulnerability management, or GRC team uses to track findings (including ITDR-side findings imported from a dedicated ITDR platform, an XDR with identity content, a SIEM with identity rules, an identity posture assessment, a third-party identity security audit, or a manual identity review) under a unified schema with CVSS 3.1 calibration and lifecycle tracking, bulk finding import for CSV exports of identity findings, document management for the identity inventory, identity policy artefacts, identity-incident after-action records, and identity processor agreements the programme produces, activity log with CSV export for audit-read durability, compliance tracking against ISO 27001, SOC 2, PCI DSS, and NIST framework controls including the identity-specific controls (Annex A 5.15 to 5.18, CC6.1 to CC6.3, AC-2 through AC-6, IA-2 through IA-8), team management with RBAC, MFA enforcement, and AI report generation for the leadership read of the identity posture. Programmes evaluating dedicated ITDR platforms should benchmark coverage of their identity portfolio (on-prem directory, cloud identity provider, federated tenants, SaaS-side directories, non-human identity inventory, privileged access platform) against the named ITDR vendors, then use SecPortal as the consolidated operating record that holds the resulting findings alongside the wider security backlog.

← Back to Blog

Technical16 May 202618 min read

Identity Threat Detection and Response (ITDR): Explained

Identity Threat Detection and Response (ITDR) is the operating discipline of observing the human, machine, and workload identity surface across the enterprise; baselining each identity, role, group, and grant against a standing identity posture policy; detecting identity-targeted attacks in flight (credential theft, kerberoasting, golden and silver ticket abuse, pass-the-hash, OAuth token theft, consent phishing, MFA bombing, session hijacking, federation trust abuse, privilege escalation, dormant account takeover); responding to identity incidents with structured containment and recovery; and governing the identity posture record against a single source of truth. For CISOs, identity security teams, SOC analysts, AppSec, vulnerability management, GRC and compliance owners, and the security leaders who sponsor the programme, ITDR is the category that names the identity-attack problem alongside ASPM, CSPM, DSPM, SSPM, and AI-SPM. This guide covers what ITDR is and is not, the five functional layers, how ITDR differs from IAM, PAM, EDR, XDR, SIEM, ISPM, and CIEM, the signals ITDR consumes, the recurring adoption pitfalls, the audit-read shape of the operating record against ISO 27001, SOC 2, NIST 800-53, PCI DSS, and NIST CSF 2.0, and a phased rollout that takes an identity programme from MFA-as-the-only-control to a defensible identity detection and response capability.

What ITDR Actually Is

Identity Threat Detection and Response is the layer that sits on the identity plane. Programmes adopted strong identity preventive controls over the last decade (MFA on the identity provider, conditional access policies on cloud directories, privileged access vaulting for elevated accounts, secret management for non-human identities) and still kept losing the credential-theft, OAuth token theft, MFA-fatigue, kerberoasting, and federation-trust-abuse incidents that drive most of the high-impact enterprise breaches in the published incident reports of the last several years. ITDR is the discipline that observes the identity surface in flight, detects when prevention has been bypassed or compromised, and runs a structured response on the identity record itself rather than relying on endpoint and network detection to surface what was always an identity-side attack.

The motivation is one of detection asymmetry. Identity-targeted attacks leave their primary forensic trail on the identity provider, the directory service, the SaaS session log, the OAuth grant table, the privileged access session record, and the federation trust audit log. They leave secondary traces on the endpoint (a Kerberos ticket request, an OAuth callback) and on the network (sign-in originating from an unexpected geography), but the primary signal lives on the identity stack. SOC programmes that rely on endpoint and network telemetry alone routinely miss kerberoasting (Service Principal Name enumeration plus offline cracking), golden ticket forgery, OAuth refresh token theft, consent phishing, MFA bombing, and federation trust abuse because the attack does not generate the endpoint-side signals their detection content was tuned to catch. ITDR is the shape of detection content built on identity telemetry, with response actions that target the identity record (revoke session, rotate credential, invalidate token, tighten conditional access, disable account, expire grant, freeze group membership) rather than the endpoint or the network.

The category label is recent. Industry analysts started using ITDR as a distinct category in 2022 to 2023 as the breach reporting made clear how many incidents started on the identity surface and how few of those were detected from endpoint or network telemetry alone. The capability it names overlaps with older disciplines (identity-aware SIEM rules, privileged access monitoring, directory service auditing, account compromise playbooks) but packages them as a unified operating record alongside the wider security posture and response categories. ITDR is the current label and the term enterprise buyers, identity engineering leads, and CISOs now use when describing the identity-detection-and-response requirement.

The Five Functional Layers

An operating ITDR record exposes five layers. Each layer can be present or absent in a given vendor offering; programmes evaluating platforms should benchmark each layer separately rather than treating ITDR as a single capability.

Layer 1: Discover the identity surface

Enumerate every identity provider, every directory service, every privileged access platform, every SaaS-side directory, every federation trust, and every non-human identity (service account, workload identity, OAuth integration, API key, federated machine identity) the enterprise actually uses. Sources include the on-prem directory (Active Directory, LDAP), the cloud identity provider (Microsoft Entra ID, Okta, Ping, Auth0, JumpCloud), the privileged access platform (CyberArk, BeyondTrust, Delinea, HashiCorp Vault for secrets and workload identity), the SaaS admin consoles for SaaS-side directories and OAuth grant inventory, the cloud provider IAM tables (AWS IAM, Azure RBAC, Google Cloud IAM, Workload Identity Federation), the secrets manager records for non-human identities, and the federation trust configuration across tenants. The discover layer is judged by the breadth of source coverage, the ability to surface non-human identities at scale (which routinely exceed human identities by an order of magnitude in real enterprise estates), the speed at which a newly provisioned identity appears on the record, and resilience against the long tail of acquired-company tenants and shadow SaaS-side directories.

Layer 2: Baseline against an identity posture policy

Pull the live configuration of each identity, role, group, grant, conditional access policy, and federation trust against a standing baseline policy. Standard baselines anchor on the orphaned account rule (no sign-in in N days, no active assignment), the dormant account rule, the over-privileged account rule, the missing MFA rule, the stale conditional access rule, the weak password policy rule, the excessive admin role assignment rule, the standing privileged session rule, the standing OAuth grant rule with excess scope, the non-rotated non-human credential rule, the standing federation trust rule with no review record, and the directory misconfiguration rule (legacy authentication protocols enabled, weak Kerberos encryption, password hash sync on accounts that should not have it). The baseline layer is judged by the breadth and accuracy of the per-identity governance model, the depth of supported identity surfaces (on-prem directory, cloud identity provider, privileged access, SaaS-side, cloud IAM, workload identity), the explainability of each finding (the operator must be able to read why a setting fails the baseline), and the cadence of the baseline pull.

Layer 3: Detect identity-targeted attacks

Run identity-specific detection content on the live event stream. Standard detection content covers credential-theft chains (LSASS memory dump indicators followed by lateral movement, password spray from a single source against many accounts, brute force against a small set of high-value accounts), Kerberos-side attacks (kerberoasting via Service Principal Name enumeration plus offline cracking, AS-REP roasting against accounts with pre-authentication disabled, golden and silver ticket usage detected via ticket lifetime and encryption type anomalies, Kerberos delegation abuse via unconstrained or constrained delegation chains), OAuth and federation abuse (anomalous OAuth grant patterns, consent phishing against new third-party apps, refresh token theft and reuse from anomalous contexts, federation trust changes outside the operative change window, token theft from local browsers replayed from new geographies), privileged escalation patterns (role assignment outside named approvers, group nesting that backdoors privilege, just-in-time elevation outside approved windows, vault access from anomalous sources), session abuse (session hijacking via stolen cookies, MFA bombing with eventual approval, conditional access bypass via legacy protocols), and non-human identity abuse (service account use outside its normal hours and source, API key reuse from anomalous geographies, workload identity reuse across boundaries). The detection layer is judged by content breadth, the false-positive profile, the time from event to alert, and the depth of identity context attached to each alert.

Layer 4: Respond to identity incidents

Operationalise the response actions on the identity record itself rather than handing the SOC a ticket that the identity team has to action manually. Standard response actions cover session revocation on the identity provider, conditional access tightening, MFA re-enrolment, credential rotation, OAuth grant revocation, refresh token invalidation, account disable with audit trail, account quarantine pending investigation, vault credential rotation, group membership freeze, federation trust suspension, and non-human credential rotation. The response layer is judged by the depth of supported response actions per identity provider, the ability to scope an action precisely (one session vs all sessions, one tenant vs all tenants), the audit trail produced per action, the ability to chain responses across the identity stack, and the operating shape of the playbooks (named owner, named approver, named expected outcome) rather than ad hoc orchestration.

Layer 5: Govern the identity posture record

Track lifecycle on each identity finding and identity incident (open, in-remediation, fixed, retest pending, accepted as exception with documented basis, deferred with re-evaluation trigger), maintain the identity exception register with owner and expiry, map findings to framework controls (ISO 27001 Annex A 5.15 access control policy, 5.16 identity management, 5.17 authentication information, 5.18 access rights, 8.5 secure authentication, 8.7 protection against malware, 8.8 management of technical vulnerabilities, 8.15 logging, 8.16 monitoring activities, SOC 2 CC6.1 logical access controls, CC6.2 prior to issuing system credentials, CC6.3 access modification, CC6.6 transmission of authentication information, CC7.1 detection of changes, CC7.2 monitoring, NIST 800-53 AC-2 account management, AC-3 access enforcement, AC-5 separation of duties, AC-6 least privilege, IA-2 identification and authentication, IA-4 identifier management, IA-5 authenticator management, IA-8 identification of non-organisational users, AU-2 audit events, AU-6 audit review, SI-4 system monitoring, PCI DSS Requirements 7 restrict access by need to know, 8 identify and authenticate users, 10 log and monitor all access, NIST CSF 2.0 PROTECT.AA access and authentication, DETECT.CM continuous monitoring, RESPOND.CO communications, RESPOND.MI mitigation), wire the identity posture into the leadership reporting cadence, and produce the recurring audit-read pack. The governance layer is judged by lifecycle discipline, exception register quality, framework mapping accuracy, and the durability of the audit-evidence shape.

ITDR vs IAM, PAM, EDR, XDR, SIEM, ISPM, and CIEM

Several adjacent categories observe parts of the identity stack from different anchors. Reading the boundaries cleanly is what stops a programme from buying overlapping platforms or from leaving an unprotected gap between them.

Category	Anchor	Relationship to ITDR
IAM	Identity lifecycle and authentication	Prevention layer. IAM provisions, authenticates, and federates. ITDR consumes IAM events to detect when prevention has been bypassed.
PAM	Privileged identity elevation and session control	Control layer for privileged identities. ITDR consumes PAM vault and session events as one of its highest-fidelity signals.
EDR	Endpoint process and memory telemetry	Endpoint anchor. EDR sees credential dumping and ticket activity on the device; ITDR sees the same attack from the identity provider and directory side. The two correlate.
XDR	Multi-telemetry correlation	Umbrella category. An XDR with strong identity content carries ITDR features inside it; an XDR without strong identity content leaves the identity surface dependent on a dedicated ITDR.
SIEM	Log collection, retention, search	Storage and rule-engine layer. ITDR built on SIEM uses the SIEM as the storage layer with identity-specific detection content layered on top.
ISPM	Standing identity posture state	Posture cousin. ISPM observes drift on the standing identity posture; ITDR observes attacks against the identity surface. Often bundled, distinct disciplines.
CIEM	Cloud-control-plane entitlement	Cloud-side entitlement record. CIEM observes who can do what against cloud resources; ITDR observes identity attacks across the full identity surface.

Mature enterprise programmes operate several of these in parallel; the categories sit on different anchors and answer different questions about the same identities, sessions, and grants. For programmes evaluating how the identity layer fits inside the wider Zero Trust strategy, the Zero Trust Architecture implementation guide covers the Identity pillar in the context of the wider five-pillar model anchored on NIST SP 800-207 and the CISA Zero Trust Maturity Model.

Signals ITDR Consumes

An ITDR record is only as strong as the signals it can ingest. The dominant signal classes in mature programmes are:

Identity provider events. Sign-in logs, MFA challenges, conditional access decisions, password resets, account lockouts, and federation events from Microsoft Entra ID, Okta, Ping, Auth0, JumpCloud, or the federation broker in use. These are the highest-fidelity primary signal for authentication-side attacks.
Directory service events. Active Directory security log events (4624 successful logon, 4625 failed logon, 4768 TGT request, 4769 service ticket request, 4776 NTLM authentication, 4720 account creation, 4732 group membership change), LDAP queries, schema changes, replication events, and trust modifications. These carry the Kerberos and replication side of the attack surface.
Privileged access events. Vault access, session start and end, session recordings, just-in-time elevation requests and approvals, and out-of-band administrative actions from CyberArk, BeyondTrust, Delinea, HashiCorp Vault, or the privileged access platform in use.
SaaS session and OAuth events.Sign-in events, session creation, OAuth grant inventory, OAuth grant creation and revocation, refresh token activity, and admin actions from the SaaS admin consoles (Microsoft 365, Google Workspace, Salesforce, Slack, GitHub, Atlassian, Notion). OAuth refresh token theft and consent phishing leave their primary trail here.
Cloud IAM events. AWS IAM API calls (CloudTrail), Azure RBAC changes (Activity Log), Google Cloud IAM changes (Cloud Audit Logs), STS assume-role activity, federation identity binding changes, and Workload Identity Federation events.
Endpoint identity signals. EDR telemetry on LSASS access, ticket cache reads, browser cookie reads targeting authentication cookies, and process activity around the authentication subsystem. ITDR consumes these as corroborating signals to the primary identity-side detection.
Non-human identity inventory.Service account inventory, workload identity inventory, OAuth grant inventory, API key inventory, and the underlying secrets-manager records. Non-human identities typically outnumber human identities by an order of magnitude and carry their own attack surface.
Threat intelligence on identity attacks.CISA advisories on identity-attack campaigns, vendor PSIRT and advisory streams (Microsoft, Okta, Auth0), sector ISAC bulletins describing identity-attack chains, and the OWASP authentication and session management guidance the programme baselines against.
Adjacent posture records. The ISPM record (standing identity posture against baseline), the SSPM record (SaaS-side identity and OAuth surface), the CIEM record (cloud entitlement detail), and the SIEM or XDR retention layer where the programme stores the underlying event log.
Manual identity reviews. Quarterly access reviews, privileged role attestations, federation trust reviews, third-party application reviews, and onboarding-and-offboarding records contribute structured findings to the ITDR record.

A mature ITDR platform exposes connectors for the identity providers, directory services, privileged access platforms, SaaS tenants, cloud IAM tables, and SIEM or XDR in use; programmes shopping for a vendor should benchmark connector breadth against the actual identity portfolio shape rather than against a glossy integrations page.

Identity Attack Classes ITDR Detects

ITDR detection content centres on the attack classes that endpoint and network detection routinely miss. Reading the catalogue helps a programme score vendor detection content honestly.

Credential theft and reuse

Password spray (one or a few common passwords against many accounts), brute force (many passwords against a small set of accounts), credential stuffing (reusing leaked credentials at scale), targeted phishing followed by sign-in from an anomalous source, and LSASS-dumped credentials replayed from a different host. The primary signal is sign-in pattern across the identity provider and directory side, with endpoint corroboration where available.

Kerberos-side attacks

Kerberoasting (Service Principal Name enumeration followed by offline ticket cracking), AS-REP roasting (against accounts with pre-authentication disabled), golden ticket forgery (TGT signed with stolen KRBTGT material), silver ticket forgery (service ticket signed with stolen service account material), delegation abuse (unconstrained or constrained delegation chained to gain access), and overpass-the-hash and pass-the-ticket lateral movement. The primary signal is directory service event log analysis with ticket-lifetime and encryption-type anomaly detection.

OAuth and federation abuse

Consent phishing (a phishing email that prompts the user to grant excessive OAuth scopes to an attacker-controlled app), refresh token theft (stolen refresh tokens replayed from a different geography or device), illicit consent grant chains (attacker apps granted broad scopes across multiple tenants), federation trust manipulation (added or modified trusts that re-route authentication), and token forgery against stolen federation signing material. The primary signal is the OAuth grant inventory plus federation event log plus sign-in correlation.

MFA bypass and session theft

MFA fatigue or MFA bombing (a flood of MFA prompts the user eventually approves), MFA push-notification approval from anomalous contexts, adversary-in-the-middle phishing with session cookie theft, legacy authentication protocol abuse to bypass conditional access, and replay of stolen session cookies from new sources. The primary signal is the MFA event stream plus sign-in correlation.

Privilege escalation

Role assignment outside named approvers, group nesting that backdoors privilege (a low-privilege group nested inside a high-privilege group), just-in-time elevation outside approved windows, dormant privileged account reactivation, and emergency-access account use outside the agreed conditions. The primary signal is the IAM and PAM change log plus the standing privileged role inventory.

Non-human identity abuse

Service account use outside its normal hours and source, API key reuse from anomalous geographies, workload identity reuse across trust boundaries, stolen CI credentials used from outside the build fleet, and machine credential leak followed by external use. The primary signal is the non-human identity inventory plus the cloud IAM and secrets-manager event stream.

Recurring Adoption Pitfalls

ITDR programmes that stall tend to fail in the same shapes. Anticipating the failure modes shortens the rollout.

ITDR scoped to the cloud identity provider only

The programme stands up identity detection on the cloud identity provider (typically Entra ID or Okta) and leaves the on-prem directory, the privileged access platform, and the SaaS-side directories unmonitored. Most enterprise identity attacks chain across surfaces (kerberoasting on AD followed by federated sign-in to the cloud provider, OAuth token theft on a SaaS app followed by lateral movement). The fix is multi-surface coverage from the start with prioritisation by attacker access asymmetry, not by ease of vendor connector.

Non-human identities ignored because they outnumber humans

The team focuses on the few thousand human users and leaves the tens of thousands of service accounts, OAuth grants, workload identities, and API keys outside the detection surface. Most modern incidents pivot through non-human identities precisely because they are under-monitored, rarely rotated, and routinely over-privileged. The fix is to inventory non-human identities first and prioritise detection content for the classes with the largest blast radius (cross-tenant OAuth grants, cloud workload identities, CI service accounts, federated machine accounts).

Detection content without response automation

Alerts fire but the response is a manual handoff to the identity team that runs hours behind the attack. Identity-targeted attacks often complete in minutes. The fix is to wire response actions (session revocation, conditional access tightening, MFA re-enrolment, OAuth grant revocation, account quarantine, vault rotation) onto the alerts with named playbooks, named approvers, and a structured audit trail rather than ticket-shaped handoff.

MFA-bombing treated as the whole problem

MFA fatigue is the most-visible identity attack of the last several years and the one with the most published incident write-ups. Programmes that scope ITDR to MFA-bombing detection leave kerberoasting, golden ticket abuse, OAuth token theft, consent phishing, federation trust manipulation, and non-human identity abuse unaddressed. The fix is a detection baseline that covers the full attack catalogue, not the most newsworthy single class.

Identity posture treated as one-time hardening

The team runs a hardening sprint (clean up dormant accounts, remove excessive admin grants, enforce MFA, tune conditional access), declares the identity posture solved, and stops baselining. Twelve weeks later, three acquired tenants have been federated, dozens of new OAuth grants are in production, two new admin roles are proliferating, and the posture has drifted off the baseline. The fix is recurring baseline pulls on a defined cadence so drift is visible on the record rather than rediscovered during the next incident.

Findings managed in chat

Identity alerts, identity hygiene findings, and identity-incident post-mortems land in chat threads, slide updates, and one-off SOC tickets. Six months later the audit asks for a lifecycle history per identity finding and the team cannot produce one. The fix is to land every identity finding on a structured operating record with severity, owner, lifecycle state, evidence pointer, and framework mapping, the same way the wider security backlog is managed. The evidence package contract for findings applies to identity findings the same way it applies to application findings.

Two parallel records: ITDR and the rest of security

The identity security team builds a separate platform, the AppSec and vulnerability management teams keep their existing record, and the two drift. Leadership ends up reading two different posture reports that disagree on severity, scope, and prioritisation. The fix is to land ITDR findings on the consolidated security record alongside other findings, with identity-specific tagging rather than a parallel platform that duplicates the lifecycle, exception, and reporting layers.

Phased Rollout

A workable ITDR rollout fits in three phases over a single quarter, with extension into a recurring operating cadence. The aim is to anchor the inventory and detection baseline first, layer in response automation second, and extend into governance and audit-read durability third.

Phase 1: Anchor the identity inventory and detection baseline (weeks 1 to 4)

Inventory the identity surface: enumerate identity providers, directory services, privileged access platforms, SaaS-side directories, cloud IAM, and the non-human identity catalogue (service accounts, OAuth grants, API keys, workload identities). Define the detection baseline that covers credential theft, Kerberos-side attacks, OAuth and federation abuse, MFA bypass, privilege escalation, and non-human identity abuse. Stand up the highest-impact detection content first (federation trust changes, golden and silver ticket indicators, anomalous OAuth grants, MFA bombing, dormant privileged account reactivation). Land every alert and every identity hygiene finding on the security operating record with severity calibration, owner, lifecycle, and evidence binding.

Phase 2: Wire response automation (weeks 5 to 8)

Build the named response playbooks: session revocation, conditional access tightening, MFA re-enrolment, OAuth grant revocation, refresh token invalidation, account quarantine, vault credential rotation, non-human credential rotation, group membership freeze, and federation trust suspension. Wire each playbook to the corresponding detection content with a named approver, a named expected outcome, and a structured audit trail. Run the playbooks against a small set of test detections to calibrate the response shape before turning automation loose on production.

Phase 3: Extend governance and audit-read durability (weeks 9 to 12)

Map ITDR findings to ISO 27001 Annex A controls (5.15 to 5.18, 8.5, 8.7, 8.8, 8.15, 8.16), SOC 2 trust services criteria (CC6.1, CC6.2, CC6.3, CC6.6, CC7.1, CC7.2), NIST 800-53 controls (AC-2 through AC-6, IA-2 through IA-8, AU-2, AU-6, SI-4), PCI DSS Requirements 7 and 8 and 10, and NIST CSF 2.0 PROTECT.AA, DETECT.CM, RESPOND.CO, RESPOND.MI. Stand up the identity exception register with named owner, basis, scope, expiry, and review trigger. Wire the ITDR record into the wider GRC posture and the leadership reporting cadence. Define the recurring operating cycle (weekly inventory review, monthly baseline pull, quarterly detection content review, annual framework mapping refresh) and document the operating model alongside the wider security programme.

Recurring operating cadence (continuous)

Weekly: review new identities entering the inventory, triage open identity alerts, review identity-incident playbook executions. Monthly: refresh the baseline pull, review detection content quality (false positive rate, time to alert, time to response), review open exceptions for expiry. Quarterly: refresh the access review on privileged roles and OAuth grants, refresh the non-human identity inventory, run identity-attack tabletop on a rotating scenario (kerberoasting, golden ticket, OAuth token theft, MFA bombing, federation trust manipulation). Annually: refresh the framework mapping, refresh the identity programme strategy, refresh the detection content against current attacker tradecraft, refresh the leadership reporting cadence.

Audit-Read Shape of an ITDR Operating Record

What an auditor, regulator, cyber insurance underwriter, customer security review team, or board-level stakeholder expects to see when they read the identity posture and the identity-incident record has a recurring shape. Programmes that pre-build the read save the cycle of post-hoc evidence assembly.

Identity inventory. Every human and non-human identity, with owner, lifecycle stage, surface class (on-prem directory, cloud identity provider, federated tenant, SaaS-side directory, cloud IAM principal, workload identity, OAuth grant), privilege level, group membership, MFA state, and last authentication.
Baseline policy. The standing baseline against the identity posture rules (orphaned, dormant, over-privileged, missing MFA, weak conditional access, standing privileged session, OAuth excess scope, non-rotated non-human credential, federation trust review, directory misconfiguration) with the per-rule configuration the programme considers compliant.
Detection content catalogue. The named detection content the programme runs across the identity surface, with the attack class each detection covers, the source telemetry, the response action, and the named approver.
Per-incident response record. Each identity incident with the detection that triggered it, the response action taken, the timestamp, the actor, the outcome, the after-action review, and the corrective findings opened on the identity posture.
Identity exception register. Every accepted risk on the identity surface (a residual standing privileged session, an over-privileged service account pending rotation, a dormant account pending offboarding, a federation trust under review) with named owner, business justification, scope, expiry date, review trigger, and recurring review cadence.
Framework mapping. Every identity finding tagged with the relevant ISO 27001 Annex A entry, SOC 2 trust services criterion, NIST 800-53 control, PCI DSS Requirement, and NIST CSF 2.0 category, so the audit-read collapses cleanly across several frameworks.
Activity record. Every state change on the identity posture record (inventory edit, baseline pull, finding open or close, exception grant or expiry, framework remap, access change) with actor and timestamp.
Leadership read. Period-over-period identity posture, top-risk identities, exception expiry pipeline, identity-incident count by class, mean time to detect and respond on identity incidents, and the planned remediation cadence as a single recurring report.

How SecPortal Reads Against the ITDR Operating Record

Identity programmes succeed or fail on the recordkeeping. The inventory edit, the baseline pull, the identity detection alert, the response action, the access review, the exception decision, the framework mapping, and the owner field all need to live on the same record so the identity queue, the leadership dashboard, and the audit read collapse into one query rather than into a multi-tool reconciliation.

SecPortal does not market itself as a dedicated ITDR platform with native identity provider connectors, real-time identity event streaming, directory service detection content, OAuth and session telemetry ingestion, or behavioural analytics on identity activity. It does provide the consolidated operating record an internal security, identity, SOC, AppSec, vulnerability management, or GRC team uses to track findings (including ITDR-side findings imported from a dedicated ITDR platform, an XDR with identity content, a SIEM with identity rules, an identity posture assessment, a third-party identity security audit, or a manual identity review). Engagement management captures each identity assessment, identity-incident response, or recurring identity review as an engagement record so the inventory, baseline, findings, and lifecycle live together. Findings management captures identity findings under a unified schema with CVSS 3.1 calibration and lifecycle tracking. Bulk finding import ingests CSV exports of identity findings from a dedicated ITDR platform, from an XDR with identity content, from a SIEM with identity rules, or from a third-party identity security audit so the identity backlog lands alongside the wider security backlog. Document management holds the identity inventory snapshot, the identity policy artefacts, the identity-incident after-action records, the access-review records, and the OAuth grant inventory snapshots the programme produces. The activity log records every state change on the identity posture record for audit-read durability and exports to CSV. Compliance tracking maps identity findings to ISO 27001 Annex A 5.15 to 5.18 and 8.5 to 8.8 and 8.15 to 8.16, SOC 2 CC6.1 to CC6.3 and CC6.6 and CC7.1 to CC7.2, NIST 800-53 AC-2 through AC-6 and IA-2 through IA-8 and AU-2 and AU-6 and SI-4, PCI DSS Requirements 7 and 8 and 10, and NIST CSF 2.0 PROTECT.AA and DETECT.CM and RESPOND.CO and RESPOND.MI on the finding itself. Team management with RBAC scopes who can read, edit, and approve ITDR-derived findings. MFA enforcement on the workspace protects the operating record the programme depends on. AI report generation produces leadership summaries from the underlying record.

Programmes evaluating dedicated ITDR platforms should benchmark coverage of their identity portfolio (on-prem directory, cloud identity provider, federated tenants, SaaS-side directories, non-human identity inventory, privileged access platform) against the named ITDR vendors, then use SecPortal as the consolidated operating record that holds the resulting findings alongside the wider security backlog. For buyer-side context on the wider Zero Trust strategy the identity layer fits inside, the Zero Trust Architecture implementation guide covers the Identity pillar in the context of the wider five-pillar model. For the audit-read durability discipline the wider security record depends on, the audit evidence half-life research covers how evidence decays without recurring review.

Roles and the ITDR Read

A working ITDR record reads differently for the roles that consume it. The same record, several reads.

CISOs and security leaders

Read the leadership view: identity portfolio shape, top-risk identities, exception expiry pipeline, identity-incident count by class, mean time to detect and respond on identity incidents, period-over-period posture trend, planned remediation cadence, and the identity-related programme spend justification.

SOC analysts

Read the detection and response view: open identity alerts by detection content, response action history per alert, identity context attached to each alert, the named playbook bound to the detection, and the after-action review queue for closed incidents.

Identity and security engineering teams

Read the engineering view: detection content quality (false positive rate, coverage gap, time to alert), inventory accuracy by surface, baseline drift since last pull, non-human identity rotation pipeline, and federation trust review queue.

GRC and compliance teams

Read the framework view: ISO 27001 Annex A access-control coverage, SOC 2 CC6 logical-access controls, NIST 800-53 AC and IA family control coverage, PCI DSS Requirement 7 and 8 and 10 coverage, identity-related exception register state, and the audit-evidence pack for the upcoming external review.

AppSec teams

Read the application-side surface: which applications federate to which identity provider, which OAuth grants are in production, which SaaS-side directories carry application-specific identities, and the identity-handling code paths the AppSec backlog covers.

Vulnerability management teams

Read the lifecycle view: identity-side findings alongside non-identity findings on the same operating record, with severity calibration, owner routing, SLA tracking, retest discipline, and evidence binding so the identity surface does not drift away from the wider security backlog.

Scope and Limitations

This guide describes the operating shape of Identity Threat Detection and Response as it is consumed in mainstream enterprise programmes. The vendor landscape evolves rapidly: identity provider connector coverage, directory service detection depth, OAuth and session telemetry breadth, non-human identity discovery, behavioural analytics, and bundled posture-management capabilities shift between releases. Specific feature claims, supported providers, and the precision of named detection content should be verified against current vendor documentation and against benchmark exercises on the team's own identity portfolio.

ITDR is a detection and response record, not an authentication control. Programmes that adopt ITDR as a substitute for the identity provider lose the authoritative authentication layer; programmes that adopt ITDR as a substitute for PAM lose the privileged-session control layer; programmes that adopt ITDR as a substitute for the SIEM or XDR lose the wider correlation across endpoint, network, and identity; programmes that adopt ITDR as a substitute for the wider GRC programme lose the cross-framework crosswalk discipline. Programmes that adopt ITDR as the identity detection and response leg alongside IAM, PAM, the SIEM or XDR, an ISPM record, a CIEM record, and the wider GRC posture, with disciplined inventory reconciliation, detection content review, response playbook rehearsal, exception lifecycle, quarterly access reviews, and annual framework mapping reviews, are the ones that see durable operating value.

Run identity findings on SecPortal

Stand up the operating record in under two minutes. Free plan available, no credit card required.

Get Started Free SecPortal for internal security teams