Exposed asset detection is the process of finding every system your organization has reachable from the public internet, including the ones nobody remembers creating. It is the first step in any serious security programme, because every control you buy afterwards quietly assumes you already know what you are protecting.
Most organizations do not. The inventory says forty hosts and the internet answers on ninety. That gap is where incidents start, and it is rarely anything exotic. It is a staging environment from a project that shipped eighteen months ago, still answering, still holding a copy of production data, still running the build that was current the day it was deployed.
What Exposed Asset Detection Actually Means
Detection is discovery. It answers one question: what of ours is reachable from outside? Subdomains, hosts, API endpoints, cloud storage, administrative panels, load balancers, third party services configured under your domain, anything that resolves and responds.
That is not the same as asset visibility, and the distinction is where most programmes stop short. Detection gives you a list. Visibility means you can say, for every item on that list, who owns it, what it is for, which environment it belongs to, and whether it should be reachable at all. Two hundred hosts with no owners attached is not an inventory. It is a backlog.
Attackers perform the detection half for free. Certificate transparency logs are public. DNS is public. Cloud provider ranges are published. Your own JavaScript bundles describe your API. The asymmetry is not in the discovery, it is that they act on what they find and you may never have looked.
Why the Inventory Drifts
Nobody decides to leave a system exposed. Drift accumulates through ordinary engineering.
A feature needs a staging environment, so a subdomain is created and pointed at a new host. The feature ships. The staging host is not in any teardown checklist, because it was created outside the normal deployment path, so it stays up. A year later the engineer who created it has moved on and nobody left can say what it is.
A mobile app needs a backend, so an API host appears that the web application never references. It is not in the web application’s scope, so it is not in the security review’s scope either. A marketing campaign needs a landing page, so a subdomain is delegated to a third party platform. When the campaign ends the platform account is cancelled and the DNS record is not removed, which is the precondition for a subdomain takeover.
Multiply that across several teams, several cloud accounts and several years, and the distance between what you think you run and what is actually answering becomes substantial. That gap is your real attack surface, and it is how most SaaS applications get breached, rather than through anything sophisticated.
What Detection Usually Finds
The same categories come up again and again.
Forgotten staging and development environments, still reachable, often with weaker authentication than production and sometimes with a copy of real data. Old administrative panels from tools that were replaced but never decommissioned. API hosts that exist for a mobile client or a partner integration and were never added to any review scope, which matters because the API is usually a larger surface than the interface built on top of it.
Cloud resources provisioned outside the primary account, most commonly storage with permissions wider than intended, and test environments an individual engineer created and never removed. Services listening on a bare IP address with no DNS name at all, which any method that starts from your domain list will miss entirely.
And dangling DNS records pointing at infrastructure you no longer control, which deserves its own section.
Subdomain Takeover, the Specific Case
A subdomain takeover happens when a DNS record still points at a third party service that has been released. The record says help.example.com belongs to a support platform, but the account on that platform was closed, so the name is unclaimed there. Anyone who registers it gets to serve content on a subdomain of your domain.
That is worse than it first sounds. Content served from your domain inherits trust from users and, depending on cookie scope, can read or set cookies for the parent domain. It passes casual inspection because the domain genuinely is yours. It defeats the advice you give your own users, which is to check the address bar.
Detection catches this by comparing what your DNS claims against what is actually being served, and by checking whether the target of every CNAME is still claimed. It is a mechanical check, it is cheap, and organizations that have never run it usually find at least one.
How Exposed Assets Are Actually Found
No single method covers the surface. Real detection combines several and cross checks them, because each one misses a different slice.
Certificate transparency logs record every certificate issued for your domains, which makes them one of the strongest sources for subdomain enumeration, including internal sounding hosts that were never meant to be public.
DNS enumeration, both passive from historical records and active against resolvers, fills in names that never had a certificate issued.
ASN and IP range mapping catches infrastructure not attached to a domain name at all. If you only enumerate subdomains you will never see a service answering on a bare address, and those exist in almost every environment. This is the gap that separates external asset discovery done properly from a subdomain list.
Cloud resource discovery works across accounts rather than across domains, finding storage, load balancers and managed services that belong to the organization but sit outside the main production account.
JavaScript bundle analysis. Your own application’s bundles frequently reveal API routes and hostnames the interface never visibly calls, which is why endpoint discovery from client code belongs in the process.
Public repositories and package registries are worth checking for internal hostnames, endpoints and keys committed by accident.
Change detection over time, comparing snapshots so a new record, a newly opened port or a newly provisioned resource is noticed while it is new rather than discovered by accident months later.
The last step is the one that separates a list from an inventory: manual confirmation that each candidate is live, is actually yours, and belongs to a known owner. Automated output without that step contains stale records, decommissioned hosts and assets belonging to someone else entirely, and a team handed one of those lists learns quickly to ignore it.
If you want to try part of this yourself, the tools page covers the reconnaissance side.
Why Scanners Do Not Solve This
Vulnerability scanners test what you point them at. That is a reasonable design, and it means their coverage is bounded by your inventory. If your inventory is wrong, your scanning is wrong in exactly the same places, and the result is a clean report describing a subset of your estate.
Attack surface tools go further and do discover assets, but most stop at the detection half. They list a host without confirming whether it is yours, whether it still resolves to something live, or whether it matters. The output is broad and unvalidated, so somebody has to triage it before it is usable, and that triage is the work.
The general problem is the same one that separates scanning from testing: automation is good at producing candidates and poor at judging them.
How to Improve Asset Visibility and Keep It
A detection exercise produces a snapshot. A snapshot is accurate on the day it is made and decays from then on, so the useful output is a process rather than a document.
Build the inventory from sources that update themselves. Your DNS zones, your cloud accounts, certificate transparency for your domains, and your API gateway or load balancer configuration, rather than a spreadsheet somebody maintains by hand.
Record an owner, an environment and a purpose for every asset. Anything without an owner is the first thing to review, because an unowned asset is one nobody is patching and nobody will notice being attacked.
Tie the inventory to the release process, so a new subdomain, endpoint or environment is registered when it is created and removed when it is retired. This is the only change that stops the drift at source rather than cleaning up after it.
Compare the inventory against what is actually reachable on a regular schedule, and investigate every difference in both directions. Something reachable that is not in the inventory is an unknown asset. Something in the inventory that is no longer reachable may be a decommission nobody recorded, or a service that is down.
Decommission properly. Remove the DNS record, revoke the credentials and delete the cloud resource, in that order, so nothing is left pointing at infrastructure you no longer control.
That last point is how you actually remediate exposed assets rather than just cataloguing them. A finding that stays on a list is not a fix.
How This Fits With Testing
Detection is not a substitute for testing, it is a precondition. If an asset is not visible it cannot be tested, and if it cannot be tested it cannot be secured. That is the whole argument, and it is why discovery is the first stage of a vulnerability assessment rather than an optional extra, and why reconnaissance is the first stage of a penetration test.
The sequence that works is detection, then scoping, then testing. Teams that skip the first step end up testing the systems they already knew about, which are usually the systems already receiving attention, while the forgotten staging host nobody scoped stays exactly as it was.
Between assessments, detection is the part that needs to keep running, because the surface changes with every deployment. That is what external attack surface monitoring is for.
Final Thoughts
Most organizations do not have a vulnerability problem before they have an inventory problem. The systems that cause incidents are rarely the ones under active review. They are the ones that fell out of scope so long ago that nobody thinks of them as production at all.
Exposed asset detection is not sophisticated work. It is certificate logs, DNS, cloud accounts, a few well chosen tools and someone willing to check every result by hand. What makes it valuable is that almost nobody does it consistently, and attackers do it as a matter of routine before they do anything else.
If you have never run it against your own domains, the first pass will find something. It usually does.
Frequently Asked Questions
What is exposed asset detection?
Exposed asset detection is the process of finding every system your organization has reachable from the public internet, including subdomains, API hosts, cloud resources, administrative interfaces and services with no DNS name at all. It is the discovery step everything else in a security programme depends on, because a system that is not on your list is not being patched, monitored or tested.
What is the difference between asset detection and asset visibility?
Detection finds assets. Visibility means understanding them: who owns each one, which environment it belongs to, whether it is genuinely reachable, and whether it should be exposed at all. Detection without visibility produces a list nobody can act on, because no owner is attached to any line of it.
Why do forgotten assets matter?
An asset nobody knows about is not patched, not monitored and not tested, so it sits at whatever security level it had the day it was deployed. Old staging environments, abandoned subdomains and unused API hosts are common entry points, and a subdomain still pointing at a released third party service can be claimed by someone else and served from your own domain.
How often should exposed asset detection run?
Continuously, because the surface changes with every deployment. A point in time snapshot is accurate on the day it is produced and decays from there. What matters is comparing the current reachable surface against the inventory on an ongoing basis, so a new host is noticed while it is new rather than months later.
Can exposed asset detection find things that have no domain name?
Yes, but only if the method includes ASN and IP range mapping. Detection that starts from your domain list and enumerates subdomains will never see a service answering on a bare IP address, and those are common in most environments.
Does a vulnerability scanner already do this?
No. A scanner tests what it is pointed at, so its coverage is limited by the inventory you give it. If the inventory is incomplete, the scan is incomplete in exactly the same places, and the report looks clean because nothing tested the systems that were missing.
How do you remediate an exposed asset once it is found?
Confirm ownership first, because acting on something that is not yours causes its own problems. Then decide whether it should exist. If it should not, decommission it properly: remove the DNS record, revoke any credentials it holds and delete the underlying cloud resource. If it should exist, bring it into scope, give it an owner and make sure it is covered by the same patching and monitoring as everything else.
