Attack Surface Management (ASM / EASM)
What counts as your attack surface, and how to keep track of it as cloud sprawl and shadow IT expand exposure.
URL: trusteed.io/academy/glossary/attack-surface-management
Attack Surface Management (ASM) is the continuous process of discovering, inventorying, and monitoring every asset an organization exposes — internally or externally — that could serve as an entry point for an attacker. It exists because most organizations don't actually know the full extent of what they've deployed: forgotten subdomains, orphaned cloud instances, shadow IT, and third-party integrations all expand an attack surface silently, without anyone deciding to expand it on purpose.
What Is an Attack Surface?
An attack surface is the complete set of points where an unauthorized user could attempt to enter or extract data from a system: every domain, subdomain, IP address, API endpoint, cloud storage bucket, login panel, open port, and third-party integration connected to your organization. It's not a fixed inventory — it grows every time a new feature ships, a new cloud account is provisioned, or a new SaaS tool is connected, and it shrinks only when something is deliberately decommissioned.
ASM vs. EASM: What's the Difference?
ASM is the umbrella discipline, covering both internal and external assets. External Attack Surface Management (EASM) is the specific practice of discovering and monitoring only what's visible from the outside — the view an attacker actually has before gaining any foothold. EASM operates without needing internal network access, agent deployment, or existing asset inventories; it finds things the way an attacker would, from the public internet inward, which is precisely why it catches shadow IT and forgotten infrastructure that internally-scoped tools structurally cannot see.
| ASM (general) | EASM (external) | |
|---|---|---|
| Scope | Internal + external assets | Internet-facing assets only |
| Discovery method | Internal inventories, agents, network scans, external discovery | Passive/active reconnaissance, no internal access required |
| Finds shadow IT? | Partially, depending on tooling | Yes — by design, since it doesn't depend on internal records |
| Typical use case | Comprehensive asset governance | Continuous external exposure monitoring |
Why ASM Matters
Research cited in Trusteed's asset discovery coverage consistently shows organizations are aware of roughly 60–65% of their actual internet-facing assets — meaning a third or more of the attack surface is effectively invisible to the team responsible for defending it. Cloud sprawl, infrastructure-as-code, mergers and acquisitions, and shadow IT all compound this gap continuously, faster than manual inventory processes can track.
This is also the direct API-layer manifestation of what OWASP calls Improper Inventory Management (API9:2023) — an undocumented API endpoint is, at the asset level, exactly the kind of exposure ASM/EASM is built to surface.
Core Components of an ASM Program
Discovery — continuously enumerating assets across cloud accounts, domains, DNS records, and internet-edge infrastructure, without relying solely on a static seed list of "known" assets. Classification — determining what each discovered asset actually is (a production API, a staging environment, a marketing microsite) and who owns it. Risk prioritization — ranking discovered assets and their associated exposures by business criticality and exploitability, not just raw count. Continuous monitoring — re-checking the inventory on an ongoing basis, since attack surfaces change constantly, not on a quarterly cadence.
How ASM Fits Into CTEM
ASM/EASM corresponds to the Scoping and Discovery stages of a Continuous Threat Exposure Management (CTEM) program — the foundation everything else depends on. You cannot prioritize risk on an asset you don't know exists, and you cannot validate exploitability for infrastructure that isn't in your inventory. Organizations that skip a strong ASM foundation and jump straight to vulnerability scanning are, by definition, only scanning the portion of their environment they already know about.
Frequently asked questions
Does ASM replace a CMDB (Configuration Management Database)?
No, but it complements one. A CMDB reflects what's been formally documented and entered by IT teams. ASM/EASM discovers what's actually reachable and running, independent of whether it was ever documented — which is exactly how it catches the gap between "recorded" and "real."
How often should attack surface discovery run?
Continuously, not periodically. New assets can appear the moment a developer provisions a cloud resource or a marketing team stands up a new subdomain — a monthly or quarterly discovery cycle leaves that window fully exposed until the next scan.
Can EASM tools access assets behind a login or VPN?
Generally no — that's the defining characteristic of EASM: it operates from the outside, the same vantage point an unauthenticated attacker has, which is why it's a valuable complement to internal asset inventories rather than a replacement for them.