Attack surface management (ASM) is the ongoing practice of finding every internet-facing thing an attacker could reach — domains, subdomains, services, certificates, exposed files, lookalike domains — and shrinking or fixing it before someone else finds it first. It is a routine, not a product: discover, assess, reduce, monitor, repeat.
What is an attack surface?
Your attack surface is the sum of every point where an outsider can interact with your systems: every hostname that resolves, every port that answers, every login form, API endpoint, file a web server will hand out, every email domain that can be spoofed, and every certificate or domain name that could be mistaken for yours. OWASP's definition adds the paths through those points — the code and data that a request can reach once it's in (OWASP Attack Surface Analysis Cheat Sheet). For a small business the useful mental model is simpler: if it's reachable from the internet and has your name on it, it's on the list. Each API endpoint on that list carries its own question — not just “is it reachable” but “who is allowed to read what through it”, which is the subject of API security testing.
The surface is bigger than most owners think because it accumulates silently: a staging subdomain left up after launch, an old WordPress install on a forgotten hostname, a database admin panel “temporarily” exposed for a contractor, an S3 bucket referenced in a page, a marketing microsite from two campaigns ago. None of these are on anyone's to-do list, which is exactly why they matter.
Attack vector vs attack surface — what's the difference?
The surface is everything that could be attacked; a vector is the specific route one attack takes. An exposed admin panel is part of your surface; guessing its password is a vector. Reducing the surface removes whole classes of vectors at once — which is why ASM starts with inventory and removal rather than with buying a vulnerability scanner.
What does attack surface management actually involve?
Four steps, repeated. The table is the whole discipline; everything else is tooling.
| Step | Question it answers | Typical output | Guide |
|---|---|---|---|
| 1. Discover | What do we actually have that's reachable? | A list of hostnames, services, certificates, email domains and third-party dependencies | Attack surface mapping |
| 2. Assess | Which of it is weak, and how weak? | Per-asset findings: missing headers, expired or weak TLS, spoofable email, exposed files, open admin panels | Website Security Score |
| 3. Reduce | What can we switch off, close or fix? | Decommissioned hosts, closed ports, hardened configs, DMARC enforced | Reduce attack surface checklist |
| 4. Monitor | What changed since last time — and what appeared that isn't ours? | Alerts on new subdomains, new certificates, lookalike domains, cloned sites, config drift | Attack surface monitoring |
Vendors slice this into “external attack surface management” (EASM — the view from the internet), “cyber asset ASM” (the view from inside your inventory) and “digital risk protection” (brand and lookalike monitoring). For an organisation without a security team the external view is the one that matters, because it is the one attackers have — see external attack surface management, explained.
External vs internal attack surface — which one matters for a small business?
Large enterprises worry about both: the internet-facing perimeter and the thousands of laptops, servers and SaaS accounts behind it. A ten-person company or an agency running fifty client websites has a different shape: almost everything that matters is external. The websites, the email domain, the DNS, the hosting control panel, the handful of SaaS logins. Internal ASM for that organisation is mostly “turn on MFA and keep laptops updated”; external ASM is where the unknowns live. Start there.
How do attackers map your surface?
The same way you should — with public data, before ever sending a packet to your servers. The reconnaissance phase of any intrusion is passive and cheap:
- Certificate Transparency logs list every TLS certificate ever issued for your domains, which is a near-complete subdomain inventory for free (crt.sh, certspotter). Staging, dev, vpn, mail, old — all there.
- DNS reveals mail providers (MX), SaaS verifications (TXT), CDNs and hosting (A/CNAME), and whether SPF/DMARC would let them spoof you.
- Search engines and archives surface old pages, exposed documents and forgotten microsites.
- Internet-wide scan databases (Shodan, Censys) already hold your open ports and banners; an attacker reads them rather than scanning you.
- Technology fingerprinting from headers and HTML tells them your CMS, framework and versions — and which public exploits to try.
- Lookalike domains they register themselves, for the phishing step that follows.
CISA's advisories on the SharePoint and PaperCut exploitation waves this year make the same point from the defender's side: the victims were rarely the ones with the worst patching, they were the ones with an admin interface that shouldn't have been internet-reachable at all (CISA, July 2026). Exposure, not the CVE, is the variable you control.
How common is that in practice? We passively checked the homepages of 376 web agencies in Bulgaria and Italy and found 81% with no Content-Security-Policy, 63% without HSTS and only 27% enforcing DMARC — the full study is here.
What belongs in a first ASM routine for a small team or agency?
A monthly hour and a few free tools cover most of the value. In order:
- Inventory hostnames from CT logs and DNS; mark each as keep, retire or unknown. Unknowns get an owner within the week.
- Retire what you don't need. Every host you delete is a host you never have to patch. Old staging sites and campaign microsites are the usual first wins.
- Score what remains — headers, TLS, cookies, exposed files, email posture — with a passive checker per host, and fix the fails.
- Enforce email authentication (SPF, DKIM, DMARC
p=reject) on every domain that sends mail, and a null MX +v=spf1 -allon the ones that don't. - Close admin interfaces to the internet (VPN, IP allow-list or at minimum MFA + rate limiting).
- Register the obvious typosquats of your main brand, and monitor the rest.
- Turn on monitoring for the things that change without telling you: new certificates for lookalike names, new subdomains, cloned copies of your site, expiring certificates, DMARC drift.
old., dev., shop. and mail. hosts the client set up before you arrived. The main site scores an A; the forgotten WordPress on a subdomain is where the breach happens. Inventory the domain, not the site.Which tools do you need?
Fewer than the market suggests. The honest split for a team without a SOC:
- Free, passive, no signup — our checkers for headers, CSP, cookies, TLS, email/DMARC, login rate limiting, and the combined A–F score; plus crt.sh and your DNS provider's zone export for inventory.
- Free monitoring for your own verified domain — the Domain Monitor (clones, lookalike certificates, typosquat registrations).
- Open-source, run it yourself —
subfinder/amassfor subdomains, nuclei for templated checks,testssl.shfor TLS depth. Powerful; needs someone comfortable with a terminal and a clear rule about only scanning what you own. - Commercial EASM platforms — continuous discovery across many organisations, integrations, SLAs. Worth it above a few hundred assets or when procurement needs a vendor name. Compared in the tools guide.
How often should you re-check?
Discovery and scoring: monthly, and after every launch, migration or agency hand-over. Email posture: quarterly, and whenever a new sending service is added. Monitoring: continuous by definition — the whole point is catching the certificate that was issued last night. Put the monthly hour in a calendar with a named owner; ASM fails when it's everyone's job.
For the site owner and for the developer
For the site owner (plain English)
You don't need a security team to do attack surface management; you need a list and a habit. The list is every website, subdomain and email domain your business has ever set up. The habit is a monthly hour: delete what you no longer use, run the free checkers on what remains, fix the fails, and let monitoring watch for anything new that carries your name. If you work with an agency, ask them for the list — if they can't produce it, that's your first finding.
Verify your domain and let the Domain Monitor watch for cloned sites, lookalike certificates and typosquat registrations — the signals that come before a phishing wave. Free during the beta.
Start monitoring your domain →For the developer / IT (a minimal ASM loop with free tooling)
# 1. Discover — subdomains from Certificate Transparency (no scanning involved)
curl -s "https://crt.sh/?q=%25.example.com&output=json" \
| jq -r '.[].name_value' | sed 's/\*\.//' | sort -u > hosts.txt
# 2. Which of them still resolve?
while read h; do dig +short "$h" | head -1 | grep -q . && echo "$h"; done < hosts.txt > live.txt
# 3. Assess each live host passively (headers, TLS, cookies, exposed files, email)
# → https://mysecscan.com/tools/website-security-score (or the individual checkers)
# 4. Email posture for every domain that appears in hosts.txt
dig +short TXT example.com | grep -i spf
dig +short TXT _dmarc.example.com
# 5. Reduce: everything in hosts.txt that's NOT in live.txt is a dangling DNS record → delete it
# (dangling CNAMEs to decommissioned SaaS are a subdomain-takeover risk)
# 6. Monitor: verify the domain at https://mysecscan.com/monitor and paste the snippetKeep hosts.txt in the repo with an owner column. The diff between two monthly runs is your change report — that, plus the monitor's alerts, is a complete small-business ASM program.