External attack surface management (EASM) is the continuous discovery and monitoring of every asset that is reachable from the public internet and belongs, even loosely, to your organization. That includes assets your CMDB has never heard of: a marketing microsite spun up by an agency, a staging API left on a wildcard subdomain, a forgotten VPN concentrator still answering on a legacy IP block. EASM exists because internal inventory answers “what do we think we own” while the internet answers “what can actually be reached,” and those two lists are never identical.
The Core Definition: Outside-In Inventory, Not Configuration Records
Internal asset inventory, whether that’s a CMDB, an MDM console, or a cloud provider’s resource graph, is built from the inside. Something has to register the asset before it appears: a Terraform apply, an onboarding ticket, an agent installed on a host. External attack surface management works the other way. It starts from what an outside party can observe (DNS records, routable IP ranges, TLS certificates, open ports) and works backward to attribute those observations to your organization, whether or not anyone told the security team they existed.
This outside-in orientation is the whole point. Shadow IT, M&A leftovers, contractor-provisioned infrastructure, and expired-but-still-resolving subdomains all share one trait: they were never entered into an internal system of record. A tool that only reads from your CMDB or cloud API will never surface them because there is nothing to read. EASM has to go find them the way an attacker would, through reconnaissance against the public internet, not through a query against your own records. This is why attack surface management is usually run as a distinct discipline from internal asset inventory rather than folded into the same tool: the discovery method and the source of truth are fundamentally different.
Four Asset Classes an EASM Program Has to Track
A useful way to scope an EASM program is by the four classes of evidence it correlates back to your organization. Each class answers a different question, and losing any one of them creates a blind spot.
| Asset class | What it tells you | Typical drift problem |
|---|---|---|
| Domains and DNS records | Which hostnames resolve, and to what | Dangling CNAMEs pointing at deprovisioned cloud resources |
| IP ranges and ASN ownership | Which network blocks are actually yours | Legacy allocations from a decommissioned data center still routed |
| TLS/SSL certificates | Which endpoints present a cert issued for your domains | Wildcard certs reused on infrastructure nobody tracks anymore |
| Running services and ports | What is actually listening, and what version it is running | An admin panel or database port exposed after a firewall rule change |
Domain and DNS tracking is the backbone because almost every other asset class is reachable through a hostname first. IP and ASN ownership matters separately because plenty of exposed services sit on bare IPs with no DNS record at all, particularly in cloud environments where ephemeral addresses get reused across tenants; this is also where EASM overlaps with network reachability testing, since owning an IP block and being able to reach a service inside it from the internet are two different questions. Certificate tracking catches assets that rotate IPs and hostnames but keep reusing the same issuing CA and subject alternative names. Service and port enumeration is the layer that turns “this hostname exists” into “this hostname is running an outdated version of a service with a known CVE,” which is the point where EASM output becomes actionable for a vulnerability program rather than just an inventory exercise.
What EASM Is Not
Two misconceptions cause the most wasted budget. First, EASM is not a replacement for a CMDB. A CMDB records intent and ownership: who requested the asset, what business function it serves, what change window applies. EASM records observation: what is visible from outside, right now, regardless of whether anyone documented it. The two are complementary. Feeding EASM findings back into the CMDB (or at minimum cross-referencing them) is how you close the gap between “documented” and “real,” but the EASM tool itself has no concept of a change ticket or a service owner unless you build that mapping.
Second, EASM is not a point-in-time audit. A single scan of your domains and IP ranges, run once a year for a compliance checkbox, produces a snapshot that is stale within days. Certificates get issued for new subdomains during a marketing campaign, DNS records get created and forgotten, cloud resources spin up and tear down on their own schedule. If the only artifact you have is a PDF from last quarter’s assessment, you have a historical document, not an attack surface management program. The word “management” implies an ongoing loop: discover, attribute, monitor, and re-check, indefinitely.
Where the Discovery Data Actually Comes From
EASM tooling does not invent visibility out of nothing. It aggregates and correlates a handful of public and semi-public data sources, and understanding those sources helps you sanity-check a vendor’s coverage claims or build your own discovery pipeline.
- Domain registrars and TLD zone files give you the registered domain and its registration metadata, useful for catching typosquats and abandoned brand domains that still resolve.
- Certificate Transparency (CT) logs are the single richest source for subdomain discovery. Every publicly trusted certificate issued since roughly 2018 is logged in an append-only, publicly queryable ledger. Querying CT logs for any certificate containing your domain as a subject alternative name surfaces subdomains long before they show up in any other channel, including ones that were issued for infrastructure that was later torn down but never had the DNS record removed.
- Passive DNS databases record historical resolution data collected by sensors sitting on recursive resolvers. This is what lets you see that a subdomain resolved to a particular IP six months ago, even if it no longer resolves to anything today, which matters for attributing an old IP block back to your organization.
- WHOIS and RIR records (ARIN, RIPE NCC, APNIC, LACNIC, AFRINIC) establish IP block and ASN ownership. Cross-referencing your organization’s registered ASN against BGP-announced prefixes tells you which IP ranges are actually routed right now, as opposed to ranges you were allocated but never announced.
None of these sources is sufficient alone. CT logs miss internal CAs and self-signed certificates. Passive DNS coverage varies by provider and geographic region. WHOIS data is increasingly redacted post-GDPR, which pushes more of the attribution work onto certificate and DNS correlation instead. A discovery pipeline that only pulls from one source will have systematic blind spots that map directly to that source’s limitations, not to your actual exposure.
Connecting EASM Output to a Remediation Workflow
Discovery without a path to remediation just produces a longer list nobody acts on. Three mechanics turn an EASM finding into a closed ticket instead of permanent backlog, and they are the same mechanics that separate a working vulnerability lifecycle process from a spreadsheet that grows every quarter:
- Ownership assignment. Every discovered asset needs an owner before it needs a severity score. Attribution logic (matching a subdomain to a team by naming convention, matching an IP block to a business unit by RIR registration, matching a certificate’s organization field to a cost center) has to run automatically, because manual triage of a growing asset list does not scale past a few hundred entries.
- SLA by exposure class, not just CVSS score. An internet-facing admin panel with no authentication and a critical CVE needs a same-day SLA. A newly discovered marketing subdomain with an outdated but non-exploitable TLS cipher suite can sit on a 30 or 60 day SLA. Binding remediation timelines to exposure context, not only to the underlying vulnerability’s base score, keeps the queue realistic.
- Verification, not self-reporting. A ticket marked “resolved” by the team that closed it is a claim, not a fact. Platforms that automate this phase, such as SITEY, re-scan the specific finding after the fix window closes rather than trusting the closure comment, which catches the common failure mode where a firewall rule change hides a service instead of actually patching or decommissioning it.
The internal link between discovery and workflow is where most EASM deployments actually fail in practice. Vendors sell the discovery half aggressively because it demonstrates the “we found things you didn’t know about” moment in a sales call. The workflow half, ownership mapping, SLA enforcement, and closed-loop verification, is less visible in a demo but is what determines whether the exposed asset gets fixed in a week or sits unpatched for a year because the ticket had no clear owner.
The Maturity Signal: Delta Tracking, Not Quarterly Snapshots
The clearest indicator of whether an EASM program has actually matured past a compliance exercise is the reporting cadence its team actually looks at. A quarterly PDF that lists every current asset is a snapshot; it tells you the state of the world on one day. A delta feed that surfaces only what changed since the last scan (new subdomain appeared, certificate rotated to a different issuer, a previously closed port reopened) is what an operations team can actually act on daily. Platforms that fold EASM discovery into a broader vulnerability pipeline, such as SITEY, route each newly discovered asset straight into the same triage and SLA rules as any other finding, so a subdomain that appeared yesterday does not sit in a separate spreadsheet waiting for someone to notice it.
Set the discovery cadence based on how fast your DNS and certificate estate actually changes, not on an arbitrary calendar. Organizations running frequent marketing campaigns or using infrastructure-as-code with short-lived environments should run discovery daily; a smaller, slower-moving estate can run weekly without missing much. What matters is that the output is framed as “these 4 assets are new since Tuesday” rather than “here are the 1,200 assets we found,” because the second framing forces a human to manually diff two exports before knowing what actually needs attention, and that manual diffing step is exactly where drift goes unnoticed for months.
A practical threshold worth adopting: any certificate expiring within 30 days on a discovered-but-unowned asset should generate an alert independent of the regular scan cycle, since certificate expiry on infrastructure nobody is actively tracking is a leading indicator of an asset that has been silently abandoned rather than decommissioned. Combined with continuous CT log monitoring and a same-day alert for any newly observed service on a previously unseen port, this is what separates a program that catches exposure within hours of it appearing from one that finds out at the next quarterly review, often well after the window an opportunistic scanner would need to find it first.
About SITEY
SITEY is an autonomous vulnerability management platform. It discovers, validates, prioritizes, remediates and re-tests vulnerabilities through an eight-phase automated pipeline, unifying output from 17 integrated scanners. SITEY is self-hosted: it runs in your own infrastructure and your findings are stored there. Outbound connections are limited to licence activation and the optional services you enable, such as an AI provider, CVE enrichment and patch catalogues. Pricing is 599 USD per month or 5,999 USD for a perpetual lifetime license. See pricing or how the platform works.