Why does continuous discovery run different scans at different frequencies?

Because the techniques do not cost the same. Light DNS enumeration across a few root domains is cheap enough to run constantly, while a full port scan across every address you own is not. A sensible discovery programme tiers them by cost and frequency, with cheap checks running more often than expensive ones. The practical consequence is that the frequency you set per technique determines the resolution at which you can detect that kind of change: an hourly name check can detect a new observable subdomain within roughly that interval, while a daily port scan can detect a newly reachable service on its next successful run.

Does discovering an asset mean it has a vulnerability?

No. Discovery reports what exists and what is reachable, not whether it can be exploited. An open port is a fact; whether an attacker can do anything with it is a separate question that needs testing which attempts the action. What discovery does give you is triage signal. An asset with an old TLS version, no detected delivery or reverse-proxy layer and a certificate from a different authority to the rest of your estate may have followed a different deployment or management path, which can make it worth looking at first.

How do shared TLS certificates reveal infrastructure relationships?

Two assets presenting the same certificate tells you they were probably provisioned or managed together, which is a weaker claim than sharing a host but often a more useful one. In practice it does three things: it groups assets that are likely to share a deployment path, so a misconfiguration found on one is worth checking on the others; it shows how far a wildcard has actually been used, which is often further than intended; and it gives you the blast radius of a single expiry. What it does not establish is ownership. A shared certificate on an asset nobody recognises is a question about which team provisioned it, not proof that it is yours to decommission.

What does external attack surface discovery miss?

Anything not reachable from the internet, and anything that only becomes visible after authentication. It will not map an internal estate for you, and it says close to nothing about tenant boundaries, ownership checks or payment logic, because those have no external signature. Enumeration cannot find a flaw whose only symptom is that the wrong user was allowed to do something.

An asset appears that nobody recognises. What now?

Establish what answers before deciding what it is. Check what the name resolves to and whether that target is still under your control, because a record pointing at a third-party service can outlive the account or resource behind it and continue directing traffic towards a target you no longer control. Then look at the classification and the exposed services: an address with a reachable service that appears to expose a database or data store, or something running an authentication service, deserves an answer the same day. A name nobody recognises is not automatically a problem, but it is always a question about who owns the process that created it.

Back on Articles page

31 August 2026

How to Continuously Map Your External Attack Surface

12 min. readBy Borg

An asset inventory is accurate on the day someone builds it. After that it drifts. A subdomain gets pointed at a new host for a demo and stays. A service moves behind a load balancer and the old address keeps answering. A wildcard certificate quietly covers something nobody meant to publish. None of it shows up in a spreadsheet, because a spreadsheet only knows what somebody typed into it.

Mapping an external attack surface continuously is the practice of closing that gap: finding what is reachable from the internet, keeping the list current as infrastructure changes, and understanding how the pieces connect. Here is how that works, and where it stops being useful.

What counts as an asset

Three things, and the distinction matters more than it looks.

For the purposes of an external attack-surface inventory, three identifiers are particularly useful: domains, subdomains and the addresses they resolve to. They form the core infrastructure layer of the inventory.

HTTP routes and endpoints are a separate layer. In this inventory model, api.example.com/v2/accounts is treated as a property of the application exposed through the hostname rather than as an infrastructure asset in its own right. Keeping the two layers apart is what stops an inventory turning into an unusable list of every URL a crawler has ever seen.

The reason to be strict about it is that the question you ask differs per layer. "Do we still own this?" is a domain question. "Is this port meant to be open?" is an address question. "Should this endpoint require a session?" is a route question, and that one needs testing rather than discovery.

The four ways an asset arrives, and the two that matter

An inventory fills from more than one direction. In Borg's platform, assets can be associated with how they were learned. The taxonomy is worth borrowing even if you build your own:

Manual, added by someone on the team.
Import, loaded in bulk from a CSV or JSON file.
Recon, found by continuous discovery.
Agent, found by Mjolnir during a pentest run, as a by-product of reconnaissance against a target.

The first two usually represent assets that were already known to someone or recorded somewhere. They are worth recording and they are rarely where the problem is. The interesting half of a real attack surface is what arrived through the other two: the things nobody put on a list.

That is the case for continuous discovery in one line. You are not trying to catalogue what you remember. You are trying to find what you have forgotten.

Why the count is always higher than anyone guessed

Three mechanics generate assets without anyone deciding to.

Delegation and inheritance. A root domain someone wrote off years ago can still carry a live subdomain tree, because the records were never removed and nothing forced a review.

Names that outlive their targets. A CNAME pointing at a third-party service stays valid after the account behind it lapses. The name still resolves. What it resolves to may no longer be yours, and the gap between owning a name and controlling what answers on it is worth finding before somebody else does.

Short-lived infrastructure that is not short-lived. A host stood up for a demo, a migration or a load test tends to outlive its reason. It was never in the inventory because it was never meant to be permanent.

None of that is exotic. It is the ordinary consequence of shipping, and it is why the first honest count of an external surface often surprises the team that owns it.

The techniques, and why they belong on different clocks

Discovery is several jobs wearing one name, and they do not cost the same. Light DNS enumeration across a handful of root domains is cheap and can run constantly. A full port scan across every address you own is not cheap and cannot.

A sensible continuous-discovery programme can run several tiers at different frequencies:

Tier	Typical Frequency	What it does
Frequent	Hourly or several times a day	Light DNS enumeration to pick up new domains and subdomains
Periodic	Every few hours or daily	Deeper enumeration for subdomains the lighter pass can miss
Comprehensive	Daily or less frequently, depending on estate size	Broader port scanning, address linking and service identification

Copy the shape rather than the specific numbers. DNS enumeration is generally cheaper than comprehensive service scanning, so the cheap check that catches fresh names can usually run more often than the expensive check that enumerates what is listening across the address space.

Two techniques do the looking. Domain recon runs DNS enumeration, HTTP probing and TLS inspection against domains and subdomains. Network recon scans the port range on the address side and labels the services it finds.

Both can be designed to minimise operational impact, and that constraint matters more than it sounds for something you intend to run repeatedly against production. Discovery that carries a plausible risk of disruption gets switched off the first time anyone blames it for an incident, and then you are back to the spreadsheet.

What a technology profile is for

Knowing a subdomain exists is thin. Knowing what is answering on it is what lets you act.

Domain recon returns several things per asset that change how you read it. The web server or edge provider answering, which can indicate whether a name is being served through a content delivery or reverse-proxy layer. The TLS protocol version and cipher, which can highlight hosts still negotiating configurations you intended to retire. The certificate subject and issuer, which can reveal differences from the rest of the estate. And whether a web application firewall is detected in front, which can help identify services that appear to differ from the standard deployment pattern.

None of those is a vulnerability. All of them are triage signal. An asset with no delivery network in front, an old TLS version and a certificate from a different authority to the rest of your estate is not necessarily broken, but the combination is a useful signal that it may have followed a different deployment or management path, and that can make it worth looking at first.

What continuous actually buys you

Run discovery once and you get an inventory. Run it on a schedule and you get something more useful: the difference between today and yesterday.

Most of a mature attack surface is stable and uninteresting. The signal is in the delta. A subdomain that appeared overnight, a port that opened on a host that had none, a certificate that changed issuer, an address that started answering for a name it never served before. Those are the events worth a person looking at, and they are invisible to a process that produces a fresh list every quarter with no memory of the last one.

This is also why the tiering matters beyond cost. A daily port scan gives you a daily port delta. An hourly name check gives you an hourly name delta. The frequency you choose per technique is the resolution you get on that kind of change, so it is worth choosing deliberately rather than inheriting whatever a tool defaults to.

Four approaches, and what each one cannot tell you

Approach	What it answers well	Where it falls short
Spreadsheet or CMDB maintained by hand	What the team believes it owns, with business context attached	Only as current as the last person to update it, and it cannot know about anything nobody added
Periodic external scan, quarterly or annual	A point-in-time snapshot, useful as an audit artefact	Anything that appears and disappears between scans is invisible, and short-lived hosts are exactly that
Certificate transparency monitoring on its own	New names shortly after a public certificate is issued	Sees names covered by certificates recorded in public Certificate Transparency logs, so address-only services and services using certificates outside those logs can be missed
Continuous discovery with tiered scanning	A list that stays close to current, plus relationships and a technology profile per asset	Reports what exists and what is reachable, not whether any of it can be exploited, and it stays bounded to what is externally visible

That last row is the honest limit and it is better stated than buried. Discovery is an inventory practice. It answers what is out there. It does not answer whether someone can get in through it. Those are different questions needing different instruments, and a programme that confuses them ends up with a very tidy list and no clear idea what to fix first.

Relationships are the half most teams skip

A flat list is a start. What makes it useful is knowing how the entries connect, because that is what tells you the blast radius of any one of them.

Three relationships are worth deriving.

Domain hierarchy. Root domain, parent, children. Walking it can help build out the subdomain tree beneath a name you own and reveal descendants that were not already recorded.

Shared certificates. When two assets present the same TLS certificate, identified by its SHA-256 fingerprint, they are linked whether or not anybody documented it. That is routine with wildcard and multi-domain certificates, and it has three uses: spotting assets that may share infrastructure or certificate-management paths, seeing how far a wildcard actually reaches, and knowing which assets a single certificate expiry would affect together.

Shared addresses. Every domain and subdomain resolving to one address, with the ports found on it. Shared hosting is not a defect, but it is a fact worth having before deciding that one of those names is low risk.

Borg renders these as edges on an attack surface map with assets as nodes, so related things cluster and concentrations become visible rather than inferred. The value is not the picture. It is that "what else is on this host" and "what else does this certificate cover" become questions you look up instead of reconstruct.

Classification is what makes an inventory triageable

An inventory that treats every entry alike forces you to read all of it. Classifying by what an asset appears to be lets you triage instead.

The useful classifications are behavioural rather than nominal. A root domain or subdomain is a name in the hierarchy. A server is an address serving web traffic. A likely database or data-store exposure can be identified from service fingerprints and commonly associated ports. Borg's classifier, for example, considers ports including 3306, 5432, 27017, 1433 and 6379 as signals that an address may be exposing a data service. An auth gateway is an address or subdomain running an authentication service.

Those last two are the point. "We have 400 subdomains" is not actionable. "One of these addresses has 27017 reachable from the internet" is actionable immediately, and it should not be sitting in the same undifferentiated list as a marketing microsite. The same goes for anything classified as handling authentication: an authentication surface nobody knew was public deserves a different level of scrutiny from a forgotten redirect, and a list that cannot tell them apart makes you find that out by reading.

Turning an inventory into work

Discovery produces a list, and a list changes nothing by itself. This is where attack surface programmes usually stall.

Two connections make it operational. The first is findings attached to assets, so the inventory stops being a catalogue and starts being a worklist. Borg rings nodes on the map by the highest severity attached to them, which sounds cosmetic and changes how the map gets read.

The second is routing into wherever engineering work already lives. A discovered asset with a real problem on it needs to become a ticket in the tracker the team already uses, not a row in a security tool nobody opens. That is worth setting up before discovery is switched on rather than after, because the first full run can be especially noisy: it establishes a baseline from which later changes can be compared, and pushing findings into Linear, Jira or GitHub can help stop that first run being ignored wholesale by moving the work into the systems engineering teams already use.

Where external discovery stops

Being clear about the boundary is what keeps the practice credible.

External discovery sees what is reachable from the internet. It does not see what is not exposed, so it is not a substitute for knowing your internal estate.

It reports what is present, not what is exploitable. An open port is a fact. Whether an attacker can do anything with it is a question for testing that attempts the action and observes the outcome.

And it says close to nothing about the class of problem that lives behind a login. Tenant boundaries, ownership checks, payment and entitlement logic: none of that has an external signature, and enumeration will not surface it. That is work for authenticated, application-aware testing.

The honest framing is that discovery sets the scope for everything else. It tells you what the target is. It does not tell you whether the target holds.

Starting from nothing

If there is no inventory today, the order that wastes least effort is unglamorous.

Begin with the root domains, which somebody in the organisation definitely knows. Let enumeration find the subdomain tree beneath them, and expect a higher count than anyone predicted. Then read the classifications before the raw list, because anything resembling a database or an authentication surface deserves an answer today whatever else is queued. Then set the cadence, cheap checks on a short clock and expensive ones on a long one.

The first pass is an audit. The value arrives on the second and every one after, when the list stops being a discovery exercise and becomes a change feed: this is new since yesterday, and nobody recognises it.

That is also the point at which discovery starts feeding the rest of the programme rather than sitting beside it. A current inventory is what lets continuous testing be scoped to what you run today instead of what you ran when someone last wrote the list down.

If you want to see what this returns against your own domains, book a walkthrough with Borg.

Frequently asked questions

Why does continuous discovery run different scans at different frequencies?: Because the techniques do not cost the same. Light DNS enumeration across a few root domains is cheap enough to run constantly, while a full port scan across every address you own is not. A sensible discovery programme tiers them by cost and frequency, with cheap checks running more often than expensive ones. The practical consequence is that the frequency you set per technique determines the resolution at which you can detect that kind of change: an hourly name check can detect a new observable subdomain within roughly that interval, while a daily port scan can detect a newly reachable service on its next successful run.
Does discovering an asset mean it has a vulnerability?: No. Discovery reports what exists and what is reachable, not whether it can be exploited. An open port is a fact; whether an attacker can do anything with it is a separate question that needs testing which attempts the action. What discovery does give you is triage signal. An asset with an old TLS version, no detected delivery or reverse-proxy layer and a certificate from a different authority to the rest of your estate may have followed a different deployment or management path, which can make it worth looking at first.
How do shared TLS certificates reveal infrastructure relationships?: Two assets presenting the same certificate tells you they were probably provisioned or managed together, which is a weaker claim than sharing a host but often a more useful one. In practice it does three things: it groups assets that are likely to share a deployment path, so a misconfiguration found on one is worth checking on the others; it shows how far a wildcard has actually been used, which is often further than intended; and it gives you the blast radius of a single expiry. What it does not establish is ownership. A shared certificate on an asset nobody recognises is a question about which team provisioned it, not proof that it is yours to decommission.
What does external attack surface discovery miss?: Anything not reachable from the internet, and anything that only becomes visible after authentication. It will not map an internal estate for you, and it says close to nothing about tenant boundaries, ownership checks or payment logic, because those have no external signature. Enumeration cannot find a flaw whose only symptom is that the wrong user was allowed to do something.
An asset appears that nobody recognises. What now?: Establish what answers before deciding what it is. Check what the name resolves to and whether that target is still under your control, because a record pointing at a third-party service can outlive the account or resource behind it and continue directing traffic towards a target you no longer control. Then look at the classification and the exposed services: an address with a reachable service that appears to expose a database or data store, or something running an authentication service, deserves an answer the same day. A name nobody recognises is not automatically a problem, but it is always a question about who owns the process that created it.