Identity Visibility, Posture and Threat Detection Guide: ISPM, ITDR and Identity Analytics

Attackers increasingly log in rather than break in, and most organisations still cannot answer three basic questions: which identities exist, which of them are exposed, and which are being misused right now. Identity visibility, posture and threat detection is the discipline that answers them. It joins three practices that grew up separately: identity visibility and intelligence (a unified inventory of human and non-human identities and what they can reach), identity security posture management or ISPM (finding and fixing weak configuration before it is exploited), and identity threat detection and response or ITDR (catching and containing attacks that use valid identities). This guide is the overview for the whole field: concepts, threats, controls by maturity, ownership and framework mapping. It is written for identity, SOC and security architecture teams, and it ends with a map of every NHI Mgmt Group guide in this category.

Key takeaways

• Visibility comes first. Posture checks and detections are only as good as the inventory behind them, and that inventory must include service accounts, OAuth apps, API keys, workloads and AI agents, not just employees.
• Posture prevents, detection catches. ISPM removes the admin without MFA or the dormant privileged account before it is used; ITDR spots the spray, the forged ticket or the replayed token when prevention fails.
• Identity infrastructure is tier zero. Domain controllers, identity providers, federation trusts and token-signing keys need the strongest monitoring, because control of them means control of every account.
• Response means revoking, not isolating. Containing an identity attack requires revoking sessions and tokens, resetting credentials, removing added MFA methods and app credentials, and reviewing federation, not just reimaging a laptop.
• Logging decides what you can see. The State Department detected Storm-0558 through premium mail audit logs; organisations without those logs could not see the same activity.

What the field covers

The category spans the full loop from knowing what exists to responding when it is abused:

• Identity visibility and intelligence: correlating accounts across directories (Active Directory, Entra ID, Okta, Google), cloud IAM, SaaS, HR and secrets stores into one graph of identities, owners, entitlements and activity. Analysts call platforms that do this identity visibility and intelligence platforms (IVIP). See the IVIP Guide.
• Identity security posture management: continuous assessment of identity configuration and hygiene, with prioritised remediation. See the ISPM Guide.
• Attack path analysis: modelling chains of group memberships, delegations, ACLs and role assignments that lead from an ordinary account to tier zero. See the Identity Attack Paths Guide.
• Identity threat detection and response: detections across directories, IdPs, cloud and SaaS, plus identity-specific response actions. See the ITDR Guide.
• Behavioural analytics and insider risk: baselining normal behaviour for people, service accounts and agents and flagging deviation, including deliberate misuse by insiders.
• Signal sharing and measurement: exchanging risk events between systems, and reporting identity risk through metrics leadership can act on.

It borrows from adjacent categories: SIEM and detection engineering supply the pipeline, IGA supplies ownership and access review, PAM supplies privileged session control. This category is where identity context meets security operations.

Core concepts

Visibility, posture and detection compared

Tier zero and blast radius

Tier zero is the set of assets whose compromise gives control of the identity estate: domain controllers, AD CS, Entra ID Connect or equivalent sync servers, identity provider admin roles, federation trusts and token-signing keys, and the accounts that administer them. Posture and detection effort should be weighted to tier zero first, then by how much each identity can reach (blast radius), how exposed it is (internet-facing, third-party, federated) and how exploitable the weakness is.

Human and non-human identities

Non-human identities usually outnumber people and behave very predictably, which makes them easier to baseline: a service account that has only ever authenticated from two hosts should never sign in interactively from a new country. They are also often exempt from MFA and conditional access, have no named owner and hold long-lived credentials, so they are prime posture findings. See the Service Account Security Guide.

Signals and sharing

Detection improves when systems share what they see. The OpenID Shared Signals Framework 1.0 (August 2025) defines how a transmitter sends Security Event Tokens (RFC 8417) to receivers by push (RFC 8935) or poll (RFC 8936). CAEP carries session and credential changes, and RISC carries account-level risk events, so an IdP can tell an application to end a session the moment an account is flagged. See the Shared Signals Framework Guide.

What identity response looks like

Endpoint response isolates a host; identity response has to remove every way back in. A complete containment for a compromised account covers:

• Sessions and tokens: revoke all refresh tokens and active sessions at the IdP, and in SaaS applications that keep their own sessions.
• Credentials: reset the password, and for service accounts rotate every key, secret and certificate the identity holds.
• Persistence: remove MFA methods, devices, mailbox rules, OAuth consents and app credentials added during the attacker's window.
• Privilege and trust: review role assignments, group changes and any new federated domain or trust made by the account.
• Kerberos: after a domain compromise, reset the krbtgt account password twice, allowing replication between resets, to invalidate forged tickets.

Main threats

The Windows event IDs above are Security log events (4624 logon, 4625 failed logon, 4662 operation on a directory object, 4768 TGT request, 4769 service ticket request, 4771 Kerberos pre-authentication failure); they require the matching advanced audit policy subcategories to be enabled on domain controllers.

Incidents in this category show the pattern. The Midnight Blizzard breach began with a slow password spray through residential proxies against a test tenant account without MFA, then abused a legacy OAuth app; Microsoft found it by reviewing Exchange Web Services activity and audit logs. In the MGM Resorts breach the attackers claimed administrator access to the Okta and Azure tenants after a help desk call, turning the identity provider into their control plane.

Key controls by maturity

Foundation: see and fix the obvious

• Collect the logs: IdP sign-in and audit logs, domain controller Security logs with Kerberos and directory service auditing enabled, cloud control-plane logs (for example AWS CloudTrail) and SaaS audit logs, retained long enough to investigate (at least 90 days hot).
• Build the inventory: every human and non-human account, its owner, its privileged roles and its last use. Use the Service Account Inventory Template to start.
• Fix the high-value posture gaps: phishing-resistant MFA for administrators, legacy authentication blocked, dormant and leaver accounts disabled, standing Domain and Global Admins reduced.
• Baseline detections: password spraying, MFA fatigue, impossible travel, new MFA method followed by sensitive activity, privileged role assignment.

Intermediate: continuous posture and identity-aware detection

• Continuous ISPM: scheduled checks across tenants and directories, findings routed to named owners with deadlines, and re-verification once fixed.
• Attack path reduction: map paths to tier zero with graph tools and remove choke points such as excessive ACLs, unconstrained delegation and vulnerable AD CS templates. See the BloodHound and Active Directory Attack Path Guide.
• Directory attack detections: Kerberoasting, DCSync, golden and silver tickets, pass-the-hash.
• NHI behaviour baselines: alert when a service account, API key or app registration is used from a new host, network or in a new way, or when a new secret is added to it.
• Playbooks: tested response for compromised user, compromised service account and compromised OAuth app. See the Identity Incident Response Playbook.

Advanced: correlated, automated and shared

• Unified identity graph: human, machine and agent identities correlated with entitlements and activity, so a detection carries blast-radius context.
• Automated containment: high-confidence detections trigger session revocation, token revocation and account disablement through the IdP API, with human approval for tier-zero accounts.
• Signal sharing: CAEP and RISC between IdP, SaaS and endpoint tools so risk changes propagate in near real time.
• Deception: honey accounts and decoy credentials that should never be used, alerting on any authentication attempt.
• Agent monitoring: AI agents baselined as identities in their own right. See the AI Agent Behaviour Baselining and Anomaly Detection Guide.

Implementing the programme

1. Scope tier zero: list the systems and accounts that control identity, and confirm their logs reach the SIEM.
2. Connect sources read-only: start ISPM and visibility tooling with read-only API permissions; review what the tool's own service principal can do, since it becomes a high-value NHI.
3. Run a first assessment: baseline the findings count by severity and agree remediation owners before publishing results.
4. Deploy detections in alert-only mode: tune for two to four weeks against known-benign activity (vulnerability scanners, backup service accounts, admin jump hosts) before any automated response.
5. Enable automated response in rings: standard users first, then service accounts with known owners, never tier zero without approval steps.
6. Roll back: keep each automated action reversible (disable, not delete; revoke sessions, not remove accounts) and document how to re-enable an account wrongly contained.
7. Review quarterly: new attack techniques, new identity sources, metrics against targets.

Choosing an approach

• Native tools versus a dedicated platform: IdP and cloud-native protection (risk-based sign-in, directory threat sensors) covers a single ecosystem well; a separate ISPM or ITDR platform earns its place when identities span several directories, clouds and SaaS. See the ITDR Buyer's Guide and the IVIP and ISPM Buyer's Guide.
• SIEM rules versus specialist detections: SIEM rules suit teams with detection engineering capacity; specialist tools ship tuned directory and token detections. Most organisations combine both.
• Small versus large organisations: a small organisation on a single IdP can get far with native risk policies, a monthly posture review and five or six well-tuned alerts. Large hybrid estates need continuous ISPM, attack path analysis and a dedicated identity detection owner in the SOC.

Detection and measurement

Metrics that show the programme works (see the Identity Security Metrics Guide for definitions):

• Inventory coverage: percentage of identity sources connected, and percentage of NHIs with a named owner.
• Critical posture findings open: count and age of critical findings on tier-zero and privileged identities.
• Attack paths to tier zero: number of distinct paths, trending down.
• Mean time to detect identity compromise: from first malicious authentication to alert, measured through incidents and purple-team exercises.
• Mean time to contain: from alert to all sessions and tokens revoked.
• Detection coverage: share of the ATT&CK techniques in the threat table with a tested detection.

Common failure patterns

• Human-only inventory: service accounts, OAuth apps and API keys missing from the graph, so the most abused identities are invisible.
• Findings without owners: thousands of posture findings that nobody is assigned to fix, so the score never moves.
• Logs not collected or not licensed: the evidence needed exists only at a higher licence tier or is never forwarded. The Storm-0558 key breach was detected through a custom alert on the MailItemsAccessed audit log that many customers did not have.
• Password reset as the whole response: stolen sessions and refresh tokens, added MFA methods and new app credentials survive the reset.
• Untuned alerts: impossible-travel alerts that fire on every VPN egress, teaching analysts to ignore them.
• Exposed security tooling: the ISPM or ITDR platform's own highly privileged service account left with standing write access and no monitoring.

Roles and ownership

Standards and frameworks

Where to go next

New to Identity Visibility, Posture and Threat Detection? These are the foundational guides to read first.

Start here

• IVIP Guide: what identity visibility and intelligence platforms do.
• ISPM Guide: posture checks, prioritisation and running ISPM as a programme.
• Identity Attack Paths Guide: how paths form across AD, cloud and SaaS and how to close them.
• Top 10 Active Directory Security Risks: the most common AD weaknesses and fixes.
• Kerberos Security Guide: Kerberoasting, ticket attacks and detection.
• ITDR Guide: identity detections and response across directories, IdPs, cloud and SaaS.
• Identity Incident Response Playbook: responding to compromised accounts.
• Shared Signals Framework Guide: CAEP and RISC for real-time signal sharing.
• Password Spraying and Credential Stuffing Defence Guide: detecting and stopping password attacks.
• Session Hijacking and Cookie Theft Guide: defending authenticated sessions.
• Top 10 Identity Attacks: the attacks most used against identities.
• Insider Threat and Identity Guide: identity signals of insider risk.

For the analytics and pipeline underneath, see the UEBA Guide and the SIEM Guide.

Browse all Identity Visibility, Posture & Threat Detection guides

Practitioner checklist

• Define tier zero and confirm every tier-zero system sends identity logs to the SIEM.
• Enable Kerberos and directory service auditing on all domain controllers.
• Build one inventory of human and non-human identities with owners and last-use dates.
• Run a posture assessment and assign every critical finding an owner and deadline.
• Map attack paths to tier zero and remove the top choke points.
• Deploy and tune detections for spraying, MFA fatigue, token replay, Kerberoasting and DCSync.
• Baseline service account and app registration behaviour and alert on new credentials.
• Write and test playbooks that revoke sessions and tokens, not just reset passwords.
• Restrict and monitor the privileged service accounts of your own security tools.
• Report the six metrics above to leadership each quarter.

Standards and references

• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-53 Rev. 5
• OpenID Foundation: Shared Signals Framework 1.0
• MITRE ATT&CK: Kerberoasting
• MITRE ATT&CK: DCSync
• MITRE ATT&CK: Valid Accounts
• CISA: Implementing Phishing-Resistant MFA

Related NHI Mgmt Group resources: Authentication Guide · Detection Engineering Guide · Service Account Security Guide · Active Directory and Entra ID Hardening Guide