Identity security posture management (ISPM) and identity threat detection and response (ITDR) are often sold together and confused, yet one fixes the weaknesses attackers would use and the other catches attackers using them. ISPM continuously assesses identity configuration and hygiene across directories, identity providers, cloud, SaaS and non-human identities, then drives remediation. ITDR watches identity activity for signs of attack and contains compromised identities. This guide gives the short answer, a side-by-side comparison, when to lead with each, the trade-offs, how the two feed each other and the mistakes that leave gaps between them. It is for identity security leads, SOC managers and architects deciding where to invest and how to split ownership.
Key takeaways
- ISPM is preventive, ITDR is detective and responsive. ISPM asks "what could an attacker abuse?"; ITDR asks "is an attacker abusing it now?".
- They work on different data. ISPM reads configuration, entitlements and account state; ITDR reads sign-in, ticket, token and audit events in near real time.
- Owners differ. ISPM findings go to identity and platform owners with remediation deadlines; ITDR alerts go to the SOC with response playbooks.
- Each makes the other better. Posture context (which accounts are privileged, which lack MFA) sharpens detection priority; detections reveal which posture gaps attackers actually use.
- Start where the gap is largest. Weak hygiene with no baseline points to ISPM first; a mature baseline with poor identity telemetry in the SOC points to ITDR first. Most organisations need both within a year.
The short answer
Choose ISPM when the question is "how exposed are our identities?" and you need an inventory of misconfigurations, excess privilege, missing MFA, dormant accounts and risky non-human identities, with a way to drive them down. Choose ITDR when the question is "would we notice an identity attack and stop it?" and you need detections for password spraying, MFA fatigue, Kerberoasting, token replay and persistence, plus fast containment such as session revocation. In NIST CSF 2.0 terms, ISPM sits mostly in Identify and Protect (ID.RA-01, PR.AA-05, PR.PS-01) and ITDR in Detect and Respond (DE.CM-03, DE.AE-02, RS.MI-01).
The live ISPM Guide and ITDR Guide cover each discipline on its own. This page concentrates on the boundary between them.
ISPM and ITDR side by side
| Dimension | ISPM | ITDR |
|---|---|---|
| Core question | What weaknesses exist in our identity estate? | Is someone attacking or misusing an identity right now? |
| Timing | Before an attack; continuous assessment and drift detection | During and after an attack; near real-time |
| Primary data | Directory objects, IdP and tenant settings, role assignments, app registrations, credential age, MFA enrolment, entitlements | Authentication logs, Kerberos and NTLM events, token issuance, audit logs, admin changes, NHI activity |
| Typical outputs | Prioritised findings, posture score, attack paths, remediation tickets | Alerts, incidents, automated containment actions |
| Main users | IAM team, AD and cloud platform owners, NHI owners, GRC | SOC analysts, incident responders, threat hunters |
| Success measure | Fewer high-risk findings, shorter time to remediate, less standing privilege | Shorter time to detect and contain, coverage of priority techniques |
| Failure mode | Thousands of findings nobody owns | Alert noise without identity context, or alerts nobody can act on |
| Response action | Change configuration, remove access, enforce MFA, rotate credentials | Disable account, revoke sessions and tokens, block source, remove persistence |
| NIST SP 800-53 Rev. 5 | AC-2 Account Management, AC-6 Least Privilege, CM-6 Configuration Settings, RA-3 Risk Assessment | SI-4 System Monitoring, AC-2(12) Account Monitoring for Atypical Usage, AU-6, IR-4 Incident Handling |
What each one actually checks
The clearest way to see the split is to take one attack technique and ask what each discipline contributes. Posture removes the precondition; detection catches the attempt when the precondition still exists.
| Technique (ATT&CK) | ISPM finds the precondition | ITDR detects the attempt |
|---|---|---|
| T1110.003 Password Spraying | Accounts without MFA; legacy authentication enabled; weak password policy | Many accounts failing from one source; low-and-slow failures across the tenant |
| T1621 Multi-Factor Authentication Request Generation | Users on push approval without number matching; no phishing-resistant MFA for admins | Bursts of denied push requests followed by an approval |
| T1558.003 Kerberoasting | User accounts with SPNs, weak or old passwords, RC4 allowed | Event 4769 service ticket requests with encryption type 0x17 (RC4-HMAC) or one account requesting many tickets |
| T1003.006 DCSync | Non-domain-controller principals holding directory replication rights | Replication requests from hosts that are not domain controllers |
| T1606.002 SAML Tokens | Token-signing keys exportable or poorly protected; unexpected federation trusts | Sign-ins with SAML tokens that have no matching IdP authentication |
| T1484.002 Trust Modification | Inventory of domain and federation trusts with owners | New or changed federation trusts and domain authentication settings |
| T1098.001 Additional Cloud Credentials | App registrations and service principals with long-lived secrets and high privilege | New secret or certificate added to an existing application |
| T1528 Steal Application Access Token | Users allowed to consent to high-privilege OAuth scopes | New consent grants with sensitive scopes; tokens used from new infrastructure |
| T1078.004 Cloud Accounts | Dormant accounts, leavers still enabled, unrotated access keys | Dormant identities suddenly active; keys used from unfamiliar locations |
Microsoft's documentation for event 4769 recommends monitoring for any ticket encryption type other than 0x11 and 0x12 (AES) on modern systems, which is a good example of the split: ISPM removes RC4 support and fixes weak service account passwords, ITDR alerts when RC4 tickets still appear. See the Kerberoasting and AS-REP Roasting Defence Guide and the Golden Ticket, Silver Ticket and DCSync Guide.
Government guidance follows the same split. The NSA and CISA advisory on the top ten cybersecurity misconfigurations (October 2023) lists posture issues such as default configurations, improper separation of user and administrator privilege, weak or misconfigured MFA methods, insufficient access control lists and poor credential hygiene. The joint guidance on detecting and mitigating Active Directory compromises, led by Australia's ASD ACSC with CISA, NSA, the Canadian Centre for Cyber Security, the UK NCSC and NCSC New Zealand, pairs each of 17 common AD techniques with both mitigations and detections.
When to lead with each
Lead with ISPM when
- You do not know your identity estate: no reliable count of admins, service accounts, app registrations or federation trusts. Detection without that context cannot tell a privileged account from a test account.
- Hygiene is visibly poor: MFA gaps, legacy authentication, standing domain or global admins, Kerberoastable accounts. Fixing these removes whole classes of alerts.
- NHIs are unmanaged: service accounts, keys and OAuth apps without owners. See the Service Account Security Guide.
- You must evidence compliance: posture reports map directly to access control and configuration requirements.
Lead with ITDR when
- The SOC cannot see identity attacks: IdP, directory and cloud audit logs are not collected or not correlated.
- You have had identity-led incidents: help desk social engineering, session theft or OAuth abuse. See the Identity Incident Response Playbook.
- Posture work is under way but slow: remediation of legacy directories can take years; detection covers the gap meanwhile.
- Containment is manual and slow: no tested way to revoke all sessions and tokens for an identity across IdP, cloud and SaaS.
Small and large organisations
A small organisation on one cloud IdP with a modest directory can often get most ISPM value from the IdP's built-in posture score and baseline checks, such as CISA's SCuBA secure configuration baselines for Microsoft 365 and Google Workspace, and most ITDR value from the IdP's risk detections sent to a managed SOC. A large hybrid estate with on-premises Active Directory, several clouds, many SaaS tenants and thousands of NHIs usually needs dedicated tooling for both, plus attack path analysis across systems. See the Identity Attack Paths Guide.
Security trade-offs
- Coverage versus depth: ISPM gains value from breadth (every directory, tenant and SaaS app); ITDR gains value from depth on the systems attackers target first (domain controllers, IdPs, federation, privileged roles). Do not delay detection on tier zero waiting for full posture coverage.
- Read-only versus write access: ISPM mostly needs read access to configuration. ITDR with automated response needs rights to disable accounts and revoke sessions, which makes the ITDR tool itself a privileged identity that must be protected and monitored.
- Noise: ISPM without prioritisation produces backlogs; ITDR without baselines produces false positives on service accounts and admins with unusual but legitimate patterns. Both need identity context: privilege tier, owner, expected behaviour.
- Automated fixes versus change control: auto-remediating posture (removing a role, disabling an account) can break production; prefer automation for safe, reversible fixes and tickets for the rest. Automated containment in ITDR is justified for high-confidence detections on high-risk identities.
- Converged products: many tools offer both. Convergence helps when findings and detections share one identity graph; it hurts when one half is shallow. Evaluate each half against your own technique list. See the IVIP and ISPM Buyer's Guide and the ITDR Buyer's Guide.
How ISPM and ITDR work together
- Share one identity inventory: both rely on knowing every identity, its owner, privilege tier and normal behaviour. Identity visibility and intelligence platforms build this layer. See the IVIP Guide.
- Use posture to rank alerts: a risky sign-in on an admin without phishing-resistant MFA, or on a service account with domain admin rights, should outrank the same signal on a standard user.
- Turn detections into posture fixes: after each identity incident, ask which precondition the attacker used and add or tighten the matching posture check, then track it to closure (CSF ID.IM-01).
- Watch posture drift as a detection: a new federation trust, a new admin role assignment or MFA disabled for a privileged account is both a posture regression and a possible attack. Route these to the SOC in real time, not to the next weekly report.
- Propagate response: ITDR containment should reach applications quickly. The OpenID Shared Signals Framework with its CAEP and RISC profiles lets an IdP or ITDR tool tell relying parties that a session was revoked or credentials changed; the OpenID Foundation announced approval of three Shared Signals final specifications in September 2025. See the Shared Signals Framework Guide.
- Validate both: test detections with safe emulation of the techniques above and check that posture findings close. See ITDR validation.
Lessons from incidents
In the Microsoft Midnight Blizzard breach, a low-volume password spray reached a forgotten test account without MFA, and the attacker then abused a legacy OAuth application with elevated access and granted itself broad mailbox permissions. Both halves were missing: posture had not brought the test tenant and its app permissions under production controls, and detection did not alert on new app creation or consent grants. In the Snowflake breach, infostealer credentials opened about 165 customer accounts that had no MFA, unrotated credentials and no network allow lists. Every root cause there is a posture finding an ISPM programme would have raised.
Detection and measurement
| Area | Metric | What good looks like |
|---|---|---|
| ISPM | Critical and high posture findings open, and median days to remediate | Falling trend; critical findings closed within an agreed deadline |
| ISPM | Privileged identities without phishing-resistant MFA | Zero for tier zero, trending to zero for all admins |
| ISPM | NHIs with an owner and credentials younger than the rotation policy | Rising percentage, reported by system |
| ITDR | Priority identity techniques with a tested detection | All techniques in the mapping table covered and validated |
| ITDR | Mean time to contain a compromised identity (sessions and tokens revoked) | Minutes for high-confidence alerts with automated containment |
| Both | Incidents whose precondition was already a known open posture finding | Falling; each one triggers a review of prioritisation |
Framework mapping
| Framework | ISPM | ITDR |
|---|---|---|
| NIST CSF 2.0 | ID.RA-01, PR.AA-01, PR.AA-05, PR.PS-01 | DE.CM-03, DE.AE-02, RS.MI-01, RS.AN-03 |
| NIST SP 800-53 Rev. 5 | AC-2, AC-6, CM-6, CM-8, RA-3 | SI-4, AC-2(12), AU-6, IR-4, IR-5 |
| NIST SP 800-61 Rev. 3 | Preparation activities that reduce incident likelihood | Detection, response and recovery activities |
| ISO/IEC 27001:2022 Annex A | 5.15 Access control, 5.18 Access rights, 8.2 Privileged access rights, 8.9 Configuration management | 8.15 Logging, 8.16 Monitoring activities, 5.26 Response to information security incidents |
| CIS Controls v8.1 | Control 5 Account Management, Control 6 Access Control Management | Control 8 Audit Log Management, Control 17 Incident Response Management |
Common mistakes
- Buying ITDR to avoid fixing posture: detection on an estate full of Kerberoastable accounts and MFA gaps produces endless alerts and still loses to a quiet attacker.
- Running ISPM as a report, not a programme: findings without owners, deadlines and verification change nothing. Route them to the system owners and track closure.
- Leaving non-human identities out of both: service accounts, app registrations and API keys are posture findings and detection subjects. Baseline their behaviour as well as their configuration.
- Ignoring non-production tenants: test and legacy tenants sit outside both posture scans and detections until an attacker finds them, as in Midnight Blizzard.
- Containment that stops at the password: resetting a password leaves stolen sessions, refresh tokens, added MFA methods and OAuth grants in place. Revoke sessions and tokens and remove persistence.
- Two teams, no feedback loop: the SOC never tells the IAM team which gaps attackers used, and the IAM team never tells the SOC which accounts are tier zero.
Practitioner checklist
- Agree the scope for both: every directory, IdP, cloud, SaaS tenant and NHI source, including test and legacy tenants.
- Build one identity inventory with owner, privilege tier and expected behaviour, shared by ISPM and ITDR.
- Map your priority identity techniques to a posture check and a detection, using the table above as a start.
- Remove preconditions first on tier zero: phishing-resistant MFA for admins, no RC4, no stray replication rights, protected token-signing keys.
- Send posture regressions on privileged identities and federation settings to the SOC in real time.
- Write and test containment that revokes sessions and tokens and removes persistence, not just resets passwords.
- Feed every identity incident back into posture checks and track the fix to closure.
- Report the metrics above monthly, separately for ISPM and ITDR, plus the shared "known precondition" measure.
Standards and references
- CISA and partners: Detecting and Mitigating Active Directory Compromises
- NSA and CISA: Top Ten Cybersecurity Misconfigurations
- CISA: Secure Cloud Business Applications (SCuBA) Project
- NIST: SP 800-61 Rev. 3 Incident Response Recommendations
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- OpenID Foundation: Shared Signals Working Group (SSF, CAEP, RISC)
- MITRE ATT&CK: Kerberoasting
- Microsoft Learn: Event 4769 A Kerberos service ticket was requested
Related NHI Mgmt Group resources: ISPM Guide · ITDR Guide · Identity Visibility, Posture and Threat Detection Guide · Identity Attack Paths Guide