ISPM (Identity Security Posture Management)

Identity Security Posture Management (ISPM) continuously inventories an organization's identity systems and accounts and evaluates their configuration and entitlements against a security baseline, so that weaknesses are found and fixed before an attacker uses them. It covers the settings of identity providers, directories and federation trusts, the state of human, service and agent accounts, and the paths by which ordinary access can lead to administrative control. Where Identity Threat Detection and Response (ITDR) notices someone walking through an unlocked door, ISPM is the practice of finding the doors left unlocked, and of making sure each one has an owner who locks it.

What Gets Checked

The identity systems themselves come first, because a weak setting there weakens every account at once. That means federation trusts nobody uses any more, token-signing certificates close to expiry or held outside protected storage, legacy protocols such as basic authentication or NTLM still enabled, token and session lifetimes far longer than policy says, and conditional access rules with exclusions nobody can explain. Break-glass accounts belong on the list too: they should exist, be excluded from the rules that could lock everyone out, and be protected in a way that makes their use conspicuous.

Accounts are the second layer. A posture check finds privileged accounts without phishing-resistant multi-factor authentication (MFA), accounts that have not signed in for months, accounts whose owner has left, shared accounts, service accounts that can sign in interactively, and API keys and client secrets that were never rotated. Workload and machine identities usually outnumber people and fare worst on every one of these, because nobody's leaver process covers them. Where an AI agent registry exists, ISPM can check agents against it directly, finding agents with broader scopes than their task, agent credentials with no registered owner, and registered agents that no longer run.

Entitlements are the third. Counting excessive permissions is less useful than following them: a helpdesk group that can reset passwords of a group that owns a server that holds an administrator's session is a path to administrative control that no single permission reveals. ISPM tools model these relationships as a graph and report the shortest paths from ordinary accounts to privileged ones, which is where remediation pays most. In cloud platforms the same analysis over roles and policies is the work of Cloud Infrastructure Entitlement Management (CIEM), and an ISPM deployment should take CIEM's findings rather than repeat them.

The Baseline Is a Decision

A finding is only a deviation from a baseline, so the baseline decides what ISPM reports. Published ones are the starting point: the Center for Internet Security (CIS) Benchmarks for directories and operating systems, and the Secure Cloud Business Applications (SCuBA) baselines that the US Cybersecurity and Infrastructure Security Agency (CISA) publishes for cloud office suites and their identity settings. None of them fits an organization unchanged. Some settings conflict with an application that cannot be replaced this year, and some are weaker than the organization's own policy.

What makes a baseline workable is an exception register. Each deviation that is accepted rather than fixed gets an owner, a reason and an expiry date, and ISPM reports it as accepted until the date passes. Without that, the same hundred findings reappear every week, the team learns to ignore the report, and the one new finding that matters is lost among them. With it, the report shows what changed, and an auditor can see that every open weakness was a decision someone made.

Identity estateSIEMITDRISPMSOARIdentity ProviderDirectoryCloud IAM logscorrelationidentity eventsposture dataalertincidentfindingrevoke, disable
ISPM reads the identity estate's configuration rather than its event stream, which is why it sits beside the log pipeline rather than behind it, and its findings reach the same response layer a detection does.
Identity estateAI agent registryISPMSOARDiscoveryIdentity inventoryBaseline evaluationRanked findings identities, settingsevaluateddrift, excessconfigurationagent inventoryremediation
Configuration, not events: ISPM discovers which identity systems and accounts exist, evaluates their settings against a baseline, and produces a ranked finding with an owner and a remediation rather than an alert to triage.

From Finding to Fix

ISPM does not fix anything by itself, and the gap between a report and a changed setting is where most deployments stall. Each finding needs to reach the team that owns the system, which is often not the IAM team: an application team owns its service accounts, a platform team its cloud roles. Ranking by exploitability does more than ranking by count. A dormant account with administrative rights on a path to the directory outranks a thousand dormant accounts with none.

Some fixes can be automated, and the rules for doing so are the ones described under SOAR: disabling a dormant account with no rights is reversible and can run unattended, while removing a federation trust or rotating a secret that production depends on waits for its owner. A fix made in a target system that identity governance manages has to go through governance as well, or the next reconciliation restores the access. Drift is the other half. A setting fixed today can be changed back tomorrow, so ISPM re-evaluates continuously and re-opens findings. Where the identity provider's configuration is kept as code, as Policy as Code argues for authorization policy, drift becomes a comparison between the repository and the deployed state, and a fix becomes a reviewed change.

The useful measures are the time from finding to fix per finding class and the number of open paths to privileged access over time. Both show an organization whether its identity posture is improving. The raw count of findings mostly shows how many checks the tool runs.

Where ISPM Sits

ISPM evaluates state; the neighbouring disciplines handle events and entitlements. The SIEM records the configuration changes as they happen and keeps them for audit, while ISPM judges whether the configuration those changes produced is acceptable. ITDR detects a weakness being used, and ISPM finds it before it is. Identity governance decides which access people and workloads should have and certifies it; ISPM checks how securely that access is implemented, for example whether the privileged accounts governance approved are protected by the factors policy requires. Privileged access management is itself a target of posture checks, from vault coverage to whether session recording is enabled on the systems that need it.

In the NIST Cybersecurity Framework (CSF) 2.0, this places ISPM in the Identify function, as asset inventory and risk assessment for identity systems, and in the continuous monitoring part of Detect. It gives the Govern function evidence that identity policy is applied as written, which is also what an auditor wants to see: not that a policy exists, but which systems deviate from it and who accepted each deviation.