What EASM actually finds, and when you need it
External attack surface management finds the internet-facing assets your organisation owns but has never written down: the subdomain from a campaign three years ago, the portal a supplier built and still hosts, the servers that arrived with an acquisition. In Quarter 2 of 2026 alone, 353 mergers and acquisitions involving UK companies completed. Every one of them merged two asset inventories at speed, and inventories do not merge cleanly.
Your asset list is wrong, but probably not because anyone was careless. It is a snapshot of something that changes every time the business does anything.
The events that break your inventory
Unknown assets are not random. They are produced, reliably, by ordinary business activity. These are the events worth recognising, because each one leaves a specific kind of thing behind.
| The event | What it leaves exposed | Why your scanner misses it |
|---|---|---|
| An acquisition | Domains, cloud accounts, VPN endpoints and remote access built to someone else’s standard | The scan scope was written before the deal completed, and nobody re-wrote it |
| Decommissioning that stopped halfway | DNS records still pointing at cloud IPs that have been released back to the provider | The record resolves; the asset is no longer yours. Nothing on your list changed |
| A marketing campaign | A microsite on agency hosting, under your brand, with your logo and an old CMS | It was bought on a marketing budget and never entered IT’s records |
| Cloud spend outside IT | A subscription opened on a departmental card, running something in production | It is in nobody’s tenant inventory because it is nobody’s tenant |
| A supplier-built portal | An application your customers use, hosted and patched by a third party, or not patched | You do not operate it, so it is not in your CMDB. It is still your name on it |
| A certificate issued and forgotten | A hostname you no longer use, published permanently in public certificate transparency logs | Certificates are issued by whoever needs one, not by whoever keeps the list |
| Staff signing up to SaaS | Company data in a service procurement never saw; the NCSC calls this shadow IT | There is nothing to scan. The exposure is the account, not the host |
The pattern is the point. Traditional vulnerability scanning works from a list you supply, so it can only ever check what you already know about. EASM works the other way round, outside in, from the attacker’s view of your name, which is why it finds the things the list is missing.
Find some of it yourself this evening
You do not need to buy anything to start. Public certificate transparency logs record almost every TLS certificate ever issued, including the ones issued for hosts you have forgotten, and they are free to search. It takes about twenty minutes.
Query the logs. Search
crt.shfor%.yourdomain.co.uk. You will get every hostname a public certificate has ever been issued for.Resolve each one. Anything that still resolves is still pointing somewhere. Anything that does not is a record you can tidy.
See what answers. Request each host over HTTPS and note what comes back. A 200 from something you did not know existed is the finding.
Compare against your asset list. The gap between the two is your starting position.
What it will not give you is IP ranges with no certificate, services on non-standard ports, assets under domains you did not think to search, or anything owned by a supplier. That is the gap a managed EASM service fills, but do the free version first, because it tells you how big your problem is before you pay anyone to size it.
What EASM finds that a vulnerability scanner does not
The NCSC’s EASM buyer’s guide makes a distinction that gets lost in vendor material: EASM products report issues, not just vulnerabilities. A CVE is one kind of finding. Most of what EASM surfaces has no CVE at all:
- Dangling DNS records: a
CNAMEpointing at a cloud service you no longer own, which someone else can claim and serve content from under your domain. - Exposed services that should be internal: databases, management interfaces and remote access answering to the whole internet rather than to your network.
- Email security gaps: missing or permissive SPF, DMARC and MTA-STS records, which is how your domain gets used to phish your own customers.
- Certificate problems: expiring certificates, certificates issued for hosts nobody recognises, weak configurations.
- Unsupported software reachable from outside, which is a finding even on the day there is no exploit for it.
- Suppliers you did not know you depended on: the third-party scripts, mail providers and cloud services your estate actually relies on.
None of those appear on a patch list, and all of them are ways in.
EASM, vulnerability scanning, and a penetration test
Three different purchases, routinely confused:
| Attack surface management | Vulnerability scanning | Penetration test | |
|---|---|---|---|
| Question it answers | What do we have exposed? | What is wrong with the things we have? | Can someone actually get in, and how far? |
| Works from | Your name, outside in | A list of assets you supply | An agreed scope and a human tester |
| Cadence | Continuous, with daily discovery | Continuous or scheduled | Point in time |
| Finds unknown assets | Yes. That is the point | No | Only if scoped to look |
| Proves exploitability | No | No | Yes |
They compose rather than compete. Discovery without remediation is a longer list; scanning without discovery is a well-maintained blind spot. If you want the scanning-versus-testing distinction in full, we have written it up separately in penetration testing vs vulnerability scanning, and the prioritisation side in what continuous vulnerability management actually means.
The order matters. Discovery feeds scanning, scanning feeds remediation, and testing validates the exposures that look serious. CISA’s Known Exploited Vulnerabilities catalogue listed 1,760 entries as of 27 October 2026. Knowing which of your assets carry one of them requires knowing what your assets are first.
When you actually need a product
Look hard at your own position before you buy.
You probably do not need one yet if you run a single domain, a handful of internet-facing services, and one cloud tenant that IT controls. Do the certificate transparency exercise above once a quarter, keep your DNS tidy, and put the money into remediation instead.
You probably do need one if any of these are true: you have acquired a company in the last two years; your cloud spend is devolved to departments; you have a supplier-hosted customer portal; your estate spans more than a couple of domains; you have been through a rebrand; or you cannot produce a current list of your internet-facing services in an afternoon.
That last one is the real test. If producing the list is a project, the list does not exist.
What to ask a provider
The NCSC guide groups EASM features into visibility and insight, security analysis, and supporting functions. Those are useful headings for a conversation:
How do you attribute assets to us? Discovery is easy; deciding what is really yours is the hard part. Ask how false attributions are handled, because an alert about someone else’s server trains people to ignore alerts.
How often does discovery run? Good products refresh daily. Quarterly discovery is an audit with a subscription fee.
What happens when something new appears? Alerting, workflow, ownership assignment, or just a dashboard you have to remember to open.
What happens after discovery? This is the question that separates offerings. A discovered asset that is never scanned, prioritised and fixed has not improved your security, only your paperwork.
Can I export the raw data? You should be able to leave with your own asset inventory.
What does it cover beyond CVEs? DNS, email, certificates, exposed services: the issues above.
Who validates the serious findings? An automated severity is a starting point, not a conclusion. Ask whether a qualified tester can confirm that an exposure is actually reachable, and whether the firm holds CREST or Cyber Scheme accreditation for that testing.
A note on Cyber Essentials
Every internet-facing service is in scope for Cyber Essentials, and the scope is declared by you. If you do not know what your internet-facing services are, your scope is an estimate, and certification against an estimate is worth what you would expect. This is one of the more practical arguments for doing discovery properly: it makes the scope statement defensible.
Sources
- ONS, Mergers and acquisitions involving UK companies: April to June 2026, released 1 September 2026: 353 completed transactions in Q2 2026 (407 in Q1). The ONS counts transactions of £1 million or more that change ultimate control, so the true number of inventory-merging events is higher.
- CISA, Known Exploited Vulnerabilities catalogue, version 2026.10.27: 1,760 entries.
- NCSC, External attack surface management buyer’s guide: definitions and feature groupings. Shadow IT definition from NCSC asset management guidance.