Your external attack surface: what an outside view can and cannot tell you

What an external attack surface is

Your external attack surface is everything an attacker could reach, or learn about, from the internet without first getting inside. It includes domains and subdomains, IP addresses and the services listening on them, web applications and APIs, login portals, cloud storage and services with public endpoints, email infrastructure, certificates and the software versions those systems reveal about themselves.

It also includes systems run for you by others: a marketing site on a hosting platform, a support desk on a software-as-a-service provider, a campaign microsite built by an agency. If it carries your name or answers on your domains, it is part of how the outside world sees you.

The definition matters because it is broader than most asset inventories. An inventory tends to list what the organization bought and approved. The attack surface is what actually exists and responds when someone connects to it.

Why assets go missing from inventories

Few organizations lose track of systems through carelessness. More often, the inventory simply lags behind how quickly new things are created. The usual causes are familiar:

• Shadow IT. Teams set up services to get work done, often with good intentions, without telling a central team.
• Mergers and acquisitions. An acquired company brings its own domains, cloud accounts and legacy systems, and folding them into central records can take years.
• Cloud growth. New accounts, projects and regions appear as teams scale, and each can publish a service to the internet within minutes.
• Third-party hosting. Agencies, vendors and partners run systems under your brand or on your domains, and those systems rarely appear in your own configuration records.
• Forgotten test and staging systems. Temporary environments outlive the projects that needed them, often with weaker controls and sometimes with real data.
• DNS and certificates. Old DNS records can keep pointing at resources that no longer exist, which creates the risk of a subdomain takeover. Certificates issued for unfamiliar hostnames are often the first hint of a service nobody maintains.

Attribution: is it really yours?

Discovering an asset is only half of the work. You also need to establish that it belongs to you, and that is harder than it sounds. Shared hosting means many organizations sit on the same IP addresses. Similar brand names produce similar domains. Content delivery networks and software platforms front services for thousands of customers at once.

Getting attribution wrong has costs in both directions. Missing an asset leaves exposure unmanaged. Wrongly claiming one is worse than noise: assessing or testing a system you do not own can be unlawful and can disrupt someone else's service. Sound attribution combines several independent signals, such as DNS ownership, certificate details, registration records, cloud account data and confirmation from the business, and it flags anything ambiguous for human review before anyone touches it.

Exposure is not the same as vulnerability

An internet-facing service is an exposure: a place where something could go wrong. It is not automatically a vulnerability. A web server answering on the internet may be fully patched and correctly configured. An administrative login page may sit behind strong authentication. Treating every exposed service as a vulnerability buries the real issues in noise.

The useful questions are about reachability and consequence:

• Should this service be reachable from the internet at all?
• Does it reveal more than it needs to, such as software versions, internal hostnames or error details?
• Is it protected the way its role requires, for example with strong authentication on anything administrative?
• Is there a known weakness in what it runs, and is that weakness being exploited elsewhere?

The answers turn a long list of exposures into a short list of things worth acting on.

What an outside view cannot see

External discovery works from the attacker's vantage point, which is exactly why it is valuable. It also has limits that are worth stating plainly.

• It cannot see internal systems, internal network paths or what an attacker could reach after an initial compromise.
• It sees configuration only as far as it is externally observable. A cloud permission that is far too broad may not show up at all from outside.
• It often cannot tell whether a service is genuinely vulnerable without authenticated or deeper testing.
• Its coverage depends on the starting information and on what the internet reveals. Some assets leave very few public traces.

For those reasons, an outside-in view works best alongside internal inventories, cloud configuration reviews and authorized testing. It complements them; it does not replace them.

Building a reliable inventory, and noticing change

A reliable external inventory has a few simple properties. Every asset has an owner, or a clear note that ownership is unknown and being resolved. Every asset records how it was found and why it is believed to belong to you. And the inventory is compared over time, because what changed since last week is often more important than the full list.

Change is where much of the risk appears: a new subdomain for a product launch, a storage service made public for a quick test, a certificate issued for a host nobody recognizes. Public Certificate Transparency (opens in a new tab) logs are a useful source here, because publicly trusted website certificates are recorded in them and new hostnames frequently appear there. The UK National Cyber Security Centre's guidance on asset management (opens in a new tab) describes the wider practice of keeping inventories accurate and validated.

Practical first steps

1. Write down your seeds: primary domains, brand names, known address ranges, cloud accounts and key third-party services.
2. Enumerate subdomains from your own DNS zones and from certificate records.
3. Identify what answers: which hosts respond, on which services, and what they reveal.
4. Attribute carefully, and ask the business about anything you cannot explain.
5. Decide, asset by asset, whether each one should be public at all. Removing unnecessary exposure is often the cheapest fix available.
6. Review the remaining exposures for known weaknesses and misconfiguration, and prioritize by reachability and consequence.
7. Repeat on a schedule, and pay the most attention to what changed.

In the United States, eligible public sector and critical infrastructure organizations can also request CISA's Cyber Hygiene services (opens in a new tab), which include scanning of internet-facing systems.

Where Threatless fits

Threatless Surface is external attack surface management software, designed to help security teams discover internet-facing assets, add ownership and technology context and highlight what has changed. If you would rather start with a bounded engagement and a reviewed report, the Vulnerability & Attack Surface Assessment service begins from the same questions.

Exposure found from the outside is most useful when it feeds a wider decision process. That is the role of Threatless CTEM, and our guide to continuous threat exposure management explains the cycle it is designed around.

This guide explains established security practice. It is general information, not advice for your specific situation. For that, talk to us.