The choice between EASM vs vulnerability scanning is usually presented as a technical argument, and it almost never is one. It is a sequencing decision made by someone with a single budget line, a patching backlog, and an auditor asking for evidence by a fixed date. The useful question is not which tool is better. It is which one you buy first, what the second one costs once the first is in place, and which findings you will still be missing after both invoices are paid.
The two different questions these tools answer
External attack surface management answers one question: what of ours is reachable from the internet, and has that changed since yesterday? It starts from a seed, typically a domain and an organisation name, and expands outwards through certificate transparency logs, DNS records, WHOIS and registration data, IP allocations and cloud ranges, building a list of things that appear to belong to you. The output is an inventory with evidence attached.
Vulnerability scanning answers a different question entirely: on the hosts I have already told you about, which known CVEs and weak configurations can be proven present right now? You supply the targets. The scanner supplies the depth.
Commercially, that distinction decides everything. One product grows your asset list; the other deepens the detail on a list you hand over. Buy the deepening tool when the list is wrong and you have purchased precision about the wrong things.
The failure mode is quiet. A scan report comes back with nine mediums and two highs, all patched inside the SLA, and everyone signs it off. Nobody asks what share of the public estate the scope covered. If the target list was built from a spreadsheet last refreshed before the rebrand, the report might be immaculate across sixty per cent of what you actually expose, and silent about the rest. A clean scan report is a statement about scope, not about safety. Ask your provider, or your own team, what percentage of the public estate the scope covers. Most organisations cannot answer, and the inability to answer is itself the finding.
Passive observation versus active testing: what a result actually proves
External discovery is mostly passive. It reads what the internet already publishes about you: TLS certificates logged when they were issued, DNS records, HTTP response headers, service banners, the shape of a TLS handshake. From those signals it infers a software version, matches that version against a CVE list, and reports that the host is likely affected. It has not tested the flaw.
Active scanning sends the probe that settles the matter. That is a more informative result and a heavier one to operate: it needs written authorisation, a maintenance window for anything fragile, change control sign-off, and a conversation with whoever runs the load balancer. Passive observation needs none of that, which is exactly why it scales across assets you did not know you owned.
Inference goes wrong in dull, repeatable ways. Debian and Red Hat backport security fixes without changing the version string, so a fully patched host advertises a version that CVE databases consider vulnerable. Reverse proxies and WAFs rewrite or strip banners, so the version you see belongs to the proxy, not the origin. A load-balanced pool can answer from a patched node on Tuesday and an unpatched one on Wednesday. Treat “likely affected”as a work item for confirmation, not as an incident. The deeper mechanics of that gap are covered in the piece on likely versus definitely as a working distinction.
Used together, the sequence is straightforward. Discovery narrows the candidate list to the handful of hosts worth testing, active scanning confirms or clears them, and nobody declares a priority one based on a banner.
Findings one tool returns and the other never will
There is overlap in the middle and clear territory at each edge. Knowing the edges is how you decide what you are buying.
What only external discovery surfaces
Dangling CNAMEs pointing at decommissioned cloud resources. Forgotten staging hosts and campaign microsites nobody renewed ownership of. Certificates that expired on a subdomain no internal team claims. Administrative interfaces and management ports answering on a public IP behind no allow-list.
Dangling DNS is the cleanest illustration of a finding that sits outside a scanner’s job. A marketing subdomain whose CNAME still points at a deleted storage bucket returns nothing a CVE check would flag, because there is no software there to be vulnerable. Anyone who registers the matching bucket name serves content on your subdomain, under your certificate chain, with your brand on it. The fix is a DNS record deletion, not a patch, and it takes minutes once someone knows. The mechanics of subdomain takeover are worth reading before you argue the case internally, because the objection you will get is “a scanner would catch that”, and it would not.
Expired certificates arrive the same way. Certificate transparency logs record every issuance, which means they also record every renewal that never happened, on hosts your inventory forgot.
What only vulnerability scanning gives you
Authenticated checks, where the scanner logs in and reads installed package versions rather than guessing from outside. Internal hosts that are not reachable from the internet at all. Patch-level confirmation across a known estate, host by host. And evidence in a format a compliance assessor will accept, which is not a small thing when a contract renewal depends on it.
What neither scores well on its own
Default credentials on a reachable management console. An open directory listing exposing a backup archive. A test environment loaded with a copy of live customer data. A legacy host answering on port 23 with a Telnet banner. None of these is exotic. They are the ordinary sediment of an organisation that has moved quickly, and most of them carry no CVE, so severity scoring handles them badly in both products.
Which is why raw severity is a poor queue. A CVSS 9.8 on a static brochure site with no credentials, no data and no onward network path matters less than a 5.3 on an internet-facing VPN appliance that terminates staff sessions. Exposure and asset value do the sorting; the score is one input among several.
Which one to fund first, by situation
Fund discovery first when the asset register is not trustworthy. The signs are familiar: a recent acquisition whose infrastructure nobody has mapped, a rebrand that left two generations of domains live, marketing or individual business units buying their own hosting on a card, or the simple fact that nobody can name every public IP range the organisation owns. In those conditions a scanning contract buys precision about a list that is wrong, and you will not find out for a year.
Fund scanning first when the inventory genuinely is current, patching is the known weak point, and the gap between a vulnerability being published and remediated is measured in weeks. If you already maintain an inventory with owners recorded against each internet-facing asset, discovery will mostly confirm what you have, and depth is the better spend.
The compliance forcing functions
For many UK organisations the argument is settled before it starts. Cyber Essentials Plus includes external vulnerability testing as part of the hands-on technical audit, as set out by the NCSC’s Cyber Essentials scheme. Organisations handling cardholder data face PCI DSS, which requires external vulnerability scans at least quarterly by an Approved Scanning Vendor under the PCI Security Standards Council programme. Check the current scheme requirements before you plan a cycle, as both are revised periodically.
The practical consequence: the scanning spend is often contractually fixed and the discovery spend is the discretionary one. That does not make discovery optional. It means you should stop arguing scanning versus EASM in the abstract and start arguing about what the fixed scan is scoped against.
A self-test that takes an hour
Can you produce a current list of your internet-facing assets in under an hour, with a named owner for each one, and defend it? Not a list of what should be there. A list of what is answering today. If the honest answer is no, discovery is the first purchase, whatever the renewal calendar says.
Running both without paying twice or doubling the noise
Buying both tools without joining them creates a third problem. Two queues of findings, two severity scales, two owners for the same host, and a weekly meeting about whose number is right. Alert volume does not motivate people; it trains them to ignore both systems.
Decide up front which system holds the asset of record. In most setups that is the discovery platform, because it sees new assets first. Confirmed discoveries then feed scan scope, so coverage follows the estate rather than last year’s spreadsheet, and the quarterly scan covers the subdomain that went live in March.
Attribution is where teams get sloppy. External discovery returns candidates, not certainties: a certificate transparency entry or a DNS record suggests an asset may be yours. It is an inference, not a confirmed fact. Somebody has to confirm ownership before anything is scanned or ticketed, because shared hosting, agency-run sites and similarly named third parties all show up in the same result set. Skipping that step is how an organisation ends up actively probing infrastructure it does not own.
Then set cadence by what the control is for. Continuous change detection on exposure, because new assets appear without warning and a point-in-time view drifts out of date the moment it is taken. Scheduled depth scanning on confirmed hosts, aligned with the compliance cycle you are already paying for. One issue, one ticket, one owner. Suppress expected states, such as the port you deliberately leave open, so that the exceptions stay visible.
Questions to ask before you sign either contract
- Discovery technique and seeds: which sources are queried, how many hops of expansion, and how candidate assets are confirmed as yours rather than assumed.
- Data freshness: how long between a new subdomain or newly opened port appearing and it showing in the console, and whether that is genuinely continuous or a scheduled sweep described as continuous.
- Prioritisation logic: what the ranking considers beyond CVSS, and how exposure findings with no CVE are scored at all.
- Active testing: included, charged separately, or your responsibility. Get this in writing; it is the single most common misunderstanding at renewal.
- Workflow fit: ticketing integration, ownership mapping, and whether the reporting is something a board or an assessor will accept without rework.
Two objections tend to stall approval, and both are answerable. External attack surface management does not exploit systems; it observes what is already published and infers from it. And looking at your own estate from the outside does not make you a target: certificate transparency logs, DNS and port scan data are public and already being read by people who are not you. A longer version of this evaluation sits in the practical checklist for choosing an EASM product.
The Short Version
- EASM grows the asset list; vulnerability scanning deepens detail on the list you supply. The weaker your inventory, the more the first matters.
- A clean scan report describes scope, not safety. Ask what share of the public estate was in scope.
- Passive fingerprinting returns “likely affected”. Backported patches, proxies and WAFs make it wrong in both directions, so confirm before escalating.
- Dangling DNS, expired certificates and exposed admin interfaces are discovery findings with no CVE attached, and some outrank your mediums.
- Cyber Essentials Plus and PCI DSS ASV scanning often fix the scanning spend regardless of the technical argument. Fix what it is scoped against.
- If you run both, name one system as the asset of record and route everything to one ticket per issue.
Frequently Asked Questions
Is EASM a replacement for vulnerability scanning?
No. External attack surface management tells you what is exposed and whether that has changed; vulnerability scanning proves what is wrong on hosts you already know about, including authenticated checks a passive view cannot perform. They answer different questions, and the overlap in the middle is smaller than vendor material on either side suggests.
If I can only fund one this year, should it be EASM or vulnerability scanning?
Judge it on your inventory. If you cannot produce a current list of internet-facing assets with named owners in under an hour, fund discovery, because scanning an incomplete list buys confidence you have not earned. If the inventory is sound and patch debt is the known problem, fund scanning.
Does EASM find things a vulnerability scanner cannot?
Yes, and the clearest example is a CNAME still pointing at a deleted cloud resource. There is no software present, so no CVE check fires, yet anyone can claim the dangling target and serve content on your subdomain. Forgotten staging hosts, expired certificates and unrestricted admin interfaces fall into the same category.
Can EASM satisfy Cyber Essentials Plus or PCI DSS scanning requirements?
Not on its own. Cyber Essentials Plus includes hands-on external vulnerability testing as part of the audit, and PCI DSS requires quarterly external scans by an Approved Scanning Vendor, both of which expect specified testing by a recognised party. Discovery output is valuable for defining the scope of that testing, but it is not a substitute for it; confirm current requirements with your certification body or ASV.
Does running EASM against my own estate make me more visible to attackers?
No. The sources used, certificate transparency logs, DNS records, registration data and public scan data, are already published and already being read by people with less friendly intentions. Looking at your estate the way an attacker does, from the outside, changes what you know, not what they can see.