Identity security posture management (ISPM): a working field guide

DCDaniel C. · Head of Security Operations
Identity & Access Security Operations·11 min read

I inherited an identity attack surface last year that nobody could describe in a single sentence: an Entra tenant, a still-syncing AD forest, Okta for legacy SaaS, 60 unreviewed OAuth grants, and a service-account inventory in a stale spreadsheet. I now ask every ISPM vendor the same thing: which of my standing exposures do you find, and which one do you actually fix?

I inherited an identity attack surface last year that nobody could describe in a single sentence. There was an Entra ID tenant, an on-prem Active Directory (AD) forest still syncing into it, Okta for a handful of legacy SaaS apps, roughly 60 third-party OAuth integrations nobody had reviewed since they were consented, and a service account inventory that lived in a spreadsheet with a last-verified column dated eleven months earlier.

In the vendor conversations that followed, every ISPM rep got the same question from me. Which of my standing exposures does each product find, and which one does it actually fix? Most answered only the first half.

That question now travels into every environment I take over. Identity security posture management (ISPM) is the discipline of finding and shrinking standing identity exposure: the privilege paths, stale identities, over-scoped grants, and long-lived credentials that sit there before an attacker arrives.

It prioritizes that standing attack surface rather than the suspicious activity of an attack already underway, which is Identity Threat Detection and Response (ITDR) territory.

In Brief:

  • ISPM reduces standing exposure; ITDR detects suspicious identity behavior and active abuse. The two overlap in modern product suites, so evaluate the actual coverage rather than the category label.
  • The exposures that matter are boring: Kerberoastable service accounts, service principals holding RoleManagement.ReadWrite.Directory, dormant accounts in sensitive groups, unrotated access keys, legacy auth left turned on, and group ownership chains nobody drew on a whiteboard.
  • Identity graphs show posture by mapping who can reach what, and choke point analysis sets priority.
  • If you run Entra ID P2, a mature Privileged Access Management (PAM) deployment, and modern Identity Governance and Administration (IGA), you may already own overlapping capabilities. Buy only the capability gap.

What ISPM actually manages, and what it doesn't

ISPM is an emerging category of identity security tools and practices focused on continuously identifying identity configuration, entitlement, and exposure risks across an organization's infrastructure. That framing is accurate but not useful on a Tuesday, because it does not settle what belongs in an ISPM program versus a Security Operations Center (SOC).

The working distinction is one of priority: ISPM identifies and ranks the standing conditions that make authentication and privilege abuse easier, such as weak multi-factor authentication (MFA) coverage, excessive privilege scope, stale identities, and long-lived credentials, while runtime identity monitoring watches for abuse in progress.

In practice, vendors bundle parts of both, so the boundary is a way to reason about coverage, not a clean market line. In the 2026 Gartner Hype Cycle for Digital Identity, Identity Visibility and Intelligence Platform (IVIP), ISPM, and ITDR form a see-it, secure-it, stop-it sequence.

Posture concerns standing exposure

This posture-versus-runtime split is the same one I use for cloud, and it holds up: cloud posture management finds the misconfiguration before exploitation, while Cloud Detection and Response (CDR) catches the workload being abused at runtime.

I have sat through cloud demos where a Detections tab turned out to contain misconfiguration counts. Identity vendors do the same thing, and the blurring is worse here, because ITDR products frequently bundle posture hardening inside the detection product.

Hold the line anyway, because the two disciplines have different owners and operating cadences, which produce different failure modes. Posture findings tend to languish in dashboards, while detections back up in queues. Those two failures need different mechanisms to fix.

The identity attack surface ISPM is meant to shrink

Each item here is standing exposure, present whether or not an attacker is currently in your environment. Most of it can be reduced through configuration, lifecycle, or architecture changes, though some of those changes take approval and a migration window rather than an afternoon.

Standing privilege and over-permissioned service accounts

Any domain user account with a Service Principal Name (SPN) set can have a Ticket Granting Service (TGS) ticket requested by any domain user, which opens the door to offline password cracking of the service account password. High-value SPN filters include MSSQLSvc, exchangeMDB, and HTTP. AES-256 encryption does not remove the risk, because human-set passwords still make dictionary attacks viable.

In Entra ID, the exposures that got my attention are the app permissions that create Global Admin paths without ever appearing in Global Admin membership. RoleManagement.ReadWrite.Directory is a role-management permission that lets an application manage Entra role definitions and assignments, which becomes a high-risk escalation path when combined with other Graph permissions or delegated admin control.

AppRoleAssignment.ReadWrite.All can enable dangerous application-permission assignment paths of its own, depending on the principal's existing rights and tenant configuration.

Application Administrator and Cloud Application Administrator roles can open takeover paths to highly privileged applications by enabling credential changes and other app-management actions, again depending on ownership, app configuration, and role restrictions. Worse for anyone auditing by portal, credentials can live on different objects, so verify both app registrations and service principals.

Dormant and orphaned accounts, stale tokens and keys

Inactive accounts accumulate quietly in AD wherever nobody watches last-logon timestamps. Defender for Identity uses a 90-day threshold and surfaces named posture assessments that cover stale Active Directory accounts, dormant entities in sensitive groups, and non-admin accounts holding DCSync permissions. The Microsoft Cloud Security Benchmark v2 names orphaned service principal abuse explicitly as a persistence technique.

Datadog's 2025 cloud security research found 59% of IAM users still hold AWS access keys more than a year old, over half of them unused for 90 days, with 55% of Google Cloud Platform (GCP) service accounts and 40% of Entra ID applications carrying keys older than a year. Roughly a quarter of AWS IAM users and GCP service accounts have keys older than three years.

Revoking Entra sessions generally invalidates the refresh token, while an existing access token can remain usable until it expires, unless Continuous Access Evaluation or another enforcement condition revokes it earlier. Attackers with sufficient permissions can also add a federated credential to an existing privileged service principal, pointing it at an identity provider (IdP) they control to gain a third authentication method beyond secrets and certificates.

MFA gaps and shadow admin paths

MFA gaps usually take a few predictable forms: legacy authentication protocols left turned on, named locations that miss external Internet Protocol (IP) ranges, break-glass accounts excluded from every policy, and workload identities not covered at all by default.

Change Healthcare's Citrix portal lacked multi-factor authentication because it arrived through an acquisition and was never brought into the control set, according to UnitedHealth's CEO. Policy existence does not guarantee universal enforcement.

Account-by-account review tools often miss multi-hop shadow-admin paths, particularly across hybrid AD, Entra ID, SaaS, and cloud relationships.

Synchronizing disparate AD forests into one Entra tenant can create hybrid attack paths to Domain Admin, including round-trip paths that cross forest security boundaries. A common one runs through a hybrid user with no privileged Entra role who owns a group that has one, which means they can reset the password and MFA of a privileged account.

How to actually assess identity posture

The order matters more than the tooling. I have watched teams buy the graph before they had the inventory, and the graph then confidently understated their exposure.

Inventory identities and entitlements before you score anything

Inventory completeness is a prerequisite for accurate path analysis. Miss ephemeral or auto-scaled workloads and app registrations nobody claims, and every path conclusion downstream is wrong by an unknown amount.

Start with what is free and native. Entra's Identity Secure Score gives native posture guidance covering dormant accounts in sensitive groups, MFA readiness, blocking legacy authentication, and insecure Kerberos delegations. AWS IAM Access Analyzer detects unused access at the action level and generates policies from CloudTrail activity. For AD, PingCastle handles health checks and Purple Knight handles posture scoring.

Find accounts and their access paths

Identity attack path management continuously discovers and maps the choke points where privilege relationships and structural exposures let lateral movement happen, and it scores their risk. BloodHound builds the identity graph across AD and Entra ID.

AzureHound does not need to run inside your environment, because Graph and Azure REST are external APIs, and it needs only read-only permissions such as RoleManagement.Read.Directory. If you have forest trusts, collect every trusted domain or your graph lies.

Then use convergence to prioritize. The typical organization carries about 11,000 exposures with roughly 2% sitting on choke points, the entities where multiple attack paths converge en route to critical assets. Fixing one choke point collapses dozens of paths. That is the number I take to a budget conversation, because removing 40 exposures at the four highest-exposure choke points survives a follow-up question in a way that closing 2,000 findings does not.

Where posture management ends and detection begins

Every exposure above can be at zero and you can still get owned. Posture shrinks the standing attack surface, but attackers increasingly arrive holding a legitimately issued session, and that runtime problem belongs to ITDR.

What ISPM can't see, and why you still need ITDR

Even correctly enforced MFA can leave a window in which adversary-in-the-middle (AiTM) token theft causes harm before the token expires. The Tycoon2FA kit bypassed common MFA, including SMS codes, one-time passcodes, and push approvals.

Stolen session cookies, theft of a Primary Refresh Token (PRT), and OAuth token theft all sit on the far side of the posture boundary. The Salesloft Drift compromise hit multiple organizations through stolen OAuth tokens that bypassed MFA by design.

Identity sits at the center of nearly every intrusion I have watched reach investigation, and they mostly succeed because the attacker holds valid credentials that satisfy every policy check.

ITDR detects the active abuse, but posture and identity controls still cut both the odds and the blast radius through phishing-resistant authentication, conditional access, device compliance, token protection, and app-consent governance. Detection engineering for that runtime layer belongs to ITDR: anomalous token alerts, cookie reuse and session hijacking detections, and vishing-driven help desk resets. Hand that work off there and staff it accordingly.

Fitting ISPM into a stack you already run

Before I sign anything in this category, I map what I am already paying for. ISPM's functional footprint overlaps three products most mature teams already own, and that overlap decides whether the category closes a gap or duplicates spend.

What it overlaps with, and what not to buy twice

Modern IGA platforms are pulling ISPM-type capabilities, including continuous monitoring, risk-based analytics, and automated remediation, directly into governance workflows, and some address privilege creep through automated reviews.

PAM overlaps on discovery and standing privilege, and mature deployments may already provide identity discovery and just-in-time (JIT) access, though how far that discovery reaches beyond privileged accounts varies by platform and licensing tier.

If you run Entra ID P2, native posture features already cover dormant-account detection, MFA posture scoring, and risk policies, and Defender for Identity signals now feed Entra Recommendations. So buy the gaps, and four are worth paying for:

  • Non-human identity (NHI) posture: Okta's own release documentation flags governance gaps around non-human identities, including rarely rotated credentials and excessive privileges. If NHI is your driver, extending IdP governance is insufficient even by the IdP vendor's own account.
  • Continuous drift between campaigns: IGA is campaign-driven, so if quarterly certification is your only cadence, you are blind for 89 days at a time.
  • Cross-system graph: IdP plus SaaS plus infrastructure as a service (IaaS) plus on-prem AD in one graph, including the hybrid sync gaps.
  • Cloud Infrastructure Entitlement Management (CIEM), if you lost it: Entra Permissions Management reached end of sale in April 2025 and full retirement in November 2025. If you were using it, that is an open gap now, and Microsoft's recommended path is a separate Delinea relationship.

Map your current spend against those four gaps before you take a vendor call, and you will know whether ISPM closes an exposure or re-bills one you already cover. That is the evaluation, and it has more than two answers: which standing exposures does the product discover, which can it remediate directly, and which does it only route to another owner.

A product that tickets a risky OAuth grant to its owner still earns its place if the handoff is accountable. I still open every one of these conversations right there.

Frequently asked questions about identity security posture management

What should an ISPM program find and reduce?

ISPM is a discipline that continuously assesses identity configuration, entitlement, and exposure risk across an organization's infrastructure. Operationally, it finds and shrinks standing identity exposure: over-permissioned service accounts, dormant and orphaned accounts, stale keys and tokens, MFA coverage gaps, and privilege paths nobody intended. ISPM was a new entrant in the 2026 Gartner Hype Cycle for Digital Identity.

How is ISPM different from ITDR?

ISPM prioritizes standing exposure and configuration drift; ITDR prioritizes suspicious identity activity and active abuse. In practice, vendors bundle parts of both, so the split is a way to reason about coverage rather than a hard product line. AiTM session theft, session-cookie theft, PRT theft, and OAuth token abuse land mostly on the ITDR side, since they play out after a legitimate authentication, though posture and identity controls still reduce how often they succeed.

Do I need ISPM if I already have PAM or IGA?

PAM and IGA already cover part of the category. Mature PAM deployments may already handle privileged account discovery and standing privilege detection, and some provide JIT access. Modern IGA platforms cover certification, separation-of-duties conflicts, and privilege creep. The gaps worth buying separately are non-human identity posture, continuous drift detection between certification campaigns, and a single graph spanning IdP, SaaS, cloud, and on-prem AD.

Where does ISPM fit with my identity provider?

Entra ID P2 gives you native posture features, including Identity Secure Score recommendations, dormant-account findings, MFA posture scoring, and risk-based sign-in policies, plus Defender for Identity signals feeding Entra Recommendations. Okta also offers posture capabilities alongside its identity protection and governance functions. Buying third-party ISPM for those specific functions duplicates spend, so buy it for what your IdP does not reach, including shadow SaaS and OAuth grants outside its scope.

How do I prioritize identity posture findings without drowning in them?

Prioritize by choke point. The typical organization carries about 11,000 exposures with roughly 2% located where multiple attack paths converge on critical assets, so fixing one can collapse dozens of paths. After building the inventory and the graph in that order, rank each node by how many identities can reach a critical asset through it.


About the author

DCDaniel C. is a security operations leader with over a decade of experience building and scaling SOC capabilities for cloud-native companies. He has led security teams through multiple stages of growth — from early-stage environments with minimal tooling to mature organizations operating 24/7 security operations with distributed teams. His experience includes designing SOC architectures, evaluating and managing MDR providers, and building internal detection and response capabilities. Daniel has been responsible for vendor selection across SIEM, EDR, and XDR platforms, as well as defining SLAs, response models, and escalation frameworks. He has also worked closely with executive leadership on budgeting, board reporting, and aligning security operations with broader business risk. He writes about the practical decisions security leaders face — including build vs buy tradeoffs, how to evaluate security vendors, and what it actually takes to run an effective security operations function at scale

Stay sharp on security operations

Practitioner takes on SOC modernization, detection engineering, threat hunting, and more. No fluff. No product pitches.

Identity security posture management (ISPM): a working field guide | Future of SecOps