External Attack Surface Management, explained: continuous monitoring vs. the annual pentest
“External attack surface management” (ASM) has become one of those phrases that means something slightly different to everyone who says it. Let’s pin it down, and then talk about why the annual pentest — valuable as it is — can’t do this job on its own.
What the external attack surface actually is
Your external attack surface is everything an attacker can reach from the public internet without credentials: apex domains and every subdomain, the hosts behind them, open ports and the services on them, web applications and APIs, TLS certificates, cloud buckets and endpoints, and the technologies you’re running — known and, more dangerously, forgotten.
The forgotten part is the point. The surface you documented is not the surface you have. A marketing team spins up a campaign subdomain. A developer exposes a staging box “just for a day.” An acquisition brings infrastructure nobody mapped. A cloud service rotates to a new IP. None of it shows up in a spreadsheet, and all of it is reachable.
Why a point-in-time pentest isn’t enough
An annual (or even quarterly) pentest is a deep, skilled look at a snapshot. It’s genuinely valuable — but the snapshot starts going stale the moment it’s taken. Between engagements:
- New assets appear that were never in scope.
- A config change re-opens something a previous test flagged as fixed.
- A new CVE drops for software that was “clean” last month.
- A certificate silently expires, or a DNS record goes dangling.
The gap between “we tested in March” and “it’s now September” is exactly where breaches live. ASM doesn’t replace the pentest — it covers the eleven months the pentest can’t.
The pieces of a real ASM program
Doing ASM well means stringing together several capabilities, in order:
- Discovery — continuously enumerate assets (passive subdomain discovery, DNS resolution, certificate transparency) so the inventory finds you, not the other way around.
- Probing — resolve what’s live, fingerprint services and technologies, check TLS, and map the real surface.
- Assessment — run templated checks for known CVEs, misconfigurations, exposures, and takeovers against that surface.
- Correlation — de-duplicate findings across tools and tie them to persistent assets, so one issue is one finding with a history — not four rows.
- Change detection — diff each run against the last: what’s new, regressed, remediated, and newly discovered.
- Reporting — turn all of it into something a human will actually read and act on, at the altitude they need.
Any one of these is a weekend project. Doing all six, continuously, with a defensible record of what you scanned and why — that’s the hard part, and it’s the part that earns its keep.
Continuous beats point-in-time, but only if it’s readable
The trap in going continuous is drowning yourself in output. Scanning every day and emailing a 240-row report is how teams end up ignoring their own tooling. The value of continuous monitoring isn’t today’s full list — it’s the delta: what changed since last time, ranked by what actually matters. (We wrote about that in “What changed since last run”.)
That’s the shape of good ASM: find everything, correlate it, watch it change, and surface only the signal — continuously, and without needing a specialist to operate it.
That’s what ProbeIQ is built to do. If your perimeter is drifting between pentests, take it for a spin.
Want this running against your own perimeter?Request early access →