Attack Surface Management vs Vulnerability Scanning
Vulnerability scanning checks the assets you know about. External attack surface management finds the ones you don't. Why the forgotten server is the one that gets breached, and how the two disciplines fit together.
Almost every organisation that has been breached had a vulnerability scanner. The scanner was working correctly. It scanned the asset list it was given, found what was wrong, and reported it faithfully. The breach came through something that was never on the list.
That gap is the entire reason attack surface management exists as a separate discipline. Vulnerability scanning answers 'what is wrong with these assets?' Attack surface management answers the prior question nobody asked: 'what assets do we actually have exposed?'
| Vulnerability scanning | Attack surface management | |
|---|---|---|
| Starting point | An asset list you provide | Your domain name and company identity |
| Question answered | What is wrong with these? | What do we even have out there? |
| Finds shadow IT | No — it was never in the list | Yes, that is the primary purpose |
| Finds forgotten subdomains | No | Yes |
| Finds expired or misissued certificates | Sometimes | Yes |
| Finds a marketing microsite nobody maintains | No | Yes |
| Perspective | Usually inside the network | Outside, as an attacker sees you |
| Cadence | Scheduled scans | Continuous discovery |
| Depth per asset | Deep — full vulnerability check | Shallower per asset, far broader |
The asset list is the flaw
Every vulnerability management programme rests on an inventory, and every inventory in every organisation is wrong. Not through negligence — through the ordinary way organisations work. Someone in marketing commissions a campaign microsite through an agency. A developer spins up a staging environment on a cloud account billed to a departmental card. A supplier integration is stood up for a pilot, the pilot ends, the endpoint stays. An acquired company brings twelve domains, of which your team is told about four.
Every one of those is internet-facing, none of them appear on the list handed to the scanner, and none of them are patched by whatever process patches the assets you do know about. They sit there, running whatever version was current when they were deployed, indefinitely.
Attackers do not work from your asset list. They enumerate your domain, certificate transparency logs, cloud address ranges and public records, and they find the microsite from 2021 running an unpatched CMS. Then they use it as the foothold. The scanner was never wrong; it was simply asked the wrong question.
What attack surface discovery actually does
External attack surface management starts from your identity rather than your inventory. Given a company name and a domain, it works outward: enumerating subdomains, reading certificate transparency logs for hostnames you have issued certificates against, resolving addresses, identifying cloud ranges you control, fingerprinting the services and technologies running on what it finds, and doing so repeatedly rather than once.
The output is an inventory built from observation instead of memory. It is invariably larger than the one the organisation believed it had — in our experience the first run is uncomfortable for every client, without exception. That discomfort is the value being delivered.
Continuity matters as much as the initial discovery. A one-off external assessment produces a snapshot that begins decaying the moment it is delivered, because your surface changes every week that anyone deploys anything. Continuous discovery catches the new exposure within days of it appearing, which is the difference between a finding and an incident.
Why this is not just a scanner pointed at more things
A reasonable objection: could you not simply scan a wider range? Partly, and doing so is better than nothing. But the disciplines differ in three ways that matter.
First, attribution. Finding a host is easy; establishing that it is yours, and not a shared-hosting neighbour or an unrelated company with a similar name, is the hard part. Scanning something you do not own is at best rude and at worst unlawful, so the attribution logic is not optional.
Second, perspective. Most vulnerability scanning is performed from inside the network, where the scanner reaches things through paths an internet attacker cannot use, and misses how the asset actually presents from outside. The external view is the one that matters for the initial foothold.
Third, change detection. The valuable signal is often not 'this host has a vulnerability' but 'this host did not exist last week', or 'this domain's certificate was issued by someone other than us'. Those are inventory events, not vulnerability events, and a scanner has no framework for them.
- Run attack surface discovery first, then feed what it finds into vulnerability scanning. Discovery without depth leaves you knowing about problems you cannot rank.
- Treat the first discovery run as an inventory reconciliation exercise, not a security finding. Decide what to decommission before you decide what to patch.
- Decommissioning is a legitimate and often the cheapest remediation. The forgotten microsite usually does not need patching; it needs switching off.
- Re-run continuously. A surface mapped once is a surface that was accurate once.
How the two fit together
They are sequential rather than competing. Attack surface management establishes what exists; vulnerability scanning and penetration testing establish what is wrong with it. Running the second without the first means auditing a subset of unknown size, which is why organisations with clean scan reports still get breached.
A workable programme looks roughly like this. Continuous external discovery maintains the true inventory. Everything discovered is triaged into owned-and-needed, owned-and-should-be-decommissioned, or not-ours. Assets in the first category go into vulnerability scanning on a schedule. The genuinely important ones — the customer portal, the payment integration, the API — get an annual penetration test, because a scanner cannot find broken access control or business-logic flaws. Changes to the surface generate alerts in their own right.
Notably, the cheapest remediation in that flow is not patching. It is decommissioning. A substantial share of what external discovery surfaces should simply not exist any more, and turning it off costs nothing and removes the risk permanently.
The Kenyan context
Two local patterns make this discipline unusually valuable here. The first is rapid digital expansion: organisations that have launched customer portals, mobile integrations, agent platforms and API partnerships over a compressed period, often through several different vendors, frequently have no single authoritative record of what was deployed and by whom. The surface grew faster than the governance around it.
The second is vendor turnover. Where systems have been delivered by a succession of agencies and contractors, assets routinely outlive the relationship with whoever built them — still running, still exposed, with no one holding responsibility for patching them and sometimes no one holding the credentials.
External discovery cuts through both, because it does not depend on institutional memory or on any vendor's cooperation. It observes what is reachable and reports it. For organisations subject to the Kenya Data Protection Act there is a compliance dimension as well: demonstrating appropriate technical measures is considerably harder if you cannot evidence that you know what systems process personal data in the first place.
Key takeaways
- Vulnerability scanning checks the assets on your list. Attack surface management finds the assets that were never on it — which is where breaches typically begin.
- Every organisational asset inventory is incomplete, through normal working practice rather than negligence. Attackers enumerate; they do not consult your list.
- Discovery must be continuous. A surface mapped once was accurate once.
- The cheapest remediation is decommissioning, not patching — much of what discovery surfaces should no longer exist.
- Run discovery first, then scan and test what it finds. Scanning without discovery audits a subset of unknown size.
Frequently asked questions
What is attack surface management?
Attack surface management is the continuous discovery, inventory and monitoring of everything your organisation exposes to the internet — domains, subdomains, hosts, IP ranges, services, certificates and cloud assets. When performed from outside, as an attacker would, it is usually called external attack surface management or EASM. Its defining characteristic is that it starts from your identity rather than from an asset list you supply, which is what allows it to find the assets you had forgotten about.
How is attack surface management different from a penetration test?
Breadth versus depth. Attack surface management continuously maps everything you expose, but examines each asset relatively shallowly. A penetration test examines a small number of chosen targets very deeply, with a human attempting real exploitation and chaining flaws together. They are complementary: discovery tells you what deserves a penetration test, and a test proves what an attacker could actually do with what discovery found.
Will attack surface management find our shadow IT?
It will find the internet-facing part of it, which is the part that matters most for an initial foothold — the unsanctioned cloud instance, the agency-built microsite, the staging environment left publicly reachable. It will not find purely internal shadow IT such as an unapproved application running only inside the network, since nothing outside can observe it. For that you need internal discovery, which some platforms including NeuroThreat provide through in-network collector agents.
How often should the attack surface be mapped?
Continuously, or as close as your tooling allows. The value is in change detection — a host that appeared this week, a certificate issued by someone other than you, a service newly exposed — and change detection requires a baseline that stays current. Annual or quarterly mapping produces a document that is out of date before it is circulated, in any organisation that deploys anything.
Is attack surface management legal to run against our own assets?
Discovery of your own footprint using publicly available sources — DNS, certificate transparency logs, public records — is passive observation of information already published and raises no issue. Active scanning is different: only scan what you own or have written authorisation to scan, since scanning third-party infrastructure without permission may constitute an offence under Kenya's Computer Misuse and Cybercrimes Act. This is precisely why attribution is a core part of the discipline rather than a detail, and why any credible platform requires an authorisation attestation before an active scan.
We have a CMDB. Do we still need this?
A configuration management database records what was deployed through your processes. Attack surface management records what is actually reachable, including everything deployed outside those processes. The gap between the two is the finding. Organisations with mature CMDBs are often the most surprised by their first discovery run, because the CMDB's completeness creates a confidence that the external view then contradicts.