What is an attack surface and why does it change continuously?

Understand what an attack surface is, which assets and exposures make it up, why it changes continuously, and how that can affect cyber risk.

ByLeonnes Cybersecurity | 4 August 2026

Lion Focus — attack surface inventory: subdomains, websites, IP addresses and cloud assets under monitoring

When an organization starts mapping its attack surface, one of the first surprises is often quite simple: things show up that nobody remembered were still exposed.

A subdomain created for an old campaign. A test application that remained accessible. An IP address associated with a service that should have been decommissioned. An API used by an integration that changed months ago.

There is not always a vulnerability in those assets. That is not necessarily the problem.

The first problem is discovering that they still exist — and that someone outside the organization can find them.

That is a useful starting point for understanding what we call the attack surface.

What is part of the attack surface?

Broadly speaking, the attack surface is the set of assets, systems, applications, services, interfaces, and other points that an attacker can reach or use in an attempt to access systems, obtain sensitive data, or compromise an organization.

NIST defines attack surface in terms of the points in a system or environment where an attacker can try to enter, cause an effect, or extract data.

In practice, this may include websites and web applications, IP addresses, published ports and services, APIs, cloud environments, mobile applications, public repositories, and other components that connect an organization to the Internet.

But an attack surface is more than a list of assets.

Imagine an organization has 200 subdomains.

That number alone tells us very little.

Some may point to important, well-managed applications. Others may no longer respond. One could be a forgotten legacy environment. Another may expose vulnerable technology. There may even be a subdomain that is not part of the organization’s official inventory at all.

They all appear during discovery. But from a security perspective, they do not necessarily mean the same thing.

This is where we start moving beyond a simple inventory and looking at how those assets are exposed.

The difficulty is that this inventory does not stand still

If the attack surface were relatively static, a thorough assessment a few times a year and an updated spreadsheet might be enough.

In reality, it changes all the time.

New applications go into production. Environments are created for temporary projects. Cloud services are published. APIs appear to support new integrations. Suppliers begin operating parts of the environment. IP addresses change. Applications are migrated.

And there is also the opposite path: systems that should disappear but never disappear completely.

This is particularly interesting because, internally, the system may no longer be considered part of the operation. The team changed, the project ended, the application was replaced.

From the outside, however, it only needs to remain reachable.

The problem with a forgotten asset is that the attacker usually has not forgotten it.

Not because someone is specifically watching that asset, but because the Internet can be continuously searched, indexed, and analyzed. An old service does not need to be in the official inventory to be found.

OWASP, for example, includes attack surface identification among the information-gathering activities used in web application security testing. The logic is straightforward: before looking for ways to compromise an environment, you first need to understand what exists and where the possible entry points are.

That is also why an external view often reveals interesting situations.

It does not necessarily start from what the organization believes it owns. It starts from what can actually be found.

Not every change needs to happen to the asset itself

There is another aspect of the attack surface that can easily go unnoticed.

An asset can remain exactly as it was yesterday and still deserve more attention today.

Imagine a service that has been exposed to the Internet for months. No configuration has changed. The address is the same, the port is still open, and the software version has not changed either.

Then a new vulnerability is disclosed for that version.

A few days later, public exploit code appears.

Later, evidence of exploitation in the wild begins to emerge.

From an inventory perspective, almost nothing happened.

From a risk perspective, quite a lot happened.

This is why monitoring the attack surface is not only about discovering new assets. It is also about noticing when the context around something already exposed changes.

That is one reason why a point-in-time snapshot of the environment ages relatively quickly.

Attack surface is not the same as attack vector

The two concepts often appear together, and they are easy to mix up.

The attack surface represents the points an attacker can reach or use.

An attack vector is the path or method used to try to exploit one of those points.

A public web application, for example, is part of the attack surface. A vulnerability in that application may allow it to become part of an attack vector.

But an attack vector can begin in other ways.

A leaked corporate credential may provide access to a remote service. A secret exposed in a repository may provide access to an API. A sensitive service published on the Internet may allow a direct compromise attempt.

In practice, an attack vector often involves more than one step.

And that is where simply knowing that an asset exists starts to become insufficient. We want to understand what can be done from that point.

We will return to this in more depth in another Insight, because attack vectors deserve a discussion of their own.

Does a larger attack surface necessarily mean more risk?

No.

A global organization with thousands of assets may have a much larger attack surface than a small company and still manage its exposures far more effectively.

Likewise, an organization with only a few assets may have one critical service sitting in an inappropriate exposure condition.

Counting assets helps us understand the size of the environment. By itself, it does not determine risk.

When we analyze an attack surface, other questions often matter more than the absolute number: which assets are reachable, which services are published, which technologies are in use, what exposures exist, and whether any of them create conditions that may be useful to an attacker.

Sometimes one asset deserves more attention than hundreds of others.

This distinction matters because there is a natural tendency to turn visibility into volume: more domains found, more IP addresses, more ports, more findings.

But finding more things does not necessarily mean understanding risk better.

Where does Attack Surface Management fit?

This is the context in which Attack Surface Management (ASM) becomes useful.

The idea is not simply to run asset discovery once and consider the job done. The goal is to maintain visibility over a surface that keeps changing, identify exposures, and follow what happens to them over time.

That brings ASM closer to the way an attacker might view the environment: looking from the outside in, searching for what is reachable, and trying to understand what opportunities those exposures may provide.

There is an important difference here.

An internal inventory usually answers:

“What do we know we have?”

Attack surface analysis also tries to answer:

“What can someone outside the organization find?”

When those answers are different, there is usually something worth investigating.

Sometimes it will simply be an asset that needs to be added to the inventory. In other cases, it may be a sensitive service, an old application, a leaked credential, an exposed repository, or a configuration that deserves closer analysis.

Not every discovery will represent a relevant risk.

And perhaps that is precisely the point.

The purpose of understanding the attack surface should not be to produce the largest possible number of findings. It should be to separate what simply exists from what actually deserves attention.

Because discovery is only the beginning.