Attack Surface Management vs Identity Attack Surface Management: Assets, Access Paths and Who Owns Each

An organisation can have a clean external scan and still be one sprayed password away from its executives' mailboxes, because the asset view and the identity view of exposure answer different questions. Attack surface management (ASM), and its external form EASM, discovers what an attacker can reach on the internet: domains, IP addresses, services, certificates and leaked secrets. Identity attack surface management looks at who and what can act once an attacker holds any credential: accounts, roles, tokens, trust relationships and the paths between them, for people, service accounts, workloads and AI agents. This guide compares the two as disciplines: threat model, data sources, architecture, failure modes, controls, where identity attack surface work overlaps with identity security posture management (ISPM), metrics and a worked scenario. It is for exposure management leads, identity security teams and architects deciding who owns which part of exposure.

Key takeaways

• ASM maps assets; identity attack surface work maps access. One asks what is reachable from outside, the other asks what any credential can lead to inside.
• Credentials are where they meet. A leaked key in a public repository is an EASM finding; what that key can do is an identity finding. Treat both halves as one exposure, with one owner for closure.
• Non-human identities dominate identity paths. Service accounts, OAuth applications, workload roles and agents hold broad, rarely reviewed permissions and are often the shortest route from a foothold to critical data.
• Identity attack surface work overlaps heavily with ISPM. The term is used for ISPM plus attack path analysis rather than a separate standard; buy and staff it as part of the identity programme, not as a second asset inventory.
• Measure closure, not counts. Discovered assets and identities grow forever; the useful numbers are time to close exposed services, leaked credentials still valid, and paths to critical assets removed.

The short answer

Use ASM when the question is "what of ours can an outsider see and touch?" It finds unknown subdomains, exposed management interfaces, expiring certificates, cloud resources open to the internet and secrets published in code. Use identity attack surface management when the question is "if an attacker gets any account, token or key, how far can it go?" It finds dormant and over-privileged accounts, missing MFA, risky OAuth consents, cross-account trusts and the chains of group memberships, roles and impersonation rights that lead to tier-zero systems. Most organisations need both views, joined at the credential, with the asset view owned by exposure or vulnerability management and the identity view owned by identity security. The live Attack Surface Management Guide and ISPM Guide cover each discipline in depth; this page concentrates on the boundary.

What each discipline is

Attack surface management: assets from the outside in

The NCSC describes EASM tools as providing automated discovery of an organisation's external attack surface, showing it from an attacker's perspective. They find domains, subdomains and IP addresses; software, versions and exposed services such as SSH, FTP, databases and web servers; DNS configuration and TLS certificates; suppliers such as cloud, ISP and mail providers; and issues such as unsupported software, email anti-spoofing gaps and subdomain takeover risk. Cyber asset attack surface management (CAASM) adds the inside view by joining data from endpoint, cloud, directory and scanner tools. CISA's BOD 23-01 states that "asset visibility is a basic pre-condition for any organization to effectively manage cybersecurity risk", and requires US federal agencies to run asset discovery every 7 days across their IPv4 space. Architecturally, ASM is internet scan data, DNS and certificate transparency sources, connectors to cloud accounts and asset tools, and a findings workflow.

Identity attack surface management: access from the inside out

The identity attack surface is every account, credential, role assignment, token, consent and trust relationship an attacker could use, plus the relationships that let one become another. The work reads configuration and entitlement data from directories, identity providers, cloud IAM, SaaS tenants, secrets stores and CI/CD platforms, then builds a graph: nodes are identities, groups, roles, machines and resources; edges are memberships, permissions, sessions, impersonation rights and federation trusts. Microsoft's exposure management documentation describes attack paths as end-to-end routes from an entry point to a critical asset, built from assets, techniques and weaknesses, with choke points where many paths converge. The identity part of that graph is what identity attack surface management owns. Graph analysis in depth is in the Identity Attack Paths Guide.

Side-by-side comparison

Threat model for each

What ASM defends against

• Reconnaissance and opportunistic exploitation: attackers run active scanning (ATT&CK T1595), search open technical databases (T1596) and gather domain properties (T1590.001) to find forgotten hosts and exposed services before you do.
• Leaked secrets: credentials found in public code repositories (T1593.003) are a direct entry point. GitHub secret scanning searches full Git history across branches, issues and pull requests and recommends rotating a leaked credential straight away rather than rewriting history.
• Blind spots: NCSC notes that EASM focuses on external assets, that version-based CVE warnings show a system is likely, not definitely, vulnerable, and that findings can include false positives. ASM says nothing about what a valid login can do.

What identity attack surface management defends against

• Valid account abuse: sprayed or stolen passwords (T1110.003, T1078) on accounts without MFA. In the Snowflake breach, infostealer credentials for accounts without MFA, unrotated for years and not restricted by network, unlocked about 165 organisations' data. An external scan of those organisations would not have shown the exposure.
• Token and consent abuse: stolen application access tokens (T1528) and malicious or over-broad OAuth consents that grant tenant-wide data access without a user signing in.
• Privilege escalation through relationships: adding cloud roles (T1098.003), impersonating service accounts, or chaining group memberships to reach tier zero.
• Blind spots: an identity graph sees only connected sources. A test tenant, a SaaS application bought outside procurement or a key in a public repository may be invisible until the asset view finds it.

Where they meet: credentials, tenants and machine identities

The most damaging exposures cross the line between the two. The Microsoft Midnight Blizzard breach shows the pattern: the actor password-sprayed an account in a legacy, non-production test tenant that lacked MFA, found a legacy test OAuth application with elevated access to the corporate environment, and granted itself an Exchange Online role that let it read senior leaders' mailboxes without signing in as them. The forgotten tenant is an asset finding; the OAuth application's permissions and the path to mailboxes are identity findings. Neither view alone shows the whole route.

For non-human identities the OWASP Non-Human Identities Top 10 is a useful checklist of identity-side findings: NHI1:2025 Improper Offboarding, NHI2:2025 Secret Leakage, NHI3:2025 Vulnerable Third-Party NHI, NHI5:2025 Overprivileged NHI and NHI7:2025 Long-Lived Secrets map directly to the joint actions above. The asset-side view of exposed secrets is in the ASM guide's identity section; this table is the hand-off between teams.

Overlap with ISPM, ITDR and CTEM

• ISPM: continuously assesses identity configuration and hygiene. Identity attack surface management, as vendors and analysts use the term, is largely ISPM plus graph-based path analysis and external credential exposure data. If you already run ISPM, extend it with path analysis and leaked-credential feeds rather than buying a parallel inventory. See ISPM vs ITDR and IGA vs ISPM.
• ITDR: detects attackers using identity weaknesses. Exposure findings tell ITDR which accounts and paths to watch most closely.
• CTEM and exposure management: the programme cycle that should own both views, so that an exposed service and an identity path to the same critical asset are prioritised together. See the Exposure Management and CTEM Guide.
• Cloud-native analysers: platforms provide identity exposure data that feeds either view. Platforms are listed alphabetically. AWS IAM Access Analyzer reports external access (resources shared outside a zone of trust), internal access to selected critical resources and unused access such as unused roles and access keys. Google Cloud's IAM recommender compares granted and used permissions over up to 90 days, covers service accounts, and raises lateral movement insights for service accounts in other projects with impersonation rights. Microsoft Security Exposure Management builds attack paths over an enterprise exposure graph, highlights choke points and ends on-premises paths at assets such as Domain Admins and domain controllers.

Failure modes

• Two inventories, no join: the ASM tool and the identity tool each produce a list, and nobody links a leaked key to the identity behind it, so the secret is reported while the account keeps its rights.
• Seed list too narrow: ASM discovery starts from registered domains and misses test tenants, acquisitions and supplier-hosted services; the identity graph starts from the production directory and misses the same places.
• Humans only: identity exposure reviews cover user accounts and administrators, while OAuth applications, service principals and workload roles with broader rights go unreviewed.
• Revoking the secret, not the path: a leaked credential is rotated, but the over-privileged role and the trust that made it valuable stay, ready for the next leak.
• Counting without closing: dashboards show growing numbers of assets and identities discovered, with no owner, no deadline and no measure of paths removed.
• Agents outside both views: AI agents are deployed with exposed endpoints and broad tool permissions, but are neither in the asset inventory nor in the identity graph.

Controls and how to implement them

1. Agree the critical assets: name the tier-zero systems and crown-jewel data both teams will measure paths to (directories, identity providers, cloud organisation roots, secrets stores, CI/CD, key data platforms).
2. Widen the seeds together: share domains, tenants, cloud accounts, code organisations and acquisitions between the ASM and identity teams so both discover from the same scope.
3. Connect identity sources: directories, identity providers, cloud IAM in every account, major SaaS tenants, secrets stores and CI/CD platforms. Run the cloud analysers in report mode first and tune before raising tickets.
4. Build the join: every leaked or exposed credential finding is enriched with the identity it belongs to, its permissions and last use; every exposed asset is enriched with the identities stored on or able to administer it.
5. Close in priority order: valid leaked credentials first, then accounts without MFA that can reach critical assets, then choke points that remove many paths at once, then dormant and unused access.
6. Validate and roll back: confirm closure by rescanning and recomputing paths; for permission removals, disable before deleting and keep a short rollback window with an owner on call.
7. Bring NHIs and agents into both views: each service account, app and agent gets an owner, a purpose and a review date. See the Identity Visibility, Posture and Threat Detection Guide.

Decision guidance

• Lead with ASM when: you do not know your internet-facing estate, have frequent acquisitions or decentralised cloud adoption, or keep discovering exposed services after incidents.
• Lead with identity attack surface work when: the external estate is small and well known but identities are spread across several identity providers, clouds and SaaS tenants, or recent incidents began with valid accounts or tokens.
• Smaller organisations: start with an EASM service or free scan data for the outside view, and the cloud and identity provider's native posture and access analysis for the identity view, before any dedicated product.
• Larger organisations: put both views under one exposure management programme, with separate owners and one prioritisation model keyed to critical assets.
• Buying: ask an ASM vendor how it ties leaked credentials to identities, and an identity vendor how it covers non-human identities, OAuth apps and agents, and whether it ingests external exposure data. See the Attack Surface Management Buyer's Guide.

Worked scenario: one leaked key, two teams

A software company's EASM service raises a finding: a cloud access key published in a public repository by a contractor. The ASM team reports it to the repository owner, who removes the file. Under a joined process, the finding is also enriched with identity data: the key belongs to a deployment service account that is unused for three months but still holds administrator rights in two production accounts, and that account can assume a role trusted by the organisation's logging account. The identity team revokes the key within the hour, disables the service account, checks audit logs for use of the key since publication, and removes the cross-account trust. The path analysis is rerun and shows the choke point gone. The lesson recorded is not "remove the file" but "a dormant administrator identity with a static key existed": the fix is moving deployments to short-lived federated tokens and alerting on unused privileged identities.

Detection and measurement

• Monitor: new internet-exposed services and certificates; new secret-scanning alerts with validity status; new OAuth consents with high-privilege scopes; new cross-account or cross-tenant trusts; privileged role assignments to service identities; use of credentials after they were reported leaked.
• Leaked credentials still valid: count and median age of exposed credentials that have not been revoked.
• Time to close: median days from discovery to closure for exposed services and for identity findings that reach critical assets.
• Paths to critical assets: number of identity paths to tier zero and number of choke points, trended monthly.
• NHI coverage: share of service accounts, apps and agents with an owner and a review date.
• Unknown share: share of newly discovered assets and identities that had no owner or were not in any inventory.

Framework mapping

Practitioner checklist

• Agree one list of critical assets that both the ASM and identity teams measure exposure against.
• Share discovery seeds (domains, tenants, cloud accounts, code organisations, acquisitions) between teams.
• Enrich every leaked or exposed credential with its identity, permissions and last use before closing it.
• Revoke valid leaked credentials first, then remove the rights and trusts that made them valuable.
• Connect directories, identity providers, every cloud account, major SaaS tenants, secrets stores and CI/CD to the identity view.
• Include service accounts, OAuth apps, workload roles and AI agents, each with an owner and review date.
• Use choke points to prioritise identity fixes that remove many paths at once.
• Report leaked credentials still valid, time to close and paths to critical assets monthly.

Standards and references

• NCSC: External attack surface management buyer's guide
• CISA: BOD 23-01 Improving Asset Visibility and Vulnerability Detection on Federal Networks
• NIST: Cybersecurity Framework 2.0
• OWASP: Non-Human Identities Top 10 2025
• MITRE ATT&CK: Valid Accounts
• AWS: IAM Access Analyzer
• Google Cloud: Role recommendations overview
• Microsoft: Review attack paths in Security Exposure Management

Related NHI Mgmt Group resources: Attack Surface Management Guide · ISPM Guide · Identity Attack Paths Guide · Exposure Management and CTEM Guide · BloodHound and Active Directory Attack Path Guide