Pillar guide · 14 min read

What is Attack Surface Management? A 2026 guide for CISOs and CTOs

Published May 17, 2026 · A practical, no-marketing primer. Cites OWASP, Gartner CARTA, ISO 27001 by name. No invented statistics.

If you run a security programme in 2026 you have almost certainly heard the term "attack surface" — usually attached to the words "ever-expanding" in a vendor pitch. The underlying observation is real, even if the framing is tired: the average organisation has more digital assets exposed to the public internet than it can keep track of, and the gap between what your CMDB says you have and what an attacker can actually see keeps widening.

Attack Surface Management (ASM) is the discipline of closing that gap. This article is what we wish we could have read when we started working on this problem — a plain-English definition, a brief history of how the category emerged, the five functional pillars every ASM product covers in some shape, where ASM sits relative to vulnerability management and DAST, a tour of the tools landscape, and a 10-step implementation checklist you can run whether or not you buy anything.

Definition: the simplest one we can give

Attack Surface Management is the continuous practice of discovering, inventorying, and monitoring every digital asset an attacker can see and reach about your organisation. The output is a living inventory and a stream of change-events, not a one-off report.

"Digital asset" here is broader than most internal asset registers cover: it includes your owned domains and subdomains, public IP addresses, exposed services (open ports, HTTP endpoints, SSH banners), TLS certificates, email-authentication records (SPF / DKIM / DMARC), public DNS posture, third-party SaaS tenancies linked to your domain, credentials leaked in public repositories or paste sites, and OSINT-discoverable infrastructure of subsidiaries and acquired companies.

The defining property is continuous. A pentest produces a snapshot; ASM produces a timeline. The value lives in the deltas — a new subdomain that appeared yesterday, a certificate that quietly expired, an open port that was closed last week.

Short history: how the category emerged

The intellectual lineage starts with Gartner's CARTA (Continuous Adaptive Risk and Trust Assessment) framework, introduced around 2017. CARTA argued that point-in-time risk models — an annual audit, a quarterly pentest — were incompatible with cloud-native infrastructure that changed by the minute. Security had to become continuous, adaptive, and context-aware.

ASM as a vendor category crystallised between 2019 and 2021. Companies like Randori, Expanse (acquired by Palo Alto Networks), RiskIQ (acquired by Microsoft) and CyCognito built external discovery engines that crawled the public internet to find assets organisations did not know they owned. Gartner formalised "External Attack Surface Management" (EASM) as a Hype Cycle entry in 2021.

Today the category sits in an awkward middle ground. The biggest enterprise vendors (Palo Alto Cortex Xpanse, Microsoft Defender EASM, Tenable ASM) have absorbed it as a module of larger platforms. A second tier of independent tools (Detectify, Intruder, CyberScore among others) target the mid-market and SMB segment with lighter pricing and faster onboarding. Open-source asset discovery (Amass, Subfinder, httpx) covers the technical-team end of the spectrum.

The five pillars of ASM

Every credible ASM product covers some shape of these five capabilities. Vendor terminology varies — what one tool calls "exposure management" another calls "risk scoring" — but the functional split is stable.

Pillar 1: Asset discovery

Finding everything that exists. Starts from seed inputs (a primary domain, a company name, a public IP range) and expands outward — subdomain enumeration, certificate transparency log mining, ASN walking, reverse DNS, third-party SaaS account discovery (Atlassian, GitHub, AWS tenants linked to your email domain), and acquisition mapping. The output is a list with confidence levels: "definitely yours", "probably yours", "possibly yours".

Pillar 2: Vulnerability identification

For each discovered asset, what is wrong with it. Passive ASM tools detect issues visible from outside — outdated TLS, missing security headers, dangling DNS records, exposed admin panels, weak email authentication, software versions in banners. Active VM tools dig further with authenticated probes. ASM stops at heuristic detection; it does not exploit.

Pillar 3: Risk prioritisation

Triage. Not every finding deserves attention this week. Prioritisation combines technical severity (CVSS or an internal score), asset criticality (a TLS issue on your marketing blog is different from one on your auth service), exploit availability (is this CVE in active exploitation? CISA KEV is the reference), and exposure context (internal vs internet-facing). The output is a rank-ordered list, not a heatmap.

Pillar 4: Remediation tracking

Closing the loop. Who fixed what when, with evidence. This is the audit-facing pillar — ISO 27001 Annex A 8.8 and SOC 2 CC7 both expect a documented vulnerability handling process with operator-attributed decisions. The minimum viable output is a CSV with finding ID, decision (fixed / won't fix / accepted risk / snoozed), operator email, and timestamp.

Pillar 5: Threat intelligence

External context. What are attackers actually doing this week? Sources include CISA KEV (Known Exploited Vulnerabilities), public CVE feeds, exploit-DB, paste sites and credential-leak monitors, dark-web feeds where available. The maturity gap between vendors is largest here — enterprise tools lean heavily into TI feeds, SMB tools usually settle for CISA KEV + a credential leak check.

ASM vs Vulnerability Management vs DAST

The three categories overlap, often confusingly. A working distinction:

  • ASM asks "what do I have, and what is visible about it?" Passive, external, credential-free.
  • Vulnerability Management (Qualys VMDR, Tenable VM, Rapid7 InsightVM) asks "for this host I already know about, which CVEs apply?" Usually agent-based or credentialed.
  • DAST (Burp Suite, OWASP ZAP, Acunetix, AppCheck) asks "for this web application, which vulnerabilities can I trigger?" Active, often authenticated, payload-driven.

A mature programme runs all three at the appropriate cadence — ASM continuously, VM weekly or daily, DAST per major release or quarterly. A pragmatic SMB programme starts with ASM (cheapest, broadest coverage, fastest to deploy) and adds the other two when scale and budget justify it.

Tools landscape (briefly)

Enterprise: Palo Alto Cortex Xpanse, Microsoft Defender EASM, Tenable Attack Surface Management, CyCognito. Deep discovery, mature TI feeds, six-figure annual contracts.

Mid-market and SMB-focused: Detectify, Intruder, UpGuard, CyberScore. Faster onboarding, published pricing in the hundreds-to-low-thousands per month, narrower feature surfaces. Coverage is generally good enough for most non-enterprise contexts.

Open source / DIY: Amass, Subfinder, httpx (ProjectDiscovery), Nuclei, theHarvester, OWASP Amass. Engineer-rich teams can build a credible internal ASM pipeline from these. The cost is operator time, not licence fees.

For our part, CyberScore sits in the mid-market / SMB bucket. We are passive only, cover fourteen scanner modules across five pillars (Attack Surface, Vulnerabilities, Email Security, OSINT & Secrets, Auth & Cloud IAM, plus a Compliance supporting pillar), host in France, and publish pricing in the hundreds per month. We do not pretend to compete with Cortex Xpanse on enterprise depth.

Implementation checklist

Whether you buy a tool or build one, the rollout sequence is the same. Run through it in order. For a more granular, scanner-by-scanner breakdown, see our 25-item external attack surface checklist.

  1. Define your perimeter. List primary domains, brand names, public IP ranges, subsidiaries, acquired companies. ASM tools seed from this — wrong seed, wrong inventory.
  2. Run a baseline discovery. Accept that the first scan will surprise you. Forgotten subdomains, dead S3 buckets, a staging server somebody put on a public IP three years ago.
  3. Triage the baseline. For each asset, decide: ours and supported, ours and deprecated, not ours. Decommission deprecated. Flag "not ours" for follow-up.
  4. Establish ownership. Every asset needs an owner (a team, not a person). Without ownership, findings sit unactioned.
  5. Set scan cadence. Weekly is the default for SMB and mid-market. Daily for high-risk segments (fintech, healthcare).
  6. Define alert thresholds. Score drops of more than 10 points, new critical-severity findings, new exposed subdomain. Tune to your noise tolerance.
  7. Wire alerts to a real channel. Slack, Teams, email — somewhere a human reads. Not a SIEM that nobody opens.
  8. Define a SLA per severity. Critical findings: fix or accept within 7 days with documented justification. High: 30 days. Medium: 90 days.
  9. Export evidence quarterly. The CSV / PDF that proves the loop is closed. ISO and SOC 2 auditors ask for this in the external-monitoring control review.
  10. Review and prune. Every quarter, walk the inventory and decommission assets that no longer serve a purpose. Most attack surface growth is forgotten assets, not new ones.

Common pitfalls

Treating ASM as a project, not a programme. A baseline scan with no follow-up is worse than no scan — it manufactures false confidence. ASM only earns its keep if the findings flow into a remediation loop.

Conflating ASM with VM. Buying an enterprise VM platform and assuming it covers external asset discovery. Most VM products do, technically — but the discovery engine is rarely first-tier and the per-asset pricing punishes broad scope.

Over-buying. A 25-person startup does not need Palo Alto Cortex Xpanse. Pick the tool whose published price you can expense on a corporate card; revisit when the company is five times larger.

Under-triaging. Importing every finding into Jira without prioritisation. The backlog grows, nothing gets fixed, the tool gets blamed.

Frequently asked questions

What is Attack Surface Management in simple terms?+

Attack Surface Management (ASM) is the continuous practice of discovering, inventorying and monitoring everything an attacker can see and reach about your organisation from the outside — domains, IP addresses, exposed services, certificates, leaked credentials, third-party SaaS accounts. The goal is to know what you actually have before an attacker does, and to spot when something changes.

How is ASM different from vulnerability management?+

Vulnerability Management (VM) typically operates inside your network with authenticated agents — it tells you which CVE affects which host. ASM operates outside, without credentials — it tells you which hosts and services exist in the first place, and which of them are exposed. VM answers "is this server patched?". ASM answers "did we know this server existed?". Most mature programmes run both.

What are the five pillars of Attack Surface Management?+

Asset discovery (find everything that exists), vulnerability identification (what is wrong with it), risk prioritisation (what matters first), remediation tracking (who fixed what when), and threat intelligence (what attackers are doing in the wild). Vendor names vary but the functional split is consistent across the category.

Do I need a separate ASM tool if I already do pentests?+

Yes — pentests are a point-in-time check, usually once a year. ASM is the continuous layer between two pentests. The most expensive surprises (a forgotten subdomain pointing at a dead S3 bucket, an expired certificate, a leaked API key) tend to appear in the 51 weeks the pentester is not looking. ASM is designed to catch them.

Is ASM the same as EASM?+

EASM (External Attack Surface Management) is the external-only subset of ASM — DNS, certificates, public IPs, exposed services, OSINT. Full ASM also includes internal asset discovery (often via agents or CMDB integration). Gartner uses both terms; in practice most SMB-targeted tools are EASM products that just say ASM.

How often should ASM scans run?+

For most organisations, weekly is the right cadence — fast enough to catch drift between deploys, slow enough not to drown in noise. Continuous (every few hours) is justified once you are a target — fintech, healthcare, public-sector. Monthly is too slow; in a month an ASM tool will report a finding that has already been live long enough for an attacker to find it too.

Try ASM on your own domain

Run a free CyberScore sample scan. You get a baseline external attack-surface report in about two minutes — no signup. It is the cheapest way to see whether your ASM problem is large enough to budget for.

Got a correction or want to suggest a tool we should add to the landscape section? Email patrick@cybersco.re.