What external attack surface monitoring is (and what it is not)

External attack surface monitoring is the ongoing practice of finding and checking everything your company exposes to the internet: domains, subdomains, DNS records, TLS certificates, email settings, websites, open ports and the services behind them. It looks at your company from the outside, the same way an attacker does before choosing a target, and it repeats that look every day so that changes do not go unnoticed.

The short answer to "what is it" is this: an up to date inventory of your internet facing assets, plus continuous checks of those assets for known weaknesses and unexpected changes. It does not install anything on your laptops or servers, and it does not need passwords or network access.

The idea is not new. In the MITRE ATT&CK framework, reconnaissance is the first tactic, described as the adversary trying "to gather information they can use to plan future operations." Monitoring your own external surface means doing that reconnaissance first, on your own terms.

What counts as your external attack surface

Most companies underestimate how much they have online. A typical list includes:

• Domains you own, including old campaign domains and country variants, plus their registrar and expiry dates.
• DNS records: A, AAAA, CNAME, MX, TXT and nameserver (NS) records. A single wrong CNAME can hand a subdomain to someone else (see subdomain takeover).
• TLS certificates for every hostname, with their issuers and expiry.
• Email authentication: SPF, DKIM and DMARC records that decide whether someone can send mail that looks like yours.
• Websites and web apps, including staging, test and admin hosts that were meant to be temporary.
• Open ports and services: remote desktop, SSH, databases, mail servers, VPN gateways.
• Things outside your control that use your name: lookalike domains, fake login pages, leaked credentials.

How the surface grows without anyone noticing

Very little of this is created on purpose as "attack surface". It accumulates through normal work. A developer spins up staging.example.com for a release. Marketing registers example-offer.com for a campaign. An agency points shop.example.com at a hosted platform and the contract ends 2 years later. Each step is reasonable. The problem is that nobody owns the list.

Certificate Transparency makes this visible. Since publicly trusted certificates are logged (the protocol is described in RFC 9162), anyone can search the logs for names under your domain. More on that in Certificate Transparency logs explained.

How to check your own surface today

You can get a first picture in under an hour with standard tools.

1. List the hostnames that ever had a certificate. Search crt.sh for %.yourcompany.com and export the names.
2. Resolve each name and note where it points:

dig +short staging.yourcompany.com
dig +short CNAME shop.yourcompany.com
dig NS yourcompany.com +short

1. Check email authentication:

dig +short TXT yourcompany.com
dig +short TXT _dmarc.yourcompany.com

1. Open every hostname in a browser. Note anything you do not recognize, anything that shows a default server page, a login form you did not expect, or an expired certificate.
2. Check the registrar and expiry of every domain with whois yourcompany.com.

Whatever you find that has no clear owner is the first thing to fix or switch off.

What external attack surface monitoring is not

It helps to be precise, because the term gets stretched.

• It is not a penetration test. A penetration test actively tries to break in, needs written authorization and runs for a fixed period. Monitoring observes and reports; it does not attempt to exploit anything.
• It is not endpoint protection. EDR and XDR tools run inside your network and watch processes and logins. External monitoring sees what is visible before anything reaches your network. Both views complement each other, as explained in attack surface monitoring vs EDR and XDR.
• It is not a one time scan. A report from last spring describes last spring. The value comes from noticing change: a new subdomain, a changed nameserver, a certificate that nobody requested.
• It is not a list of scary numbers. A useful finding says what was found, why it matters and exactly how to fix it.

A short checklist

• Keep one list of every domain and who owns it, with renewal on auto-pay.
• Review DNS for records that point to services you no longer use.
• Make sure every public hostname has a valid certificate and an owner.
• Publish SPF, DKIM and DMARC, and move DMARC toward enforcement.
• Close remote desktop and database ports to the internet.
• Remove or protect staging and test hosts (see forgotten staging and test servers).
• Repeat the review on a schedule, not only after an incident.

Where Datahorses fits

Datahorses does this review every day. We watch your company from the outside, see what an attacker can see, and send each finding with exact fix steps for your developer, reviewed by a person. We do not enter your systems and need no access; the full list of what we watch is on the home page, and you can see a complete example dashboard.