Ask a vendor how EASM discovers assets and you will usually get a list of sources: certificate transparency logs, DNS, WHOIS, maybe a nod to BGP. All true, and all the easy part. The harder question, the one that decides whether the inventory you are handed is worth acting on, is how a hostname that appeared in a log at 09:14 becomes a line in your asset register with your name against it. That is attribution, and it is where external attack surface management tools genuinely differ.
What follows tracks one seed domain through to a usable inventory, and spends most of its time on the two things that get skipped: how a candidate becomes a confirmed asset, and what each discovery method cannot see.
What discovery starts with: seeds, and why the seed list decides everything
Discovery does not begin with the internet. It begins with a small set of things you declare about yourself, and everything else grows outwards from there.
What goes into a seed set
A seed set usually contains primary registered domains, any IP ranges you know you hold, autonomous system numbers if you announce your own space, and legal organisation names as they appear in registration records. Four categories, often fewer than twenty entries in total.
A thin seed list does not fail loudly. It quietly caps coverage. If you declare brand.co.uk and nothing else, the tool will do excellent work on that one tree and will never learn that the pension scheme runs on a separate domain, that a divested brand still resolves to your load balancers, or that the agency registered the campaign domain in its own name. You will get a clean report and an incomplete one.
Expansion versus enumeration
There are two ways to find your estate. One is to scan large parts of the internet, fingerprint everything, and then try to work out which of it belongs to whom. The other is to start from what you declared and pivot outwards: this certificate covers these hostnames, these hostnames resolve to this IP, this IP sits in this allocation, this allocation holds these other names.
Most credible EASM platforms do a mixture, weighted heavily towards expansion, because expansion carries evidence with it. Every hop is a reason. Internet-wide enumeration produces volume without reasons, and volume without reasons is how you end up with an inventory nobody trusts.
Why the output is a candidate list
Expansion produces candidates. A candidate is a hostname, IP or service that has some link to a seed, of varying strength. Nothing has yet decided whether it is yours, whether anyone in your organisation is responsible for it, or whether it is simply a neighbour on shared infrastructure.
It becomes an inventory only after attribution, deduplication (one host may appear as four names, two IPs and a certificate), ownership assignment, and a scope decision. Skip those steps and you have a long list, not an internet-facing asset inventory.
Building a seed list that includes the awkward corners
Spend an afternoon on this and you will get more coverage than any feature comparison will buy you. Pull the domain list from finance rather than IT, because renewals appear on card statements even when they never appeared in a ticket. Ask the marketing team which agencies have ever registered a domain on your behalf. Include brands you sold, because DNS often outlives the deal. Add every acquisition, including the ones that were folded in on paper but not in the racks, and include their ASNs and IP ranges as separate seeds rather than assuming the parent domains will reach them.
The public data sources EASM expands through
Certificate transparency logs
Every publicly trusted TLS certificate is submitted to append-only certificate transparency logs, because browsers including Chrome have required proof of logging for certificates issued since 2018. The practical effect for discovery is speed: hostnames surface in the logs within minutes of issuance, which means a new host can be externally discoverable before it is live, before it is hardened and before change control has written it down.
Certificate transparency log monitoring is the strongest single source for subdomain discovery. It is also the source with the largest hole in it, which is covered further down.
DNS and passive DNS
Live DNS answers the question of what resolves now: A and AAAA records for addresses, CNAME for aliases, MX for mail, NS for delegation, TXT for SPF, DKIM selectors, DMARC policy and assorted verification strings that themselves reveal which SaaS platforms you use.
Passive DNS answers a more interesting question: what resolved before. Historical resolution data surfaces retired infrastructure, old hosting providers, and hostnames that no longer resolve but whose names hint at services that may still be listening on an IP you have forgotten. It also fills gaps left by wildcards, because a name that was observed in real traffic was observed regardless of how its certificate was issued.
Domain registration data: what redaction took away
Registrant-based pivoting is weaker than most vendor material implies. Ten years ago you could take a registrant email address from a port 43 WHOIS response and find every domain registered with it. GDPR-era redaction removed most of that, and the shift to RDAP, the structured successor to WHOIS, changed the plumbing without restoring the data. ICANN’s transition plan set January 2025 as the point at which contracted parties were no longer obliged to run port 43 WHOIS at all, so check what your tooling is actually querying.
In the UK, Nominet withholds the details of individual (non-trading) registrants on .uk domains unless they opt in to publication. So the agency-registered campaign domain often reveals nothing about who paid for it.
What still works: registrar pivots, nameserver pivots (a small self-hosted nameserver set is a strong signal), and creation-date clustering. Weaker signals, honestly labelled, beat strong signals that no longer exist.
IP and routing data
Regional internet registry allocations, ASN membership and BGP announcements tell you which address space is associated with your organisation name. Reverse DNS across ranges you actually hold is one of the highest-yield, least glamorous techniques available.
Consider an acquisition that brings a /24 announced under its own ASN. Nothing in the parent company’s domain list reaches it. Reverse DNS across that range surfaces a legacy remote access appliance that never made it into the due diligence pack. No amount of certificate monitoring would have found it, because the appliance had a self-signed certificate and no public name worth logging.
Fingerprint and content pivots
When registration data is redacted, content becomes the pivot. Certificate subject and organisation fields, favicon hashes, analytics or tag manager identifiers, error page templates, shared JavaScript bundles: all of these link hosts that look unrelated by name. Useful, and the weakest class of evidence in the set, because a shared favicon proves a shared template far more often than a shared owner.
From candidate to confirmed: how attribution actually works
Finding four thousand hostnames that mention your brand is trivial. Deciding which three hundred are your responsibility is the work. That is the whole discipline in one sentence.
The false positives that cost you trust
Shared hosting is the classic. One of your marketing sites sits on a shared IP alongside a couple of hundred unrelated domains. A tool that attributes by IP neighbour alone hands you all of them, and the security team stops opening the report by the third week. CDN address space does the same thing at greater scale, because the IP tells you which CDN answered, not who owns the origin. Then there are supplier tenants that legitimately carry your brand in the hostname: yourbrand.supplier-portal.com is a real exposure worth knowing about, but it is not yours to patch.
The false negatives nobody chases
False positives annoy people. False negatives hurt them. The asset registered on a developer’s personal card, sitting in a personal cloud account, with a domain that has no relationship to any seed. The acquisition completed six weeks ago whose ranges are not in the seed list yet. The regional office that bought a local hosting package in a local language. External discovery will not find these by magic, and a tool that reports complete coverage is telling you about its own confidence, not your estate.
Confidence, evidence and a ‘not ours’ decision that sticks
Good attribution is expressed as a confidence level with the evidence attached: found in a certificate alongside a seed hostname, resolves into a range allocated to you, delegated to your nameservers. You should be able to click a host and read why the tool believes it is yours. If the answer is a single score with no chain behind it, you cannot audit it and you cannot defend it to the business owner who insists the site is not theirs.
Ask the question that vendors dislike: when an analyst marks something ‘not ours’, does that decision persist through the next refresh, or does the host reappear every Monday? Persistent de-scoping with a recorded reason is the difference between an inventory that gets maintained and one that gets ignored. This is one of the recurring errors in external attack surface programmes: treating the tool’s output as a verdict rather than as a working hypothesis that needs human adjudication.
What discovery can see, and what it can only infer
External discovery observes. It reads banners, response headers, TLS configuration, redirect behaviour and software fingerprints, and from those it says ‘likely’. A header advertising a particular web server version, matched against a CVE list, produces a probable finding. It has not tested the flaw.
That distinction matters when the finding reaches a change board. A probable version, inferred from a fingerprint, is a reason to check the host, not grounds to declare an incident. Authenticated or active vulnerability scanning is what turns likely into definitely, which is why EASM sits alongside scanning rather than replacing it. The two answer different questions, as covered in more detail in the piece on EASM versus vulnerability scanning.
Some exposures, though, discovery finds outright, with no inference required. An expired or mismatched certificate is a fact. An admin login page reachable from the open internet is a fact. And a dangling CNAME is a fact, which brings us to the finding that deserves same-day handling.
Take the ordinary version: an agency creates promo.brand.co.uk as a CNAME to a cloud storage bucket for a six-week campaign, deletes the bucket when the campaign ends and leaves the DNS record alone. Discovery finds the hostname first, as an asset. Only when it resolves the chain and gets a 404 or a NoSuchBucket-style response does the asset become an exposure, because until the record is deleted the name is claimable by anyone who registers the same bucket. The fix is a DNS deletion, not a patch. The mechanics are worth reading in full in the explainer on subdomain takeover and dangling DNS. How that initial hostname surfaces in the first place, and where certificate transparency logs fall short, is covered separately in the piece on subdomain discovery gaps.
The blind spots in every discovery method
Wildcard certificates. This is the big one. A certificate for *.example.co.uk logs exactly that string and no individual hostnames, so an estate that standardised on wildcards can look a fraction of its real size in certificate transparency data. Compensating means passive DNS history, nameserver and range pivots, and plain wordlist resolution against the zone. If a vendor’s discovery story is certificate logs and little else, push on this specifically.
CDN-fronted origins. The CDN answers, so the origin’s address, software and patch level stay hidden. Worse, the origin often remains directly reachable on its real IP, protected only by obscurity. Some hosts answer only when the correct Host header is sent, so an IP sweep sees nothing while a name-based request sees an application.
Redacted registration data. Covered above, and it bites hardest on .uk domains registered by individuals, which is precisely the category the shadow IT and campaign-microsite problem lives in.
SaaS tenants and non-web services. External discovery under-represents hosted portals, identity providers, file-sharing tenants and anything that is not a web service on a common port. Your third-party HR portal is part of your attack surface and will rarely be discovered from a domain seed.
Pair discovery with three internal sources and the gaps narrow considerably: reconciliation against the CMDB (to find what you list but cannot see externally), cloud account and subscription enumeration (to find what exists before it is exposed), and procurement or expense records (to find what was bought outside IT). Discovery tells you what the outside world can see. It does not tell you what you own.
Keeping the picture current, and questions to put to a vendor
Certificates appear in logs within minutes. A developer deploys a service. A DNS record is added for a launch. A bucket is deleted and the record is not. Weekly discovery finds those changes up to six days late, and for a claimable hostname, six days is a long time. Daily is the honest baseline for change detection, with the argument set out at greater length in the case for continuous monitoring over point-in-time scanning.
Speed has a cost: noise. Manage it by grouping findings by cause rather than by host (one misconfigured wildcard record explains forty alerts), and by insisting that suppression rules carry an expiry date. Permanent suppression is how a real exposure disappears from view in the third month.
When you are evaluating, the questions that separate genuine discovery from a domain lookup are narrow and awkward:
- How do you handle seeds, and can we add ASNs, IP ranges and organisation names rather than domains alone?
- Which sources do you use beyond certificate transparency, and how do you find hosts covered by a wildcard certificate?
- What evidence is attached to each attribution, and can an analyst see the pivot chain?
- Does a ‘not ours’ decision persist across refreshes, and who can reverse it?
- How do you avoid attributing shared hosting and CDN neighbours to us?
For neutral reference, the NCSC published a buyer’s guide to external attack surface management on 18 September 2025, which is a sensible document to read before a vendor call. Eligible UK public sector organisations can also use NCSC’s Web Check and Mail Check services at no cost; they overlap the certificate and mail configuration end of discovery and are a reasonable way to see what this class of data looks like before committing budget. Our own walkthrough of how EASM discovers the assets you forgot goes further on the forgotten-estate problem, and the product selection checklist covers the commercial questions this article leaves out.
The Short Version
- Discovery starts from seeds you declare (domains, IP ranges, ASNs, organisation names) and expands outwards. A thin seed list caps your coverage silently.
- Certificate transparency, live and passive DNS, RDAP registration data, routing data and content fingerprints are the main pivots. Each has a different evidential weight.
- The output is a candidate list. Attribution, deduplication and ownership assignment turn it into an inventory.
- Attribution is where tools differ. Shared hosting and CDN space cause the false positives; personal-card assets and fresh acquisitions cause the false negatives.
- Wildcard certificates are the largest blind spot in certificate-based discovery, and redacted registrant data (including Nominet’s treatment of individual .uk registrants) has weakened registrant pivots.
- Passive observation gives you ‘likely’, not ‘definitely’. Dangling CNAMEs are the exception: treat them as same-day work.
- Daily refresh with expiring suppression rules beats weekly with permanent ones.
Understanding how EASM discovers assets is really about knowing which parts of the list in front of you are facts, which are inferences and which are somebody else’s problem. Ask for the evidence behind each attribution, keep the seed list honest, and treat the first export as a starting position rather than a finished inventory.
Frequently Asked Questions
How does EASM discover assets without access to my network?
It works from public data only: certificate transparency logs, live and historical DNS, RDAP domain registration records, regional internet registry allocations and BGP announcements, plus lightweight interaction with hosts that already answer the internet. No agent, no credentials and no internal access are involved, which is the point; it sees your estate the way an attacker does, from the outside.
Can EASM find subdomains hidden by a wildcard certificate?
Not from certificate transparency logs, because a certificate for *.example.co.uk records no individual hostnames. Those subdomains can still be found through passive DNS history, nameserver and IP range pivots, and wordlist resolution against the zone, but coverage is less predictable. If your organisation relies heavily on wildcards, ask any prospective vendor exactly which of those techniques it applies.
Why does EASM list assets that are not ours?
Almost always because of weak attribution evidence: a shared hosting IP whose neighbours were attributed to you, CDN address space that tells you nothing about the origin’s owner, or a supplier tenant carrying your brand in its hostname. Some of those are worth knowing about even though you cannot patch them. The test of a decent platform is whether you can see the evidence, mark the asset out of scope with a reason, and have that decision survive the next refresh.
How often should external asset discovery run?
Daily, for change detection at minimum. Certificates appear in transparency logs within minutes of issuance and a claimable dangling record is exploitable from the moment the backing resource disappears, so a weekly cycle can leave a window of several days. Pair the cadence with suppression rules that expire, otherwise the extra speed just produces alert fatigue.
Does EASM discovery replace vulnerability scanning?
No. Discovery infers software and versions from banners, headers and fingerprints, which produces ‘likely vulnerable’ rather than confirmed findings, and it does not see anything that is not internet-facing. Authenticated and active scanning confirms exploitability and covers internal estate. Use discovery to define the scope, and scanning to test what is inside it.