Back to glossary

Attack surface

7 min read

In security, the attack surface of an organisation is the complete set of points where someone outside it can interact with something inside it: domains, exposed services, APIs, client applications, third-party integrations and people. It is not a list of vulnerabilities. It is the list of places a vulnerability would count, and it changes daily.

July 24, 2026
Compartir:

How it works

The attack surface is defined by reachability, not by intent. An asset belongs to it if something outside your control can send it a message and get a response, whether or not anyone meant to publish it, and whether or not it appears in an inventory.

It is usually split three ways. The external surface is everything reachable from the internet: domains and subdomains, listening services, web applications, APIs, mail infrastructure, remote access, cloud storage set to public. The internal surface is what a foothold reaches, which in a flat network is very nearly everything. The human surface is the set of people who can be reached and persuaded, which is the one that never appears in a scan.

Two properties are easy to miss and decide most of the difference between an inventory and reality. The first is that the surface expands without any decision being taken: a certificate is issued, a developer publishes a test host, a marketing agency parks a subdomain on their platform, a supplier integration opens a new API. The second is that it is transitive. An identity provider that federates into your tenant, a support tool with a session in your console, a library your build pulls in: all of them are places an attacker can push from, and none of them are your servers.

Measuring it is enumeration rather than assessment: certificate transparency logs, passive DNS, the cloud accounts you know about and the ones you find, code repositories and mobile application bundles that name back-end hosts, and mail and DNS records that describe suppliers. The output is a list of things that answer, which is where testing starts and not where it ends.

What goes wrong

The gap between the asset register and what answers on the internet is the single most productive thing we find on an external engagement, and it is almost never a technology failure. It is an ownership failure.

Every organisation has hosts that nobody claims. A campaign site from three years ago, still resolving, still running the content management system it was built on, still holding a database with the entries from a competition. A staging environment with production data and no authentication because it was meant to be temporary. An acquired company’s domain, still pointed at their old provider, still carrying a wildcard certificate. These are not exotic, they are the default state of an estate that has been growing for a decade.

Subdomain takeover is the clearest example of the mechanism. A DNS record continues to point at a cloud service after the resource behind it was deleted. The name is yours; the content it now serves belongs to whoever registers that resource next. It costs an attacker nothing, and it hands them a hostname inside your domain that browsers, session cookies and staff will trust.

The reason this survives is that nothing breaks. An orphaned host does not raise a ticket. It does not fail a health check that anyone is watching, because nobody set one up. It gets found when somebody enumerates certificate transparency logs, which takes minutes, and which attackers do continuously and most organisations do never.

Attack surface, attack vector and exposure

These three get used interchangeably in the same paragraph of the same report, and they are different quantities with different owners.

Attack surface Attack vector Exposure
What it is Every reachable point The route used through one of them A reachable point with a weakness that matters
Countable? Yes, by enumeration Only after the fact Yes, and it is the number worth tracking
Changes when Something is published or removed An attacker chooses a path A vulnerability, a credential or a configuration changes
Who reduces it Whoever owns publication and DNS Nobody directly Whoever owns the asset
Sensible target Smaller Not applicable Zero for the reachable and critical

The distinction matters because the metric people report is usually the wrong one. Counting the attack surface tells you how large the estate is. Counting exposure, which is exposure management rather than vulnerability counting, tells you how much of it is a problem right now. A growing surface with flat exposure is a company growing safely.

Common mistakes

Confusing the CMDB with the surface. The register lists what was provisioned through a process. The surface includes what was not.

Scanning only the ranges you own. Most of the modern surface is not in your address space. It is in cloud accounts, in software-as-a-service tenants and on providers’ shared infrastructure, found by name rather than by address.

Treating shadow IT as a policy problem. A department buying a tool with a card is responding to a real need. The security answer is discovery and onboarding, not a memo. The part that does need enforcing is that it does not carry corporate identity or data by default.

Forgetting people and third parties. Staff who can be phoned, suppliers with standing access to your tenant, and integrations with long-lived tokens are all reachable, and none appear in an external scan.

Measuring once a year. Certificates are issued in minutes and cloud resources in seconds. An annual enumeration describes an estate that no longer exists.

How to reduce it

Reduction is mostly deletion, and deletion needs ownership. Every hostname, every listening service and every cloud account should map to a named team, and anything that does not map is the first work item. In practice, running the discovery is easy and assigning the results is the part that takes months.

Then make expansion visible. Watch certificate transparency for your domains, alert on new records in your zones, and review DNS entries that point at third-party services against whether the resource behind them still exists, which is what closes subdomain takeover before it opens. Give the estate a default of closed: no public storage, no management interface on the internet, no remote access without an identity check. Standing infrastructure benefits from hardening baselines applied on build rather than corrected afterwards.

Track the trend that matters. Not the number of assets, which will grow, but the age of the oldest unowned asset and the time between a host appearing and somebody claiming it. Those two numbers describe a process; a total does not. Continuous attack surface management is the tooling category built for this, and it is worth exactly as much as the ownership process behind it.

Where this shows up in an audit

An external engagement starts here, and the enumeration is a deliverable in its own right. We hand over the full list of what answers, how each item was found, which are confirmed as the client’s and which we could not attribute, because the unattributable ones are usually the interesting ones. The list is dated, because it is a snapshot.

The finding written against attack surface is not a vulnerability. It is a delta: what we found that the client did not know they had. Severity is not the count. It is the worst thing on a host nobody claims, which is why the same enumeration next quarter reads very differently once the ownership work has been done.

This enumeration is where an external engagement begins, before anything is tested at all.

FAQ

What is the difference between attack surface and attack vector? The surface is every point that can be reached. A vector is the specific path an attacker used through one of those points. You can reduce a surface deliberately; you only ever learn a vector afterwards.

How often should attack surface be measured? Continuously, because it changes continuously. A quarterly review of the deltas is a reasonable human cadence on top of automated discovery, and an annual snapshot on its own is close to useless.

Does reducing attack surface make us secure? It makes fewer things count. A smaller surface with the same weaknesses on it is still exploitable; what reduction gives you is less to defend and fewer places to be surprised. It pairs with reducing exposure, not with replacing it.

Is our asset inventory the same thing? No. An asset inventory is what you provisioned deliberately. The attack surface is what actually answers, which includes everything provisioned outside the process and everything nobody removed.

¿Quieres ver cómo trabajamos en Asperis Security?

Agenda 30 minutos con uno de nuestros especialistas. Revisamos tu stack y te decimos qué conviene probar primero.