A scanner only covers what somebody typed into it. Breaches tend to begin on the host nobody typed in.
Give it a few things you definitely own, a domain, an address block, an autonomous system number, and it works outward through registration records, DNS, certificates and network relationships until it reaches the boundary of what you are actually answerable for. Microsoft states the reasoning bluntly: most vulnerability programs cannot see past the firewall, and what sits outside it is where breaches predominantly start.
- Seeds outwardRecursive discovery from what you know
- Eight asset typesDomains, hosts, pages, certificates, IPs, ASNs
- Five statesFrom approved inventory to requires investigation
- ContinuousScheduled rediscovery, not a one-off scan
Eight reasons this turns up things your scanner never will.
It starts from seeds and works outward recursively
You supply known assets, called seeds, and each one gets scanned recursively to find further entities through whatever it connects to. Seeds sit as central nodes and the search branches outward, picking up everything directly attached, then everything attached to those, repeating until it reaches the edge of what your organization is responsible for managing.
There are six kinds of seed, and one domain will do
A seed can be a domain, an address block, a host, an email contact, an autonomous system name, or a registrant organization. In practice one corporate domain gets you started. From there it reads registration records, DNS, certificates and network data to derive an entirely fresh set of assets worth investigating.
SSL certificates are the connection people forget
One of the documented relationships is every certificate attached to each of your hosts, plus any other host presenting the same certificate. That single link is how a forgotten staging environment resurfaces, or a microsite an agency built for a campaign in 2022, or infrastructure that arrived with an acquisition and was never documented. Certificates leave a public trail no internal tool can follow.
Five asset states, not a flat list
Approved Inventory covers what you own and answer for. Dependency covers infrastructure a third party owns that your assets rely on, a hosting provider address being the obvious case. Monitor Only covers what is genuinely relevant but outside your control, with franchisees and related companies given as the example. Candidate covers a relationship too thin to confirm. Requires Investigation covers whatever the confidence scoring has flagged for a person to decide.
Confidence decays as the search goes deeper, deliberately
As the search reaches third and fourth level connections its confidence in ownership drops, and it may well surface assets relevant to you without being yours. That candor is precisely what makes the output workable. A product that confidently asserted ownership of everything it found would be actively dangerous.
Discovery groups, with recurring schedules
Seeds live inside discovery groups, which is where you automate the search, maintain the seed list, and set it to run on a schedule. Once the inventory exists, continuous scanning uses virtual user technology to examine the content and behavior of each page on applicable sites, which is what produces findings on both vulnerabilities and compliance.
Pages count as assets, and that is where the compliance findings surface
The documented filters run across domains, hosts, pages, contacts, certificates, addresses, address blocks and autonomous system numbers. Pages deserve more attention than their position in that list suggests, because the scanning examines what each page contains and how it behaves. That is what turns up an abandoned framework, a third-party script nobody approved, or a form quietly collecting personal information on a site with no owner, which under CCPA and CPRA and the other state statutes is a legal problem before it is a technical one. A host that merely answers is a modest finding. A page actively gathering personal data on infrastructure your security team has never heard of is an entirely different conversation.
A prebuilt inventory exists before you configure anything
Before configuring anything, you are advised to look for the prebuilt inventory that already exists for your organization, assembled from connections the system has previously identified. That means the first useful output lands in minutes rather than weeks, and it is reliably the moment somebody in the room says they had no idea that was still up.
No scanner has ever found an asset nobody entered into it.
The problem is documented plainly, and it describes nearly every American company we assess.
- The documented position: a great many vulnerability programs cannot see outside the firewall at all, leaving them unaware of external risks and threats, which are the primary source of data breaches.
- And alongside it: digital growth keeps outrunning what a security team can realistically protect, with new initiatives and the entirely commonplace shadow IT together expanding the attack surface beyond the firewall.
- What that means in practice is a scanner reporting full coverage of every asset in its target list. That statement is entirely true about the list and tells you nothing whatsoever about the estate.
- External discovery works the other way round. It begins with public evidence of what you own rather than with whatever somebody remembered to add, which is why a first run reliably produces assets nobody present can immediately account for.
Four things that stop this becoming another report nobody opens.
We start triage where Microsoft says to start it
Start with Requires Investigation, because the confidence scoring has already flagged those as needing somebody to decide. Working alphabetically, or by asset type, costs exactly the same hours and returns far less. Five states rather than one list exist precisely because they imply a running order.
We seed from what you actually own, including acquisitions
Domains, address blocks, autonomous system numbers, and registrant organizations. Acquisitions matter out of all proportion here, because each one arrives with its own network ranges, its own certificate history, and its own name servers. They are by some distance the most common source of assets nobody at the parent company has ever laid eyes on.
We draw the line between what you own and what you merely rely on
The Dependency state exists for a reason worth understanding. Infrastructure somebody else owns while your assets depend on it, a provider hosting your web content being the classic case, is genuinely part of your attack surface and entirely outside your authority to fix. Blurring those two produces findings nobody has the power to act on.
The schedule gets set before the first report is ever presented
Discovery groups run on a recurring schedule and continuous scanning keeps the asset detail current. An attack surface that was accurate in March describes nothing by September. Fixing the schedule and naming a reviewer at the outset is exactly what turns this into a control rather than a one-off deliverable.
Six US situations where external discovery finds something the same week.
A group that has acquired several businesses
Every acquisition arrives with its own domains, its own network ranges, and its own certificate history. Seeding from the acquired company registrant organization and network numbers pulls all of that into a single inventory, and it regularly surfaces environments the acquired IT team had themselves forgotten, because whoever built them left before the deal closed. For a private equity roll-up this is simply routine.
A business whose marketing runs through agencies
Campaign microsites, landing pages, and event registration forms thrown up quickly on somebody else hosting, carrying a certificate that points straight back at you. That certificate link is precisely how they surface, and without exception they are the least patched and least monitored things in the estate.
A regulated firm asked to evidence its external footprint
SOC 2 auditors, cyber carriers, and enterprise customers now ask what you have facing the internet, not simply what you have patched. A discovered inventory with ownership states, refreshed on a schedule, is a considerably better answer than a hand-maintained spreadsheet, and the trend across quarters is what demonstrates the control is actually working.
An operator with plants and remote facilities
Plants, yards, and remote sites accumulate their own connectivity, their own remote access, and occasionally their own public addressing, all arranged locally to solve a genuine problem that day. Address block and network seeds surface that infrastructure regardless of whether head office ever approved it.
An institution with departmental autonomy
Departments, research groups, and student organizations stand up their own sites and services, frequently on the institution own domain and frequently without central IT hearing about it. Shadow IT is named explicitly as a driver of the expanding external attack surface, and nowhere is that more visible than a university estate.
A business that has rebranded or migrated hosting
Old domains keep resolving, old hosts keep answering, and the migration project was signed off long before the decommissioning was actually finished. These carry the oldest software anywhere in the estate, and because nobody remembers them, nobody has patched them in years. Discovery finds them because DNS and certificates have a longer memory than people do.
How US organizations know what they have exposed.
| Feature | External discovery in place | Scanner against a known list | Nothing systematic |
|---|---|---|---|
Known assets assessed | Yes | Yes | No |
Unknown assets found | Yes | No | No |
Acquisition infrastructure surfaced | Yes | Rarely | No |
Certificate relationships followed | Yes | No | No |
Third-party dependencies distinguished | Yes | No | No |
Ownership states tracked | Yes | No | No |
Discovery runs on a schedule | Yes | Not applicable | No |
New exposure noticed quickly | Yes | No | No |
Shadow IT visible | Often | No | No |
Attack surface trend measurable | Yes | No | No |
One domain seed, and everything it leads to.
Data source
Whois records
- Relationship derived
- Further domains registered against the same contact address or registrant organization
- What it usually surfaces
- Campaign domains and brand defensive registrations nobody tracks
Data source
Whois records
- Relationship derived
- All domains registered to any address at your domain
- What it usually surfaces
- Domains bought on a personal initiative years ago
Data source
Whois records
- Relationship derived
- Other domains associated with the same name server
- What it usually surfaces
- Sister companies, joint ventures and acquisitions
Data source
DNS records
- Relationship derived
- Every host observed on your domains, plus the websites sitting on those hosts
- What it usually surfaces
- Staging, UAT and legacy hosts still resolving
Data source
DNS records
- Relationship derived
- Domains running on different hosts that nonetheless resolve into the same address blocks
- What it usually surfaces
- Shared hosting neighbors and forgotten co-tenanted sites
Data source
DNS records
- Relationship derived
- Mail servers associated with your domains
- What it usually surfaces
- Legacy relays and third-party senders still authorized
Data source
SSL certificates
- Relationship derived
- Every certificate attached to each host, and any other host presenting the same one
- What it usually surfaces
- Agency-built microsites and expired-project environments
Data source
ASN records
- Relationship derived
- Further address blocks under the same autonomous system, with everything resolving into them
- What it usually surfaces
- Whole ranges from an acquisition that nobody inventoried
Five steps, with something useful in your hands during the first week.
- 1
Deploy and check the prebuilt inventory
The service is created as an Azure resource. Before building anything custom, look for the prebuilt inventory that already exists for your organization, assembled from connections previously identified. That first look takes very little time and frequently produces the single finding that gets the rest of the project funded.
- 2
Define the seeds and the discovery groups
Domains, address blocks, hosts, email contacts, autonomous system names, and registrant organizations, arranged into groups that mirror how the business is genuinely structured, whether by brand, by region, or by acquired company. The recurring schedule gets configured at this point rather than added as an afterthought.
- 3
Triage by state, starting with Requires Investigation
Then the Candidate list. Every asset receives an ownership decision: Approved Inventory, Dependency where a third party owns something your assets rely on, or Monitor Only where it matters without being yours to control. This is a business conversation rather than a technical one, and it is where all the value of the exercise actually sits.
- 4
Feed the inventory into what you already run
Anything newly confirmed has to reach the vulnerability program, the certificate lifecycle process, and whatever asset register your company keeps. Discovery that ends at a list changes precisely nothing. Data connections exist to push the inventory into the tools that will actually do something with it.
- 5
Set the rhythm and watch the trend
Rediscovery on a schedule, a named person responsible for reviewing anything new that appears, and a reported trend showing how the surface is growing. Continuous scanning keeps the detail current, but a human still has to read what changed, and that role is assigned before we close the engagement.
What organizations ask about external attack surface management.
Fifteen questions that turn a discovery into a decision.
Setting it up
- Have you checked the prebuilt inventory first?Microsoft recommends it before custom work.
- Which seeds do you actually own?Domains, IP blocks, hosts, contacts, ASNs, Whois orgs.
- Are acquisitions included as seeds?They carry their own ASNs and certificates.
- How are discovery groups organized?By brand, region, or business unit.
- What is the recurrence schedule?Discovery is not a one-off exercise.
Triage
- Who reviews Requires Investigation first?Microsoft recommends starting there.
- Who decides Approved versus Dependency?It is an ownership judgment, not technical.
- Are franchisees or affiliates Monitor Only?That is the published use of the state.
- What happens to a Candidate nobody claims?Decide the default in advance.
- How long should triage take?Set a target or it never finishes.
Acting on it
- Who owns decommissioning an orphaned host?Usually nobody, which is the problem.
- Do findings reach the vulnerability program?Otherwise discovery changes nothing.
- Are expired certificates tracked?They are also a discovery signal.
- Do new assets trigger a review?A new host should raise a question.
- Who sees the trend over time?Growth of the surface is the real metric.
The pages around this one.
Defender Vulnerability Management
What happens to the assets once you know they exist: continuous assessment, inventories and prioritized remediation.
Microsoft Defender XDR
The correlation layer the wider exposure picture feeds into, across endpoint, identity, email and cloud.
Cybersecurity audit and compliance
Independent testing of whether the exposure you found is actually exploitable, and the evidence pack behind it.
Send one domain and we will show you everything hanging off it.
Because the prebuilt inventory exists before anything is configured, that first look takes very little time. In every engagement we have run, something has appeared in that list which nobody in the room could immediately explain.
Related Services
Explore more solutions that work great with this service
Microsoft Defender Vulnerability Management Services
Defender Vulnerability Management deployment for US organizations:
Learn moreMicrosoft Defender XDR Services
One incident queue across endpoint, email and identity
Learn moreMicrosoft Security Services
The Microsoft security stack deployed and managed end to end
Learn moreMicrosoft Defender
Advanced endpoint and email threat protection
Learn more