External attack surface management — the 90-day onboarding playbook

External attack surface management (EASM) is the continuous discovery and monitoring of the assets an attacker can reach from the public internet — domains, subdomains, exposed management interfaces, APIs, cloud storage, forgotten marketing microsites, and the properties a recently acquired subsidiary brought with it. It is the outside-in view: what an unauthenticated attacker sees before they have any foothold.

Boards fund EASM reactively. The trigger is almost always a peer breached through an internet-facing appliance — the two NetScaler ADC/Gateway RCE zero-days CVE-2026-88771 and CVE-2026-88772, added to CISA's Known Exploited Vulnerabilities catalog on 27 September 2026, are a textbook example: unauthenticated remote code execution affecting default configurations, exploited before a patch existed. Every organization running one asked the same question — 'do we even have one exposed, and where'.

In scope: everything reachable from the internet that carries your organization's identity or data. Out of scope: internal vulnerability management (that is a separate authenticated-scanning program) and the full internal exposure loop (that is CTEM, which EASM feeds but does not replace). Keep the scope boundary explicit — an EASM program that quietly expands into internal scanning stalls and delivers neither.

An EASM program fails in three predictable places, and the 90-day plan below is organized around getting each one right:

• Discovery — the map misses assets nobody remembers owning. Shadow IT, ephemeral cloud workloads, expired-but-still-resolving subdomains, and third-party-hosted properties are exactly where the breach comes from, and exactly what a classical CMDB does not list.
• Ownership attribution — discovery produces a list, but no accountable owner, so nothing gets fixed. A finding with no name attached ages into a quarterly report and never closes.
• Triage to remediation SLA — exposures are ranked by raw CVSS instead of real exploitability, so the team burns its remediation budget on high-CVSS findings that are unreachable while a genuinely exploitable exposure sits open.

Get these three wrong and you have bought a dashboard. Get them right and you have a program the board and your regulator can read.

Goal: a complete seed set and a first exposure ledger by day 30.

Discovery is only as good as its seeds. Start from what you can assert you own, then let discovery expand outward:

• Assemble the seed set: registered domains and brands, owned IP ranges and ASNs, cloud-provider account and organization IDs, known SaaS tenants, and — critically — the domains and IP space of every subsidiary acquired in the last five years. The UK NCSC's EASM buyer's guide is a good neutral reference for what a discovery capability should cover.
• Run continuous discovery, not a one-off scan: enumerate subdomains, resolve DNS, fingerprint services and technologies, and pull certificate-transparency logs to catch hosts that never appeared in your own DNS. Configure it to re-run on a fixed cadence — daily for DNS and certificate changes, weekly for full re-enumeration.
• Produce the first exposure ledger: every internet-facing asset, its open services, its detected technologies and versions, and whether it exposes an unauthenticated management or login interface. Expect to be surprised — first-baseline runs routinely surface 20-40% more internet-facing assets than the asset inventory listed.

Checklist for Phase A:

• Seed set signed off by IT, cloud, and each business unit.
• Discovery running on a scheduled cadence, not manually triggered.
• First exposure ledger produced, with discovery provenance recorded for each asset (which seed and which technique found it).
• Any asset exposing an unauthenticated admin interface flagged for immediate review, ahead of the full triage phase.

Goal: every asset in the ledger has a named, accountable owner by day 60.

This is the phase most programs skip, and it is the one that decides whether the program produces action or noise.

• Attribute an owner to every asset: map each asset to a business unit and a named accountable individual. Automate what you can — WHOIS, cloud-account tags, TLS certificate organization fields, internal CMDB joins — but budget for manual attribution of the long tail.
• Resolve the orphans deliberately: some assets resolve to your brand but map to no known owner — a contractor's microsite, a shadow cloud account, a subsidiary's forgotten property. Each orphan is a decision, not a mystery to be left open: claim it (assign an owner) or decommission it (take it offline). 'Nobody owns it' is not an acceptable end state — orphaned internet-facing assets are the single most common breach entry point.
• Tier the assets by blast radius: an internet-reachable, unauthenticated interface fronting sensitive data or a management plane is tier 1; a static marketing page is tier 3. The tier drives the remediation SLA in Phase C.

Checklist for Phase B:

• 100% of ledger assets attributed to a business unit and a named owner, or explicitly queued for decommission.
• Orphan register produced, each entry with a claim-or-kill decision and a date.
• Asset tiers assigned, reviewed with the business, and recorded in the ledger.
• Decommission actions for unclaimed assets tracked to closure.

Goal: an exploitability-based triage model and enforced remediation SLAs by day 90.

The prioritization mistake that wastes the most remediation budget is ranking by raw CVSS. Rank by exploitability in your environment instead:

• Internet reachability — is the vulnerable service actually reachable unauthenticated from the public internet? EASM already told you.
• Known exploitation — is the CVE on CISA's KEV catalog? A KEV-listed unauthenticated RCE on an internet-facing asset outranks a CVSS 9.8 sitting behind MFA and segmentation.
• Exploitation probability — use FIRST's EPSS score to separate the CVEs likely to be exploited in the next 30 days from the long tail that never will be.

Set remediation SLAs by tier and enforce them:

• Tier 1 (internet-reachable, unauthenticated, sensitive): KEV-listed → emergency window, mitigate or isolate within 24-48h even before a patch (see the KEV-driven emergency patch window playbook); non-KEV critical → 7 days.
• Tier 2: 30 days.
• Tier 3: 90 days or documented risk acceptance.

Gate closure on retest. A ticket marked 'fixed' is a hypothesis until the exposure is re-checked from the outside and confirmed gone. 'Found' is not 'fixed'. Anything left open past its SLA requires a documented, owner-signed risk acceptance — not silence.

Checklist for Phase C:

• Exploitability triage model (reachability + KEV + EPSS) applied to the full ledger.
• SLAs defined per tier and wired into the ticketing system with due dates.
• Retest gating enabled — no exposure closes without an external re-check.
• First board readout delivered: exposure count by tier, mean time to remediate, and the accepted-risk register.

Keep these artifacts standing, signed and timestamped — they are what an auditor, an insurer, or a regulator asks for, and what you need when a discovered asset turns out to be already compromised:

• Asset inventory with discovery provenance — every internet-facing asset, and how it was found (which seed, which technique, which date).
• Ownership register — asset to business unit to named owner, with the orphan claim-or-kill decisions.
• Exposure ledger — per-asset services, versions, CVEs, KEV flag, EPSS score, tier, and current status.
• Remediation and retest log — action taken, date, approver, and the external re-check result that closed each item.
• Risk-acceptance register — every exposure left open past SLA, with the owner signature and the business justification.

The recurring gap this list exposes is that a scanner produces a list of findings, not evidence of what is exploitable. The step that converts one into the other is validation: proving, from the outside, that a discovered exposure can actually be reached and exploited, mapped to MITRE ATT&CK technique for the regulator filing. Zero Hunt's autonomous AI red team re-runs that validation continuously and on every change to the surface — each newly discovered internet-facing asset is adversarially tested, and each confirmed exposure closes with a signed proof-of-exploit artifact, so the ledger records what an attacker can actually do rather than what a version banner implies.

1. The point-in-time scan. A surface mapped once drifts stale within weeks — a new subdomain, a reopened port, a fresh cloud bucket. If discovery is not continuous, the map is describing a network that no longer exists. This is the failure the NetScaler zero-days punished: the exposed appliance was often one nobody had re-checked since it was stood up.

2. Discovery without ownership. The most common way to waste an EASM investment is to produce a beautiful asset list that no owner is accountable for. Findings without names attached never close.

3. CVSS-only prioritization. Ranking purely by CVSS burns the remediation budget on unreachable high-severity findings while a KEV-listed, internet-reachable exposure stays open. Reachability and known exploitation beat raw severity every time. NIST's SP 800-115 technical testing methodology is the neutral reference for building the validation step that produces this ranking.

4. Forgetting to refresh the seeds. Seeds are not set-and-forget. Miss an acquisition and the platform silently drops an entire subsidiary's internet presence from the map. Refresh the seed set after every M&A event and every major product launch.

5. Treating EASM as a complete inventory — or 'found' as 'fixed'. EASM is the outside-in external view; it is not your full asset inventory and it does not confirm remediation. Pair it with an authenticated internal program, feed it into your CTEM loop, and gate every closure on an external retest.

EASM is the discovery and monitoring layer. Three adjacent programs consume its output, and drawing the boundaries prevents both duplicated effort and dropped handoffs:

• CTEM — the continuous threat exposure management loop takes the external ledger as one input alongside internal exposures and drives the scope-discover-prioritize-validate-mobilize cycle. EASM is the external-discovery front end; CTEM is the whole loop.
• Emergency patching — when a discovered internet-facing asset lands on KEV, the response switches to the time-boxed KEV-driven emergency patch window, decided by exposure and known exploitation rather than a fixed calendar.
• Edge-device incident response — if discovery reveals an internet-facing appliance that is already compromised, you are no longer in exposure management but in incident response; hand off to the edge-device compromise playbook and preserve volatile evidence before you touch the box.

For the regulatory framing — why continuous, evidence-producing testing is increasingly what NIS2 and DORA expect — see NIS2 + DORA and continuous pentest.