There's a category of breach that security teams find uniquely embarrassing: the asset that nobody remembered existed. The staging server that was stood up for a product demo two years ago and never decommissioned. The S3 bucket an engineer created for a hackathon project that somehow ended up with production data in it. The subdomain pointing to an old Heroku app that was abandoned when the team switched cloud providers. These aren't sophisticated attacks. They're failures of basic inventory management.
Research from CyCognito and similar firms consistently finds that approximately 45% of data breaches involve assets that weren't part of the organization's known attack surface - machines, services, and applications that security teams either didn't know about or had marked as decommissioned but that were still running. This isn't a fringe finding. It's the dominant pattern in modern enterprise breaches.
Shadow IT and the Forgotten Assets Problem
Shadow IT - technology acquired or deployed by employees without formal IT approval - has exploded alongside the cloud and SaaS revolutions. It used to be hard to stand up unauthorized infrastructure. Now any developer can create a new AWS account, spin up a dozen EC2 instances, and have a running service in an hour. No ticket, no approval, no entry in the CMDB. When they leave the company or move to a different team, those resources keep running.
The same dynamic plays out with SaaS applications. Individual contributors sign up for tools using a corporate credit card or a personal card they expense later. Those tools may have integrations that access company data - Slack messages, Google Drive files, customer records. When the employee churns or the tool falls out of favor, the integration often persists. An attacker who finds a credential for that forgotten SaaS tool may have access to data the company doesn't realize is being shared.
Certificate transparency logs have made this problem visible in an interesting way. Every publicly trusted TLS certificate is logged to append-only public ledgers. You can query these logs to find every subdomain that has ever received a certificate under your domain. What you find is often surprising - subdomains from test environments, old product iterations, acquired companies, and long-running internal tools that someone put behind a real certificate years ago. Each one is a potential entry point.
ASM vs. Vulnerability Management: An Important Distinction
Vulnerability management assumes you know what you have and focuses on whether those known assets have known vulnerabilities. It's scan-based work: run a tool against your defined scope, get a list of CVEs, prioritize and remediate. This is important work, but it starts from a premise - "here is our asset inventory" - that is often significantly incomplete.
Attack surface management starts upstream of that. The core question is "what does our organization look like from the outside?" It involves continuous discovery - probing the internet to find assets that are associated with your organization, regardless of whether they appear in your official inventory. DNS records, certificate transparency logs, WHOIS data, passive DNS datasets, and technologies like Shodan and Censys are the raw inputs. The output is a continuously updated map of your actual external exposure.
The two practices are complementary, not competitive. Good security programs do both. But if you're a smaller organization choosing where to focus first, ASM often has higher ROI because it finds the unknown unknowns - the assets that are completely outside your existing vulnerability scanning scope.
What Continuous Discovery Actually Looks Like
Manual ASM is impractical at any significant scale. If you have a mid-sized technology company with multiple product lines, acquired companies, and dozens of developers who've been spinning up infrastructure for years, conducting a manual asset inventory is a months-long project - and it's out of date before you finish it.
Automated ASM tools work by continuously querying the same sources an attacker would use. They start from seed data - your primary domains, IP ranges, ASN numbers, and known brand names - and expand outward through DNS enumeration, certificate log analysis, and port scanning. They then continuously monitor for changes: new subdomains appearing, services changing ports or technologies, certificates expiring, cloud storage buckets becoming public.
The goal isn't a one-time report - it's a live inventory that alerts you when something unexpected appears. When a developer stands up a new staging environment that's publicly accessible, you want to know within hours, not discover it 18 months later during an incident post-mortem.
Where to Start If You're Starting From Zero
The quickest thing you can do today is run your primary domains through a certificate transparency log search. Go to crt.sh, type in your organization's domain, and look at what comes back. For most companies with more than a year of history, you'll find subdomains you didn't know about. Some will be fine - CDN endpoints, email verification services, forgotten redirects. Some will be running live services. Go check each one.
The next step is standing up automated monitoring. Tools like ProjectDiscovery's subfinder, amass, and the Shodan API can be combined into a basic continuous scanning pipeline with modest engineering effort. For organizations that want a commercial solution with less maintenance overhead, dedicated ASM platforms provide more comprehensive coverage with better alerting.
The uncomfortable truth about attack surface management is that most organizations don't do it because they're afraid of what they'll find. That logic is backwards. The attacker isn't going to be squeamish about looking. The question is whether you find the forgotten server before they do.