What Is Identity Attack Surface Management (IASM)?

Most organisations can list their servers and their endpoints. Very few can list every identity that can reach them, including the service accounts nobody owns and the API keys that outlived the project. Identity Attack Surface Management (IASM) is the practice of discovering every identity across your estate, mapping what each one can actually reach, scoring the risk, and closing the gaps before an attacker finds them. It is not a replacement for IAM, IGA, or PAM. It is the continuous layer that sits over all three and tells you what they are collectively missing.

If you are trying to work out where IASM fits against ITDR, ISPM, and CIEM, skip to the acronym map. If you want the practical version, go to the 90-day starting plan.

Last verified: September 2026. Checked against IBM's Cost of a Data Breach 2026 figures, vendor product documentation, and publicly confirmed 2026 market consolidation.

What is Identity Attack Surface Management (IASM)?

IASM is a proactive security practice, and a tool category, that provides identity discovery, risk assessment, and mitigation workflows across an organisation's identity assets and the relationships between them. It graphs those assets, analyses them for exposures, and drives remediation.

The identity attack surface is every system, on-premises and in the cloud, that authenticates a human or automated interaction and grants access on the basis of it. That includes directories, user accounts, service accounts, authentication mechanisms, federation trusts, entitlements, tokens, API keys, and the privileged access paths between them.

The distinguishing move is perspective. Traditional identity tooling asks "is this access correctly provisioned?" IASM asks "what would an attacker do with what is actually provisioned right now?" Those two questions produce different findings from the same data, and the second one is the one that matches how breaches happen.

Why identity became the attack surface

Perimeter defences assume there is a perimeter. When staff work from anywhere, workloads run in three clouds, and half your integrations are third-party APIs holding long-lived tokens, the durable boundary is the identity, not the network. Attackers moved accordingly, because a valid credential does not trigger the alarms a vulnerability exploit does.

The economics support the shift. IBM's Cost of a Data Breach Report 2026 puts the global average cost of a breach at $4.99 million, a record and a 12% year-over-year increase. Against that, the cost of an identity hygiene programme is a rounding error, which is the argument to take to a budget meeting.

Three structural changes made the identity surface harder to see at exactly the moment it became the target:

• Identity data decentralised. Hybrid estates split identity across on-premises Active Directory, one or more cloud identity providers, and per-SaaS local user stores. No single console holds the whole picture, so no single console can tell you the whole risk.
• Non-human identities outgrew human ones. Service accounts, workload identities, CI/CD tokens, Kubernetes service accounts, OAuth app registrations, and now AI agents all authenticate. Most were created by an engineer solving a problem, and most are governed by nothing.
• Entitlements accumulated. Permissions are granted continuously and revoked rarely. The gap between what an account was provisioned for and what it can currently reach widens every quarter, and that gap is the attack path.

The limits of IAM, IGA, and PAM on their own

Three pillars have carried identity security for two decades, and each was designed for a problem that is no longer the whole problem.

• IAM authenticates users and enforces access at the point of entry. It verifies the login. It does not continuously check whether the permissions behind that login still match the person's job.
• IGA manages the lifecycle: provisioning, role assignment, access certification. It audits periodically. A quarterly certification cannot detect a privilege escalation that happens on a Tuesday and is used on a Wednesday.
• PAM vaults and brokers privileged credentials. It is excellent at human administrators. It routinely misses the service account, the API key, and the cloud workload identity that hold equivalent power without ever appearing in a vault.

None of these are wrong. They are point-in-time and siloed, and attackers operate in the gaps between them. IASM is the layer that reads across all three, plus the systems none of them cover, and produces one prioritised view.

The acronym map: IASM, ITDR, ISPM, CIEM, and NHI

These five terms are used interchangeably in vendor marketing and they are not interchangeable. The clean way to separate them is by the question each answers.

Category	The question it answers	Timing	Primary scope
IASM, Identity Attack Surface Management	What identity exposure exists across the whole estate, and which of it matters most?	Continuous, preventive	Every identity and every access path, human and non-human, on-premises and cloud
ISPM, Identity Security Posture Management	Is our identity configuration correct against policy and best practice?	Continuous, preventive	Configuration and hygiene of identity systems: MFA coverage, stale accounts, weak policy, dormant admins
ITDR, Identity Threat Detection and Response	Is an identity attack happening right now, and can we stop it?	Real time, detective and responsive	Sessions, tokens, consent grants, anomalous behaviour, lateral movement
CIEM, Cloud Infrastructure Entitlement Management	Who and what can do what in our cloud accounts, and how much of it is excessive?	Continuous, preventive	Cloud entitlements specifically: AWS IAM, Azure RBAC, GCP IAM
NHI security, Non-Human Identity	What machine identities exist, who owns them, and are their secrets rotated?	Continuous, preventive	Service accounts, API keys, tokens, certificates, workload and agent identities

In practice the relationship is a nesting, not a competition. ISPM and CIEM are both narrower posture disciplines, ISPM on identity system configuration and CIEM on cloud entitlements, and a capable IASM programme subsumes both. NHI security is the population IASM most often reveals as unmanaged. ITDR is the runtime half of the same problem: IASM reduces the surface before the attack, ITDR catches the attack that lands on what remains.

The practical consequence: IASM and ITDR are complements, not alternatives. Buying detection without doing discovery means you detect attacks against a surface you never measured. Doing discovery without detection means you shrink the surface and then stop watching it. For the runtime side in depth, see the ITDR guide.

Core capabilities of an IASM programme

1. Identity discovery and mapping

Inventory every identity across hybrid environments: employees, contractors, customers, service accounts, API keys, workload identities, OAuth app registrations, and AI agents. Discovery is the step that produces the uncomfortable number, and it is the step most programmes underinvest in. Typical findings include hidden service accounts in Active Directory, over-permissioned roles in cloud IAM, orphaned accounts belonging to people who left, and shadow SaaS tenants nobody registered.

Mapping matters as much as counting. An inventory tells you an identity exists. A graph tells you what it can reach, and which two hops away from it sit your crown jewels.

2. Risk prioritisation and privilege analysis

Correlate permissions across systems to find excessive privilege and viable attack paths. A marketing contractor with write access to a financial database is a finding. A CI/CD token with administrative rights in production is a bigger one. The output that matters is not a list of misconfigurations, it is a ranked list of paths an attacker could actually walk, scored by what sits at the end of each path.

3. Continuous monitoring and drift detection

Identity configuration is not static. A benign account becomes over-privileged through a role change, a project grant that was never revoked, or a group nesting nobody noticed. IASM watches for that identity drift and alerts on deviation from baseline, rather than waiting for the next certification cycle.

4. Non-human identity governance

Discover and classify machine identities, assign each one a human owner, and hold them to rotation, scoping, and expiry policy. This is where IASM most often delivers its first concrete win, because service accounts and long-lived tokens are usually ungoverned, frequently over-privileged, and almost never monitored. AI agents make this urgent rather than merely important: an agent with delegated credentials is a non-human identity with a much broader action space than a service account.

5. Remediation and response integration

Findings that do not become tickets, workflows, or automated actions are a report, not a control. Mature IASM pushes remediation into the systems that own the change: an IGA workflow to revoke access, a PAM policy to vault a discovered credential, a cloud policy update to trim an entitlement. It also feeds SIEM and XDR so that posture context enriches detection.

How IASM changes IAM, IGA, and PAM

IASM is most valuable when it feeds the tools you already own rather than sitting beside them.

IAM gains continuous context

IAM decides at the door. IASM supplies the risk context that makes the decision smarter: if an account has accumulated risky permissions, or its device fails a posture check, step-up authentication can be required before access is granted. That is a dynamic policy rather than a static MFA rule, and it is the practical form of a zero trust posture.

IGA gains real-time governance

IGA relies on periodic reviews and static role definitions. IASM validates entitlements continuously against current job function, so a department change triggers a revocation workflow immediately instead of surfacing at the next certification. It also shortens certification itself, by pre-flagging the entitlements that actually carry risk so reviewers are not rubber-stamping a thousand rows to reach the ten that matter.

PAM extends to machine identities

PAM secures human administrators well. IASM finds the privileged non-human accounts that never reached the vault, classifies them, and drives them into vaulting, rotation, and just-in-time policies. In most estates this is a larger population than the human administrators, and it is the one an attacker prefers because nobody is watching it.

Unified policy enforcement

Aggregating IAM, IGA, and PAM data enables one policy statement rather than three conflicting ones. A single rule can require that every privileged session is brokered through PAM, authenticated with a phishing-resistant factor, and consistent with the role model in IGA. Without that aggregation, each tool enforces its own view and the gaps between the views are invisible.

The attack vectors IASM is defending against

Identity-centric attack paths, roughly in order of how often they show up in incident reports:

• Stolen or reused credentials. Infostealer output, breach reuse, and credential stuffing. No exploit required.
• Phishing and adversary-in-the-middle. Modern phishing kits proxy the real login and steal the post-MFA session cookie, which is why non-phishing-resistant MFA is not the control people believe it is.
• MFA fatigue. Push prompt spamming until someone approves.
• OAuth consent phishing. The user grants a malicious application broad scopes. The attacker never touches a password and the access persists through a password reset.
• Over-privileged and dormant accounts. Accounts that should not have the access they have, or should not exist at all.
• Unmanaged non-human identities. Long-lived API keys, service accounts with domain admin, hardcoded secrets in repositories.
• Cloud entitlement misconfiguration. Roles that can escalate to administrator through a chain of legitimate permissions.
• Federation and trust abuse. Compromised identity provider trust relationships, forged assertions, and downstream access through a supplier's identity plane.
• Supply chain and third-party access. Vendor and integrator identities with standing access into your estate.
• Insider misuse. Legitimate access used illegitimately, which posture tooling catches only by noticing that the access should never have been that broad.

What unites this list is that almost none of it is a software vulnerability. It is configuration, accumulation, and trust. That is why patching programmes do not reduce it and identity hygiene programmes do.

What the public breaches actually taught

A handful of well-documented incidents map cleanly onto the categories above, and each one points at a control that IASM is designed to surface.

• Snowflake customer accounts (2024). Attackers used credentials harvested elsewhere against customer tenants that had no MFA enforced. The lesson is coverage: an MFA policy that does not cover every account is a partial control, and knowing which accounts are uncovered is a discovery problem.
• Microsoft, Midnight Blizzard (disclosed January 2024). Password spraying succeeded against a legacy non-production test tenant account that lacked MFA, and an OAuth application with elevated permissions was used to extend access. Legacy and non-production identities are in scope, and OAuth application permissions are an identity attack surface in their own right.
• Okta support system (2023). Access was obtained through a credential exposed via a personal account on a company-managed device. Boundaries between personal and corporate identity are part of the surface.
• MGM Resorts (2023). Reported as social engineering of the help desk to obtain a credential reset. The recovery path is an authentication path, and it is frequently the weakest one.
• Retool (2023). A social engineering chain that reached an account with broad internal access, with a cloud authenticator sync feature widening the blast radius.

Read as a set, these are not sophisticated exploit stories. They are stories about accounts nobody had inventoried, MFA that was not universal, help desks that could be talked into a reset, and application permissions that nobody reviewed. All four are discoverable before an attacker finds them, which is the entire premise of IASM.

The vendor landscape in 2026

There is no clean "IASM market" with tidy boundaries. Capability is delivered from five directions, and most organisations assemble rather than buy.

Where capability comes from	Representative vendors	What it covers well	What it misses
Identity governance platforms adding posture	SailPoint, Saviynt, Omada	Entitlement context, certification workflow, remediation that actually executes	Real-time detection, cloud-native and non-human identity depth
Privileged access vendors extending outward	CyberArk (now part of Palo Alto Networks), Delinea, BeyondTrust, One Identity	Privileged account discovery, secrets, session control	Standing user entitlements, customer identity, SaaS local accounts
Identity providers adding native posture	Microsoft Entra ID Governance and Defender for Identity, Okta Identity Security Posture Management	Deep coverage of their own estate, low friction to enable	Anything outside their own identity plane
Dedicated ITDR and identity security specialists	Silverfort, Push Security, Permiso, Semperis (Active Directory specifically)	Detection, legacy and AD coverage, response	Governance workflow and entitlement remediation
Cloud security platforms with CIEM	Wiz, Palo Alto Prisma Cloud, Microsoft Defender for Cloud	Cloud entitlements, attack-path graphing across cloud assets	On-premises directories, workforce and customer identity

The category is consolidating quickly, which is a buying consideration in itself. Palo Alto Networks completed its acquisition of CyberArk on 11 February 2026, folding one of the largest privileged access franchises into a platform vendor. Assume any standalone identity security product you evaluate may have a different owner within eighteen months, and weight the integration surface and the data export path accordingly.

Practical selection advice: start from your biggest blind spot rather than from the category label. If your risk is Active Directory, buy AD-specific depth. If it is cloud entitlements, a CIEM-capable cloud security platform will outperform a general identity tool. If it is ungoverned service accounts, non-human identity coverage is the requirement, and you should test it against your real environment rather than a demo tenant.

What IASM costs

Pricing is rarely published and is usually structured per identity, per asset under management, or per module. Several practical notes, offered as budgeting structure rather than as quoted prices:

• Per-identity pricing is a trap if you have not done discovery. The whole point of the tool is that you have more identities than you think, and your bill scales with the finding.
• Non-human identities are frequently priced separately or counted differently from human ones. Ask explicitly, because in many estates they are the larger population.
• The integration work is a real line item. Connecting on-premises directories, several cloud identity providers, and the SaaS estate is where implementation time goes.
• Some meaningful capability is already paid for. Identity governance features inside your existing identity provider licence, and CIEM inside your existing cloud security platform, frequently cover the first wave of findings at no extra cost. Exhaust that before buying.

Set the business case against breach cost rather than against tool cost. At a global average of $4.99 million per breach, and with credential-based intrusion as one of the most common initial access routes, an identity hygiene programme does not need a large risk reduction to pay for itself.

Benefits of IASM

• Visibility you did not previously have. The first discovery run is usually the most valuable output of the entire programme, because it changes what the security team believes about its own estate.
• Prioritisation instead of a findings backlog. Attack-path scoring turns thousands of misconfigurations into a ranked list of paths that actually reach something valuable.
• Reduced blast radius. Trimming standing privilege limits what a single compromised credential can do, which is the difference between an incident and a breach.
• Faster, cheaper audits. Continuous evidence of least-privilege enforcement and access review replaces the scramble before an assessment.
• Better incident response. When responders already have the identity graph, "what else could this account reach?" is a query rather than a week of investigation.
• Lower operational cost over time. Automated revocation of dormant and orphaned access removes work that was previously manual and usually skipped.

Challenges of implementing IASM

• No single source of truth. Hybrid estates split identity data across systems that disagree with each other. Reconciliation is the hard part, and it is not a product feature you can buy your way past.
• Legacy systems that will not integrate. Applications with local accounts and no modern protocol stay invisible unless you wrap them, and wrapping them is a project.
• Findings without owners. Discovery produces thousands of results. Without a named owner per finding class and a remediation workflow, the programme becomes a dashboard nobody opens.
• Non-human identity ownership. The single hardest operational question in this discipline is "who owns this service account?", and in most organisations the honest answer for a large share of them is nobody.
• Breaking production. Aggressive permission trimming breaks things. Stage it, monitor for denials, and build a fast restore path, or the first outage will end the programme.
• The human layer. Help desk social engineering, credential sharing, and personal-device boundary crossing are identity attack surface that no scanner enumerates.

A 90-day IASM starting plan

You do not need a platform purchase to begin. The first three items below can be done with tooling most organisations already own.

1. Days 1 to 15: inventory the identity providers themselves. List every system that can authenticate a user or workload, including SaaS applications with local accounts. This list is usually longer than expected and it scopes everything that follows.
2. Days 15 to 30: measure MFA coverage and find the exceptions. Not "do we have MFA" but "which accounts do not have it, and why". Every incident in the section above involved an account outside the policy. Prioritise phishing-resistant factors for administrators.
3. Days 30 to 45: enumerate privileged accounts, human and non-human. Include cloud roles with escalation paths, not just group membership. Assign every privileged non-human identity a named human owner, and treat an unowned one as a finding.
4. Days 45 to 60: kill the dormant population. Accounts unused for 90 days, accounts for departed staff, and credentials for retired integrations. This is the highest ratio of risk removed to effort spent in the whole programme.
5. Days 60 to 75: audit the recovery and help desk paths. What can an agent reset, with what verification? Run the social engineering scenario as a tabletop. Recovery is an authentication path and it is usually the weakest one.
6. Days 75 to 90: review OAuth application grants and third-party access. Which applications hold which scopes in your tenant, and who approved them? Revoke the unrecognised ones and put an approval gate in front of new ones.

Only after that should you scope a platform, because by then you know which blind spot is biggest and you can evaluate against your real environment instead of a feature list.

Best practices for implementing IASM

• Discovery before tooling. Buying a platform before you know your worst blind spot means the platform chooses your priorities for you.
• Own every identity. A named human owner per identity, including machine ones. Unowned equals unmanaged.
• Phishing-resistant factors for privileged access. Push and one-time codes are not sufficient for accounts whose compromise is a company-level event.
• Treat recovery as an authentication path and give it the same scrutiny as the login path. It is where determined attackers go.
• Time-bound privilege. Just-in-time elevation beats standing access, and it collapses the window in which a stolen credential is useful.
• Feed identity signals to the SOC. Posture context makes detection better, and detections make posture priorities concrete.
• Measure a small number of things well. Privileged accounts without phishing-resistant MFA, non-human identities without an owner, dormant accounts still enabled, and mean time to revoke. Four numbers, tracked monthly, beat a dashboard of two hundred.
• Stage remediation. Monitor in advisory mode, then enforce. Breaking production is how identity programmes lose their mandate.

Where IASM is heading

• AI agents as a first-class identity population. Agents authenticate, hold delegated authority, and act at machine speed across systems. They need discovery, ownership, scoping, and revocation like any other identity, and current tooling is behind the deployment curve.
• Convergence into platforms. The separate IASM, ISPM, ITDR, and CIEM product categories are collapsing into identity security platforms, and the 2026 consolidation wave is the visible form of that. Expect fewer standalone vendors and more modules.
• Phishing-resistant authentication as the assumed baseline. As passkeys and hardware-backed credentials become the default, the residual attack surface shifts further toward entitlements, tokens, recovery paths, and machine identities, which is exactly the territory IASM covers.
• Identity graph as shared infrastructure. The map of who can reach what is becoming the substrate that governance, detection, and response all query, rather than something each tool rebuilds privately.

Frequently Asked Questions

What is identity attack surface management in one sentence?

IASM is the continuous practice of discovering every human and non-human identity across an organisation, mapping what each one can reach, scoring which of those access paths an attacker would actually use, and closing them before that happens.

What is the difference between IASM and ITDR?

IASM is preventive and continuous: it reduces the identity attack surface before anything happens. ITDR is detective and real-time: it identifies and responds to an identity attack in progress, through session, token, and behaviour signals. They are complements. Detection without discovery means watching a surface you never measured, and discovery without detection means shrinking the surface and then looking away.

Is IASM the same as ISPM?

They overlap heavily and some vendors use the terms interchangeably. The useful distinction: ISPM focuses on whether identity system configuration matches policy, such as MFA coverage, stale accounts, and weak settings. IASM takes the attacker's view across the whole estate, including entitlement paths and non-human identities, and prioritises by exploitability rather than by policy deviation.

How does IASM differ from general attack surface management?

Traditional ASM and EASM inventory internet-facing assets: domains, IP ranges, exposed services, certificates. IASM inventories identities and the access relationships between them. An EASM tool finds the misconfigured storage bucket. An IASM tool finds the service account that can read every bucket. Most organisations need both, and they are rarely the same product.

Do we need to buy a dedicated IASM tool?

Not to start. Identity governance features in your existing identity provider licence, CIEM inside your cloud security platform, and a disciplined manual pass over privileged and dormant accounts will surface most of the first wave of findings. Scope a purchase once you know which blind spot is largest, and test candidates against your real environment rather than a demo tenant.

What does IASM cost?

Pricing is usually per identity, per asset under management, or per module, and is rarely published. The budgeting trap is that per-identity pricing scales with exactly the discovery finding you bought the tool to produce. Ask specifically how non-human identities are counted, because in many estates they outnumber the human ones, and include integration effort in the total.

Where do non-human identities fit into IASM?

They are usually the largest ungoverned population an IASM programme discovers, and the fastest win. Service accounts, API keys, CI/CD tokens, workload identities, and AI agents all authenticate and all hold access, and most were created outside any governance process. Assigning each a human owner is the first control, and rotation, scoping, and expiry follow from that.

How do we measure whether IASM is working?

Four metrics carry most of the signal. The share of privileged accounts on a phishing-resistant factor, the number of non-human identities without a named owner, the count of dormant accounts still enabled, and mean time to revoke access. All four should move in one direction, and all four are reportable to a board without translation.

The bottom line

Identity is where modern attacks start, and it is the one attack surface most organisations have never fully enumerated. IASM is the discipline of enumerating it, understanding it as a graph rather than a list, and closing the paths that matter. It does not replace IAM, IGA, or PAM. It reads across them, covers what none of them reach, and makes their combined output something you can act on in priority order.

The starting move is not a purchase. It is a discovery pass, and an honest answer to a short question: can you list every identity that can reach your most valuable system, and name a human owner for each one? Most organisations cannot. That gap is the identity attack surface.

Written from the practitioner vantage of having founded LoginRadius, a customer identity platform scaled to over a billion user identities, where identity sprawl and entitlement drift were architecture problems before they had acronyms.

Related reading: ITDR explained, privileged access management solutions, identity governance and administration solutions, attack surface management tools, and account recovery design.