Exposure · External attack surface management

External attack surface management (EASM) that starts from what answers, not from your list.

ShadowMap rebuilds your external estate every 24 hours from the outside — domains and subdomains, open ports and service banners, web and API stacks, mobile binaries, cloud storage, certificates — and ranks each finding by what an attacker could reach with it. No agents, no allowlists, no cooperation from the asset owner required.

Request an exposure snapshot How to evaluate this

app.shadowmap.com/org/acmecorp/attack-surface

24h

Full external rediscovery cycle

Seedless

No seed list, no scope file, no inventory to hand over

CERT-In

Empanelled auditor since 2008 — Security Brigade

30–60%

More external assets surfaced than internal inventory held

A band observed across first scans, not a promise — it runs lower in organisations with a mature configuration record and higher where the estate arrived through acquisition or an engineering team that ships faster than governance can track. The delta is not the interesting number anyway. What matters is how few of the new assets are reachable, and which of those were never meant to be.

The delta

Where the declared estate and the observed estate come apart

Reconciliation is only useful if it runs in both directions. These are the places the two views disagree, what each one can see, and where the disagreement was actually measured.

Where assets go missing	Declared inventory and agent-based tooling	Outside-in discovery
Cloud accounts outside central enrolment	Invisible. Posture tooling covers the accounts inside your management organisation, and an unenrolled account is not so much unmonitored as unmonitorable.	Found by response. An account nobody enrolled still answers on the public internet, and answering is the only qualification discovery requires.
Anonymised logistics-technology engagement, first 30 days, 2026: 21 of 109 cloud accounts, projects and subscriptions sat outside central enrolment, all inherited through two acquisitions.
Ephemeral and preview environments	Created by automation and destroyed by convention. Nothing in the record notices the ones that were not destroyed.	Every responding front door is discovered on its own terms, whatever created it and whatever was supposed to remove it.
Same engagement: 148 pull-request preview environments were still publicly reachable past their fourteen-day teardown window, the oldest at 620 days.
Estates arriving through acquisition	Enters the record when somebody migrates it, which in practice is after the clinical, revenue or ERP systems — sometimes years after.	Discovered outward from the apex domain. No cooperation from the acquired IT team, and no seed list from them, is required.
Anonymised hospital-group engagement, 2026: nine of fourteen sites joined by acquisition over eleven years, and two acquired diagnostic brands were still serving patient report downloads on their original domains and original certificates.
Hosts switched off but never retired	Still listed, still counted, still inflating the compliance picture with systems that stopped existing.	Recorded as no longer responding — a correction the register cannot generate about itself.
Logistics engagement: 173 of 540 recorded internet-facing entries no longer responded at all. False assurance is a discovery finding, not a rounding error.
Origin servers behind a WAF or CDN	Not an inventory question at all. The record names the service; it does not name the address that answers when the edge is stepped around.	Found by virtual-host probing against candidate origins, and raised as its own finding type rather than buried in a note.
Product behaviour rather than an engagement finding — the one row here that is not a count. It gets its own finding type because the asset at risk is the origin, not the hostname the record already knows. The mechanism, and the limits of its coverage, are set out in the next section.
Brand-carrying assets on infrastructure you do not own	Out of scope by definition. You cannot inventory a host that belongs to a partner, a franchisee or an agency.	Surfaced and labelled references your organisation — confirm before acting. ShadowMap does not adjudicate ownership.
Logistics engagement: 60 hostnames carried the group brand on carrier partners' infrastructure. Surfaced, labelled and routed for confirmation — never counted as the customer's own.

Cloud accounts outside central enrolment

Declared inventory and agent-based tooling: Invisible. Posture tooling covers the accounts inside your management organisation, and an unenrolled account is not so much unmonitored as unmonitorable.
Outside-in discovery: Found by response. An account nobody enrolled still answers on the public internet, and answering is the only qualification discovery requires.

Anonymised logistics-technology engagement, first 30 days, 2026: 21 of 109 cloud accounts, projects and subscriptions sat outside central enrolment, all inherited through two acquisitions.

Ephemeral and preview environments

Declared inventory and agent-based tooling: Created by automation and destroyed by convention. Nothing in the record notices the ones that were not destroyed.
Outside-in discovery: Every responding front door is discovered on its own terms, whatever created it and whatever was supposed to remove it.

Same engagement: 148 pull-request preview environments were still publicly reachable past their fourteen-day teardown window, the oldest at 620 days.

Estates arriving through acquisition

Declared inventory and agent-based tooling: Enters the record when somebody migrates it, which in practice is after the clinical, revenue or ERP systems — sometimes years after.
Outside-in discovery: Discovered outward from the apex domain. No cooperation from the acquired IT team, and no seed list from them, is required.

Anonymised hospital-group engagement, 2026: nine of fourteen sites joined by acquisition over eleven years, and two acquired diagnostic brands were still serving patient report downloads on their original domains and original certificates.

Hosts switched off but never retired

Declared inventory and agent-based tooling: Still listed, still counted, still inflating the compliance picture with systems that stopped existing.
Outside-in discovery: Recorded as no longer responding — a correction the register cannot generate about itself.

Logistics engagement: 173 of 540 recorded internet-facing entries no longer responded at all. False assurance is a discovery finding, not a rounding error.

Origin servers behind a WAF or CDN

Declared inventory and agent-based tooling: Not an inventory question at all. The record names the service; it does not name the address that answers when the edge is stepped around.
Outside-in discovery: Found by virtual-host probing against candidate origins, and raised as its own finding type rather than buried in a note.

Product behaviour rather than an engagement finding — the one row here that is not a count. It gets its own finding type because the asset at risk is the origin, not the hostname the record already knows. The mechanism, and the limits of its coverage, are set out in the next section.

Brand-carrying assets on infrastructure you do not own

Declared inventory and agent-based tooling: Out of scope by definition. You cannot inventory a host that belongs to a partner, a franchisee or an agency.
Outside-in discovery: Surfaced and labelled references your organisation — confirm before acting. ShadowMap does not adjudicate ownership.

Logistics engagement: 60 hostnames carried the group brand on carrier partners' infrastructure. Surfaced, labelled and routed for confirmation — never counted as the customer's own.

The sharpest case

The origin your CDN was hiding

Our red teams kept running into the same thing by hand: an application published through a WAF, and an origin server that will serve the identical application directly to anyone who knows the address. It stopped being a manual technique and became a finding type.

How the finding is produced

One customer portal, published through a CDN

What the edge presents: The hostname resolves to the CDN. Requests pass the WAF, headers are normalised, rate limits apply, and an external scanner pointed at that hostname is assessing the edge. Every result it returns is true. None of it describes the server doing the work, and the difference only matters on the day somebody stops asking politely.
What the origin answers: Candidate addresses assembled from historic DNS, certificate transparency, hosting neighbourhood and public scan data are probed with your hostname supplied in the request. Where an address serves the same application directly, the WAF is not in the path at all. The same probing surfaces virtual hosts with no DNS record of their own — internal consoles and staging applications published on a shared address, reachable by anyone who asks for them by name.
What the record shows afterwards: Two named finding types carry it — origin_exposure and internal_application_exposure — each holding the origin address, the hostname it answered for, and the evidence that both served the same application. Probe coverage is recorded per host, so an address nobody reached reads as unprobed rather than as clean and the gap is something you can see instead of something you have to assume. Where it is safe and authorised, Continuous Automated Red-Teaming then assesses the origin itself and reports what the edge was hiding.

The definition

What external attack surface management actually measures

EASM is the discipline of establishing, from outside your network and without your cooperation, which of your systems can be reached today. The word carrying the weight in that sentence is outside.

A configuration database and an authenticated scanner are both good instruments, and neither answers this question, because both begin from a list somebody inside the organisation maintains. A CMDB is a record of intent: accurate at the moment of provisioning and decaying from that moment, with no access to ground truth. A scanner is an instrument of execution against a scope it was handed. So is a seeded attack surface product — hand it a list of domains and it inherits the same blind spot one layer down. In one engagement the incumbent tool had been given 34 domains by hand; nobody had ever told it about either acquisition. Discovery inverts the order: it starts at an apex domain, works outward through the public registration, naming and certificate record to the subsidiaries, brands and acquired entities underneath it, and keeps only what actually responds. Cloud accounts are read from the provider directly where you choose to connect them, but nothing in that path depends on it. What comes back is not a tidier version of your list. It is a different kind of object — an observation, which can disagree with the record, and reliably does in both directions.

Coverage

What stays under continuous attack surface monitoring

Discovery is not a single technique. These run continuously against the estate as it is rediscovered, and each contributes findings into one correlated exposure model rather than into a console of its own.

Discovery

Subdomains and DNS

Passive and active enumeration across registrar records, DNS, certificate transparency and reverse DNS. This is what catches the orphan subdomain marketing stood up last quarter, and the wildcard nobody remembered was still delegated.

Discovery

Open ports and service banners

Daily port scanning with banner capture across the discovered estate. The banner matters as much as the port: a service you already knew about, answering on a version you did not, is the finding that periodic scanning is worst at producing.

Fingerprinting

Web applications, APIs and front-end scripts

Technology-stack detection on every responding web property, including the third-party JavaScript loaded into your own pages. Knowing an application runs WordPress 6.2 rather than 6.7 is what decides which CVEs are actually yours.

Inventory

Mobile applications

Play Store, App Store and side-loaded marketplaces monitored for applications carrying your name — the ones you published, and the ones you did not. Most attack surface management tools treat mobile as an add-on; here it is part of the estate.

Posture

Cloud storage and certificates

Misconfigured S3, GCS, Azure Blob and Spaces buckets matched against your attributed inventory, alongside expired, weak and wildcard-leaking certificates with the renewal path attached to the finding.

Reconciliation

A two-way diff against your own record

A first-class comparison against the ServiceNow CMDB, not an asset-list export left for you to diff yourself. Your record is an input to that comparison and never the scope of the discovery — which is the only reason the comparison is worth reading in the second direction as well as the first.

Correlation

Correlation that makes the queue smaller

Almost every product in this category claims correlation that surfaces more. The version worth paying for is the one that surfaces less and can show you exactly what it set aside, and why.

From 1,286 responding hostnames to 19 items of week-one work As of Anonymised logistics-technology engagement, first 30 days, 2026

1,286 hostnames responded to probing across the group estate. That is the raw discovery number, and on its own it is a worse answer than no answer, because it converts into 1,286 unread rows.
Served-content fingerprinting collapsed those to 572 unique logical applications. A single wildcard used by the sales demo fleet accounted for 430 hostnames resolving to three applications — recorded rather than deleted, because each remained a separate front door with its own build.
Unattributable addresses are resolved by what they serve. An IP with no DNS name of its own is matched on content, certificate and technology against applications already attributed, and where it turns out to be a second front door on something known it is downgraded to a property of that application instead of being raised as a new asset.
Reconciliation against the configuration record isolated 205 running applications with no entry of any kind. Among them were an internal admin console for carrier onboarding, a partner tariff API, a legacy dispatch interface belonging to an acquired business, and a Kibana instance fronting operational logs.
63 applications carried strong signal against the published test, and 19 were surfaced for action in week one. Roughly 68 responses to one piece of work — and every step above is reproducible against the same estate.

Deliberately excluded

The signal test is published rather than applied silently: an application is surfaced if it returns real content, or if its hostname or certificate indicates a sensitive function.
Hosts returning only an edge block page or an empty body are filtered as noise — and still counted, because a host that 404s discloses its server version and its certificate.
Filtered items stay visible and reviewable. Nothing is deleted, and the reasoning is retained against each item, so a downgrade is something you can argue with rather than something you have to trust.
Assets on third-party infrastructure carrying your brand leave this funnel in both directions: never downgraded on your behalf, and never counted as yours either. They reach you as a judgement to make, not as a number.

The loop

Discover, attribute, prioritise, route

Each step depends on the one before it. Attribution is meaningless without discovery, prioritisation is meaningless without attribution, and routing is the step that turns the whole thing from a report into work somebody finishes.

Discover

Start from an apex domain, keep what answers

The input is an apex domain. Discovery fans out from it to the subsidiaries, brands and acquired entities beneath it, and keeps only what answers when probed — nobody has to describe the estate for it to be found. The whole surface is then rebuilt every 24 hours and diffed against yesterday, and the diff is the deliverable rather than the inventory: a new port on a known host is a same-day alert, not a line in next quarter's report.
Attribute

Establish whose it is before calling it yours

Responding hosts are grouped into logical applications by served content, certificate subject, technology stack and hosting neighbourhood, then reconciled against your own record in both directions. Assets carrying your name on infrastructure you do not own are labelled for confirmation rather than absorbed into your count.
Prioritise

Rank by what is reachable, not by what scores highest

Each finding is scored on the joint signal of severity, exploit availability and the criticality of the asset it sits on. Where it is safe and authorised, Continuous Automated Red-Teaming assesses the finding directly, and the result is recorded against it — including a confirmed negative, which demotes the finding without deleting the reasoning. Not every finding is validated, and the ones that are not say so on their face.
Route

Into the board the owning team already reads

Ownership is derived from cloud resource tags where they exist and falls back to the platform team where they do not. A discovered service becomes a ticket in Jira or ServiceNow, a message in the owning team's own Slack channel, and an event in your SIEM. The SLA clock starts at discovery rather than at triage, so a slow triage is visible instead of invisible.

Where this gets sharper

Attack Surface Management works from one correlated exposure model

Continuous Automated Red-Teaming Origin-server and virtual-host detection finds the infrastructure behind your WAF; that origin is then assessed where authorised, surfacing what the edge was hiding. Brand Protection Your logos, sites, infrastructure patterns and technology stack inform impersonation signatures and cut false positives in a broad phishing dataset.

Questions buyers actually ask

Before you evaluate this

Is EASM the same thing as external vulnerability scanning?

No, and the difference is the scope rather than the checks. External vulnerability scanning executes a set of tests against hosts you supply. It is good at that, and it inherits every gap in the list it was handed. External attack surface management establishes the list itself — from outside, continuously, and without your cooperation — then keeps re-establishing it as the estate changes. Scanning is a verb applied to a scope. EASM is how the scope stops being wrong. Organisations that run both usually find the second one changes the input to the first within a month.

We already have a CMDB and cloud posture tooling. What does this add?

Both are records of enrolment. Posture tooling covers the accounts inside your management organisation; a configuration database covers what somebody remembered to register. The part of the estate that hurts you is outside both: cloud accounts that arrived with an acquisition and were never enrolled, pull-request environments that outlived the pull request, marketing properties commissioned through an agency, and services switched off years ago and still on the register. Outside-in discovery needs none of it declared, because the only question it asks is what responds.

How do you find an origin server sitting behind our WAF?

By probing candidate origin addresses — drawn from historic DNS, certificate transparency, hosting neighbourhood and public scan data — with your hostname supplied in the request. Where one of them serves your application directly, the edge is not in the path, and it is raised as an origin exposure in its own right. Two things are worth checking when anyone offers you this. Whether the probing is bounded by the scope you authorise, so that an address outside it is recorded as unprobed rather than quietly counted as clean. And whether the same technique also returns virtual hosts published on a shared address with no DNS record of their own — that second case is usually where the internal consoles are.

How should we evaluate attack surface management tools against each other?

Give each of them the same single apex domain and nothing else — no seed list, no allowlist, no help from your team — and then compare three things rather than one. What did each find that your record did not hold? What did each set aside, and can it show you the reasoning? And what did each do with assets that carry your brand but sit on infrastructure you do not own? A product competing on the size of the number it returns in week one is competing on the wrong axis. The number you are buying sits at the end of the funnel, and the argument for it should be reproducible by somebody who does not work for the vendor.

See the part of your external estate you have never been shown

One apex domain is the entire input. No seed list, no allowlist, nothing to install — and a written inventory you can lay beside your own record.

Request a proof of concept See Pricing