Ask a security team to list every internet-facing asset the organisation owns and you will get a confident answer that is incomplete. Not through negligence. The external attack surface changes continuously, and almost none of those changes are routed through security.
Marketing stands up a campaign subdomain. A team ships a staging environment and forgets it. An acquisition brings infrastructure nobody has inventoried. A cloud service gets a public endpoint by default. A vendor hosts something on a subdomain you delegated three years ago. None of these generate a ticket.
External attack surface monitoring is the practice of continuously discovering and assessing what is actually reachable from the internet, rather than what an asset register says should be.
What attack surface monitoring covers
The external attack surface is everything an outsider can reach without credentials: domains and subdomains, IP ranges and the services listening on them, cloud storage endpoints, exposed admin panels and dashboards, API endpoints, certificates, DNS records, and the third-party services operating under your name.
Three properties make it a monitoring problem rather than an audit problem.
It changes without notice. The interval between an asset appearing and anyone in security knowing about it is the window that matters, and a quarterly review makes that window a quarter long.
It extends past what you provisioned. Delegated subdomains, vendor-hosted services and acquired infrastructure are part of your surface and usually absent from your inventory.
The interesting assets are the forgotten ones. A maintained production service is patched and monitored. A staging box from a project that shipped two years ago is neither, and it is on the same surface.
The discovery sources that matter
Discovery is mostly a collection problem against public sources, and no single source is sufficient.
Certificate transparency logs. Every publicly trusted certificate is logged, which makes CT the most reliable subdomain discovery source available. It finds hosts nobody advertises, including internal-sounding names that were never meant to be public.
Passive DNS and DNS enumeration. Historical and current resolution data, which surfaces hosts that no longer appear in your zone but still resolve somewhere.
Registries and WHOIS. Domain ownership and registration data, useful for finding domains acquired or defensively registered years ago and never inventoried.
ASN and IP range data. What address space is attributed to your organisation, which anchors the network side of the surface.
Cloud provider ranges. Public endpoints in your accounts, which are frequently the fastest-growing part of the surface.
Public code and package repositories. Not for secrets hunting, which is its own discipline, but because repositories reference hostnames, endpoints and infrastructure that discovery would otherwise miss.
Job postings and public technical content. Listings name the stack in detail. That is legitimate open-source intelligence about your own footprint, and it is also what an attacker reads first.
The OSINT collection methods behind several of these are covered in residential proxies for threat intelligence and OSINT.
Your own network sees a friendlier internet
This is the part that surprises teams, and it is the strongest argument for taking the vantage point seriously.
Scanning your own surface from your corporate egress produces a systematically optimistic picture, because your own addresses are frequently allowlisted. WAF rules exempt them. Geographic restrictions do not apply to them. Rate limits are relaxed for them. Staging environments are open to the office range. A resource that is firewalled to corporate IPs looks reachable and fine from inside, and invisible from anywhere else, which is exactly the distinction you were trying to measure.
The inverse also happens. A service intended to be internal is reachable from outside because a rule was scoped wrongly, and you will never see that from a vantage point the rule exempts.
Geography compounds it. CDN and WAF configurations often differ by region, and a service can be exposed in one geography and blocked in another. An organisation with customers in several markets has an attack surface in each of them, and observing from one country reports one country’s surface.
Using residential exits in the regions you care about means observing your own surface the way an ordinary outsider would. With the Shifter gateway, the vantage point goes in the credentials against p.shifter.io:443:
customer-USERNAME-country-de-sid-easm-de-04-ttl-600:PASSWORDcountry-de sets the observation point, and sid-easm-de-04 holds one exit across a scan pass so results are attributable to a single vantage point rather than mixed across several. Keep request rates modest and back off on errors, as in rate limiting and request throttling. The product view is on the cybersecurity and OSINT proxies page.
Stay inside the authorisation boundary
Attack surface monitoring is observation of assets you own or are contractually authorised to assess. That boundary needs to be explicit, written down, and narrower than your curiosity.
Monitor, do not exploit. Discovery and identification are one activity. Probing a vulnerability to confirm it is another, and it belongs inside a scoped, authorised test with its own agreement.
Get authorisation in writing, including for subsidiaries and vendors. Assets that appear to be yours may be operated by a third party under terms that do not permit your testing.
Keep collection passive where passive works. Certificate transparency, passive DNS and registry data require no interaction with the asset at all, and they find most of what matters.
Coordinate with legal and with your own detection team. Monitoring traffic that nobody was told about wastes an incident response cycle, and repeatedly.
Continuous means diffing, not rescanning
The output of attack surface monitoring is not an asset list. It is a stream of changes against a known baseline, because the list is too large to review and the changes are what carry risk.
Maintain a baseline of assets with, for each one, first seen, last seen, resolved addresses, open services, certificate details and issuer, hosting provider, observed geography, and an owner. Then alert on the transitions rather than the state:
| Change | Why it matters |
|---|---|
| New host appears | Something was deployed that security did not know about |
| Service newly reachable | A port or endpoint opened, deliberately or otherwise |
| Certificate about to expire, or newly issued by an unexpected issuer | Expiry causes outages; unexpected issuance can indicate a takeover |
| DNS record points somewhere new | Including at a decommissioned provider, the classic subdomain takeover setup |
| Host stops resolving while the DNS record remains | The dangling record an attacker can claim |
| Technology fingerprint changes | A component was replaced, or a known-vulnerable version appeared |
Dangling records deserve particular attention. A CNAME pointing at a cloud resource that no longer exists is not a cosmetic problem, because whoever can register that resource next inherits your subdomain.
Cadence should follow risk. Certificate transparency is near real-time and worth consuming continuously. Full enumeration weekly is usually enough. Critical assets deserve a faster loop.
Make the findings owned, or nothing gets fixed
The failure mode of a mature monitoring program is a large accurate inventory that nobody acts on.
Every asset needs an owning team recorded against it, assigned at discovery rather than at incident time. Findings need a severity model that reflects exposure and asset criticality, not just a scanner’s score. And there needs to be a route by which an unowned asset becomes someone’s problem, since orphaned assets are the ones that turn into incidents.
Track the metric that reflects the actual risk: the time between an asset appearing on the internet and appearing in your inventory. Shrinking that number is what the program is for.
FAQ
How is this different from a vulnerability scan?
A vulnerability scan assesses assets you already know about. Attack surface monitoring finds the ones you do not, which is why it runs first and continuously.
Do I need external vantage points if I already scan from our own infrastructure?
Yes, because your infrastructure is frequently allowlisted and exempt from the controls you are trying to verify. Scanning from inside measures a friendlier internet than your attackers see.
Is certificate transparency enough on its own?
It is the single most productive source and it is not sufficient. It misses hosts that never received a public certificate, and it says nothing about which services are actually listening.
How do we handle assets belonging to an acquisition?
Treat the acquisition as a new surface and run discovery against it explicitly, before assuming its inventory is accurate. Acquired infrastructure is consistently the least documented part of an organisation’s footprint.
The bottom line
You cannot defend an asset you do not know exists, and the register will always lag reality. Continuous external attack surface monitoring closes that gap by discovering what is actually reachable, from vantage points that are not exempt from your own controls, and alerting on changes rather than restating a list.
Discover from multiple public sources, observe from the regions your users are in, keep collection inside a written authorisation boundary, diff against a baseline, and give every asset an owner. Rates for the collection layer are on the pricing page.