External Attack Surface: Inventory and Reduce It

Reviewed October 2026.

What the external attack surface is

An attack surface is every point where someone could get into a system or get data out of it. The external attack surface is the part reachable from the internet: the domains, hosts, services and third-party platforms that carry your name or hold your data.

The NCSC's reasoning is direct. Attackers constantly scan the internet for weaknesses, so you need at least the same view of your own systems as they have. Anything you expose is already being probed by internet-wide scanners, researchers and criminals, whether or not you look at it yourself.

The surface changes all the time. A marketing team launches a campaign site on a new platform, a developer starts a test server, a supplier moves its hosting. Adding is quick and easy; removing needs someone to remember.

What it includes

Area	What to list	What goes wrong
Domains	Every registered domain, including old brands, campaign domains and defensive registrations, and the registrar account behind each	A lapsed renewal, or a registrar account tied to one person's email, can hand control of web and email to someone else
Subdomains and DNS	Every name in each DNS zone and where it points: address, CNAME, MX, TXT and NS records	A CNAME pointing at a deleted cloud resource can be claimed by someone else
Web servers and applications	Websites, admin panels, APIs, login portals, staging and test sites	Missing updates, disclosed software versions, weak TLS, missing security headers
Email	Mail servers, and the SPF, DKIM and DMARC records for every domain, including domains that send no mail	Others can send mail that appears to come from your domain
Network services	Remote access (SSH, RDP, VPN gateways), databases, file sharing, container and management APIs	A service meant for internal use answers anyone on the internet
Certificates	The certificates issued for your names, who issued them and when they expire	An expired certificate breaks a service; an unexpected one can mean someone else controls a name
Third-party platforms	SaaS tools, CDNs, hosted forms, cloud storage and code repositories that serve your names or hold your data	Accounts nobody manages any more, and data in services nobody assessed

People and public information, such as staff names and email addresses, are part of the wider picture too. This guide sticks to the technical surface.

How to build an inventory

Work from what you know outwards. Each step finds things the one before it missed.

Collect your domains from registrar accounts, renewal invoices and old brand names. The NCSC recommends one group in the organisation acting as the internal registrar, so domains are not registered ad hoc with different providers.
Export each DNS zone. Every name that resolves is a candidate asset; for each one, find out what it is for and who owns it.
Search certificate transparency logs for names you did not know about (see below).
Look at what each name serves: the addresses it resolves to, the web server and software it discloses, and which service ports answer.
Ask the rest of the organisation. Marketing, sales, finance and development teams often run services on platforms IT never set up. The NCSC advises a no-blame approach to this shadow IT, so that people tell you about it.
Record the result. For each asset: its name and address, its purpose, its owner, the supplier, the data it handles and when it was last reviewed.

Certificate transparency

Publicly trusted TLS certificates are recorded in certificate transparency logs: public, append-only logs that anyone can search. Most certificates in use carry proof that they were logged, and the major browsers require it. Searching the logs for your domain lists the names certificates were issued for, which often turns up forgotten hosts: an old staging site, a supplier's portal, a test system set up years ago.

The logs have limits:

A wildcard certificate is logged as *.example.com, so the individual names it serves are not listed.
Names that never had a publicly trusted certificate, or that use one from a private certificate authority, do not appear.
The logs keep history, so a name may be listed long after its host was retired.
Anyone can search them. The names are as visible to an attacker as they are to you.

A name in a log is a lead, not proof of ownership. It may belong to a supplier or to someone else entirely, so confirm who runs it before you test it.

Subdomain finder Find a domain's subdomains in public certificate transparency logs.
DNS checker Look up a domain's A, AAAA, CNAME, MX, TXT, NS, SOA, CAA and DS records through public resolvers.
Technology detector See the web server, CDN and frameworks a site's home page discloses.
Exposed services checker Check your domain for databases, remote desktop and other services open to the internet, once it is verified.

What commonly turns up

A first inventory usually finds some of these:

Staging, test and old campaign sites still online, often on older software than the main site.
Subdomains pointing at cloud resources that have been deleted. See dangling DNS.
Remote desktop, SSH or database ports answering from the internet. See exposed remote access and exposed database ports.
Servers advertising software versions that no longer receive security updates. See end-of-life software.
Domains that send no email but publish no SPF or DMARC record, which makes them easy to spoof.
Certificates close to expiry with nobody clearly responsible for renewing them.
Registrar or DNS accounts registered to a former employee or a web agency rather than to the organisation.

How to reduce it

The smallest attack surface holds only what you need, configured well and owned by someone.

Remove what you do not need

Decommission sites and services that no longer serve a purpose, and delete their DNS records at the same time.
Remove CNAMEs and delegations when the service behind them ends. The NCSC notes that once the name a CNAME points at expires, someone else can take it and direct your traffic to their own systems.
Close accounts on platforms you have stopped using, and delete the data in them.

Keep internal services internal

Keep databases, file shares, and container and management APIs on private networks, not reachable from the internet.
Put remote administration behind a VPN or access gateway that requires multi-factor authentication, rather than exposing SSH or RDP directly.
Disable services and ports a server does not need.

Harden what remains

Install security updates on internet-facing systems as soon as you can. The NCSC calls this essential for anything that can be exploited from the internet.
Serve HTTPS only, with current TLS versions and the HTTP security headers that suit the site. See TLS and certificates and HTTP security headers.
Stop servers advertising their software versions.

Protect your domains

Turn on two-step verification for registrar and DNS accounts, and make sure more than one trusted person can manage them.
Set domains to renew automatically, paid from an organisation account rather than a personal card.
Use the registrar's lock on important domains, if it offers one.
Publish CAA records to limit which certificate authorities may issue certificates for your names. See CAA records.
Give domains that send no email SPF and DMARC records that reject everything. See email authentication.
Publish a security.txt file (RFC 9116) so that people who find a problem know where to report it.

Keep the inventory current

An inventory starts going out of date the day it is finished, unless something keeps it current.

Monitor critical DNS records, such as NS, MX and the records behind important services, for unexpected changes. The NCSC recommends this alongside watching certificate transparency logs, because a certificate you did not request can be a sign that someone has control of your DNS.
Check the inventory at the moments the surface changes: launches, migrations, new suppliers and people leaving.
Run external checks again after each change and on a schedule, and keep the results so you can see what changed and when.
Review the whole inventory with the asset owners on a regular schedule.

The NCSC's buyer's guide to external attack surface management describes products that do this continuously. Whether you use one or a simpler routine, the aim is the same: to shorten the time between something becoming exposed and someone noticing.

What an outside check can and cannot show

An external check sees your surface the way an attacker first does. It cannot tell you whether what it sees is meant to be there.

Ironfang can check

DNS records for the domain, including dangling CNAMEs, CAA and DNSSEC.
SPF, DKIM at common selectors, DMARC and null MX.
TLS certificates, expiry, protocol versions and cipher suites.
HTTP security headers, cookies, security.txt and the software a site discloses.
For a verified domain, whether any of 21 common service ports accept a connection: databases, remote desktop, SSH, Telnet, FTP, SMB, the Docker API and alternate web ports.
Hostnames from certificate transparency logs, listed for review and never scanned.

The organisation must establish

The complete list of domains, accounts and suppliers.
Who owns each asset and who may change it.
Which exposed services are intended, and why.
Internal systems and devices that are not reachable from the internet.
Decisions to keep, change or retire each item, and when they were last reviewed.

Sources

Checked on the review date above. Standards and schemes change; the source is the authority.