Attack surface management (ASM) is the ongoing practice of finding, cataloguing and reducing everything your organization exposes to the internet: domains, subdomains, IP addresses, certificates, cloud resources and the services running on them. The key is to build that list from the outside in, the way an attacker would, instead of trusting what your records say you own. Done well, it keeps answering three questions: what do we have online, what's risky about it, and who is responsible for fixing it?
Most organizations find something they didn't know about the first time they look. Usually it's mundane: a staging server left running after a project, a marketing microsite on a forgotten hosting account, a remote access portal nobody decommissioned. That's exactly what makes these assets dangerous. Nobody patches what nobody remembers.
What is attack surface management?
Your attack surface is the sum of every point where someone could try to get in or pull data out. That includes internal systems, but the part most teams underestimate is the external attack surface: anything reachable from the public internet without prior access.
External attack surface management (EASM) focuses on that outer layer. It combines discovery, assessment, prioritization and remediation. Then it repeats all four on a schedule, because the internet-facing footprint changes every week.
How is ASM different from vulnerability scanning?
A vulnerability scanner checks the targets you give it. If an IP address or hostname isn't on the list, it never gets scanned. ASM handles the step before that: finding the targets in the first place, including ones outside the network ranges and cloud accounts you know about.
The two work best together. ASM feeds a more complete target list into vulnerability management, and vulnerability scanning adds depth to what ASM finds.
Why is your asset inventory probably incomplete?
Internal inventories are built from what IT provisions. The internet-facing footprint grows through plenty of other channels:
- Shadow IT. Teams sign up for SaaS tools, spin up hosting or register domains on a corporate card without telling IT.
- Forgotten cloud assets. Test environments, proof-of-concept virtual machines, storage buckets and load balancers outlive the projects that created them.
- Old infrastructure. Legacy VPN concentrators, mail gateways and file transfer servers get kept "just in case".
- Mergers and acquisitions. An acquired company brings its own domains, IP space and cloud accounts, often with little documentation.
- Third parties. Agencies and contractors host sites or APIs on your behalf, sometimes under your domain name.
- DNS debris. Records still point to IP addresses or cloud services you no longer control.
That last one deserves attention. When a DNS record such as a CNAME points to a cloud resource that has been deleted, someone else may be able to claim that resource and serve their own content on your subdomain. This is called subdomain takeover, and it comes from poor cleanup rather than any clever attack.
How do you discover your external attack surface?
Discovery starts with a few known "seeds" and expands outward. Each new finding can lead to more.
Start with the seeds you already have
Gather what you know for certain:
- Registered domain names, including country-code and legacy domains
- Public IP ranges and any autonomous system numbers (ASNs) you hold
- Cloud provider accounts, subscriptions and projects
- Company and brand names used in registrations and certificates
Domain registrar accounts are a good early stop. It's common to find domains registered years ago by former staff or agencies, sometimes under personal accounts.
Enumerate DNS
DNS is the closest thing you have to a map of your public footprint. Useful sources include:
- Your authoritative DNS zones. Export them. Every A, AAAA and CNAME record is a potential asset, and every record pointing somewhere you don't recognize is a question to chase.
- Passive DNS data. Historical resolution data shows subdomains that existed in the past and may still be live.
- Subdomain enumeration. Open-source tools such as OWASP Amass pull from many sources to find subdomains you didn't list.
- Mail and verification records. MX and TXT records, including SPF includes and domain verification tokens, reveal which SaaS providers act on your behalf.
Search Certificate Transparency logs
Certificate Transparency (CT) is a public, append-only logging system for TLS certificates, first described in RFC 6962 in 2013. Publicly trusted certificate authorities log the certificates they issue, and major browsers now expect certificates to show up in those logs.
For defenders, that makes CT logs one of the richest discovery sources available. Search them for your domains (free services such as crt.sh make this easy) and you'll see the hostnames people have requested publicly trusted certificates for, including internal-sounding names like vpn-old, jira-test or dev-api. Wildcard certificates hide individual hostnames, but most organizations still reveal plenty.
CT logs also work as an early warning. Monitoring them for new certificates on your domains tells you when someone in the business stands up a new public service, often before IT hears about it.
Map IP ranges and cloud accounts
Scan your known public IP ranges regularly, not just the addresses you expect to be in use. In cloud environments, pull lists of public IPs, load balancers, API gateways, storage endpoints and serverless functions directly from each account's APIs. If some accounts sit outside central management, finding them is part of the job.
Identify exposed services
Once you have hostnames and IP addresses, find out what's actually listening. Port scanning and service fingerprinting reveal open ports, software versions, login pages and TLS configuration. Internet-wide scan datasets can supplement your own scans, but confirm what they show before you act on it.
What should you look for first?
Not every exposed asset is a problem. A public website is supposed to be public. These exposures should jump the queue:
- Remote access and administration interfaces: RDP, SSH, VPN portals, and hypervisor or firewall management pages
- Databases and caches reachable from the internet
- Cloud storage that allows public read or list access
- Development, staging and test environments, which often run older code and weaker authentication
- Software versions listed in CISA's Known Exploited Vulnerabilities catalog
- Login pages without multi-factor authentication, where stolen credentials could be reused
- Dangling DNS records open to subdomain takeover
- Expired certificates, which usually point to neglected systems
How do you prioritize attack surface findings?
A first discovery run can produce hundreds of findings. Rank them on a small set of factors instead of treating them all as equal.
| Factor | Question to ask | Higher priority when… |
|---|---|---|
| Exposure | What is reachable, and by whom? | An admin interface or data store is open to the whole internet |
| Exploitability | Is there a known, practical way in? | The software has a known exploited vulnerability or weak authentication |
| Data and access | What could an attacker reach through it? | It holds sensitive data or connects to internal systems |
| Ownership | Does anyone know it exists? | No owner can be identified |
| Purpose | Does it still need to be online? | It's left over from a finished project |
The last question is underrated. Decommissioning an unneeded asset removes it from the attack surface entirely, which beats patching it every month for the next five years.
Who should own each asset?
Discovery without ownership just produces a longer list of problems. Every asset you find needs a named owner who can decide whether it stays and who fixes it when something is exposed.
A few habits make this workable:
- Record ownership at creation. Require owner and purpose tags on cloud resources, and enforce them where your platform allows.
- Treat "unclaimed" as a signal. If nobody claims an asset after a reasonable effort, schedule it for shutdown after a documented grace period.
- Route findings to owners, not a shared inbox. A finding assigned to "IT" tends to stay there.
- Set remediation timelines by severity. For example, fix internet-exposed admin interfaces within days and lower-risk issues within the normal patch cycle.
- Bring procurement and legal in. New domains, hosting purchases, SaaS contracts and acquisitions should all trigger an asset registration step.
How often should you run discovery?
Your external footprint changes whenever someone deploys, registers or forgets something. A quarterly exercise will miss a lot.
For a benchmark, look at the US federal government. In October 2022, CISA issued Binding Operational Directive 23-01, which requires federal civilian agencies, by April 3, 2023, to perform automated asset discovery every seven days and to enumerate vulnerabilities across all discovered assets every 14 days. The directive covers agency networks broadly, not just internet-facing assets, and it doesn't apply to private companies. The cadence is still a sensible reference point.
A practical rhythm for a small or mid-sized organization looks like this:
- Continuous or daily monitoring of CT logs and DNS changes
- Weekly scans of known IP ranges and hostnames
- Monthly review of new and unowned assets with the relevant teams
- Quarterly review of registrar accounts, cloud accounts and third-party hosting
ASM also fits neatly into established frameworks. The first of the CIS Critical Security Controls (v8) is inventory and control of enterprise assets, and ASM is how you keep the internet-facing part of that inventory honest.
Frequently asked questions
Do we need a dedicated ASM platform?
Not necessarily. Smaller organizations can get a long way with DNS exports, CT log searches, open-source enumeration tools and scheduled port scans. Dedicated platforms mainly add automation, correlation and continuous monitoring at scale, which matters more as your footprint grows.
Is it safe to scan our own assets?
Scanning assets you own or are authorized to test is standard practice. Be careful with assets you think are yours, such as addresses in shared cloud IP space or systems a third party hosts for you. Confirm ownership, and check your cloud and hosting providers' testing policies before running active scans.
How is ASM different from a penetration test?
A penetration test is a point-in-time, in-depth attempt to exploit a defined scope. ASM is continuous and broad, and its main job is making sure that scope is complete. Pen testers can only test what they know about, so ASM output makes their work better.
What about assets our vendors host?
If a vendor runs a service under your domain or holds your data on an internet-facing system, it's part of your attack surface. Include those assets in discovery, and make sure contracts spell out who fixes exposures and how quickly.
Next steps
If you haven't looked at your organization from the outside recently, start small:
- Export your DNS zones and search CT logs for every domain you own.
- List your public IP ranges and cloud accounts, then scan them for open services.
- Flag remote access interfaces, exposed data stores and anything nobody recognizes.
- Assign an owner to every asset, and decommission what no longer needs to exist.
- Put discovery on a weekly schedule so the inventory stays current.
You won't get a perfect map on day one. Aim for a map that gets more accurate every week, with a name next to every item on it.