How to actually reduce your attack surface

Attack surfaces grow by default. Every deploy adds a hostname, every vendor adds an integration, every acquisition adds an estate nobody fully catalogued, every experiment leaves a subdomain behind when the team moves on. Nothing subtracts by itself. Left alone, an organization's external surface only ever gets wider, which is why "we should reduce our attack surface" appears in every security strategy deck and so rarely turns into a changed number.

The good news: reduction is not a product you buy, it is a sequence you run. Five moves, in an order that matters, and most of them cost nothing but decisions. Here is the sequence as we see it from the external attack surface management side, watching it work and fail across real estates.

Count it before you cut it

You cannot reduce what you have not counted, and almost nobody's count is right. The gap between "the assets we track" and "the assets that resolve" is where incidents start, because the untracked host is also the unpatched, unmonitored, unowned one.

Counting properly means enumerating the way an attacker does, from the outside, starting with nothing but your name. Certificate transparency logs record every TLS certificate your teams ever minted, including the staging ones. Passive DNS aggregators remember hostnames that answered years ago and still do. Web archives surface applications that never got a certificate at all. Walk those sources for your domains, then do it again for the domains you forgot you own: the acquisition's old brand, the product microsite from two launches ago, the vendor-built campaign page. We wrote up the full outside-in walk in what an attacker sees when they look at your company.

The output of this step is not a scan report. It is an inventory with an owner column, and the willingness to write "nobody" in it honestly.

Retire what should not exist

Now the most satisfying step, and the most skipped: deletion. Some fraction of what you just counted has no reason to exist. The demo environment for a product you sunset. The staging copy of the site from a redesign three years back. The microsite a marketing vendor handed over and nobody claimed. The API version you replaced but never turned off.

Every host you retire is a permanent subtraction: no patching it next quarter, no monitoring it forever, no 3 a.m. page about it ever. Deletion is the only remediation that never recurs.

While you are in the DNS zone, hunt for records that point at infrastructure you already tore down: the CNAME aimed at a deprovisioned cloud app, the A record for a released IP. Dangling records are worse than dead weight, because on many platforms whoever provisions that name next inherits your subdomain, wearing your domain on content you do not control. Resensor flags these, but the habit matters more than the tool: infrastructure teardown is not finished until the DNS that pointed at it is gone too.

Gate what should not be public

Some of what remains has to exist but never needed to face the internet. Admin panels. Database ports. Remote desktop and SSH. The internal dashboard that was exposed "temporarily" during an integration. Monitoring consoles, build systems, file shares.

Move these behind something: the VPN, a zero-trust proxy, single sign-on, an IP allowlist, whichever your stack supports. If a service sits behind a CDN, check the origin does not also answer directly, because attackers query the host, not your architecture diagram. None of this fixes a single vulnerability, and it still shrinks your attack surface, because exposure is the precondition for exploitation. A flaw on a host only your VPN can reach is a task. The same flaw on the open internet is a countdown.

The test for this step is blunt: for every service still answering publicly, someone should be able to say why it must.

Fix what is left, in exploit order

What survives counting, retiring, and gating is your deliberate surface, and it will still carry findings. This is where most teams fall back into sorting by severity, and severity is the wrong order. It ranks how bad a flaw could be in theory, not whether anyone can use it against you this week.

Work exploit evidence first: vulnerabilities on CISA's Known Exploited Vulnerabilities list, findings with public exploit code, anything with a high probability of exploitation per EPSS. That evidenced short list is genuinely short, usually a screenful, and clearing it removes the paths an attacker would actually pick. Then schedule the real-but-unevidenced fixes into your normal cycle, and batch the hygiene, the headers and email authentication and TLS tidying, into sprints that finish.

Resensor stamps this triage on every finding as one word, exploitable, fix, or hygiene, so the queue arrives pre-sorted. But the principle holds with any tooling: prioritize by what is exploitable, not by what sounds worst.

Hold the line

Here is the part the strategy deck always omits: reduction decays. Next sprint mints a new certificate, a new subdomain, a new open port. The vendor re-points a record. A teammate ships a quick demo on a public URL. Six months of entropy quietly rebuilds what one hard week removed.

So the last move is standing, not one-time: watch the diff. Re-enumerate on a schedule, compare against the deliberate surface you decided on, and treat every new public asset as a question with a deadline: intended, or drift? Resensor rescans continuously and alerts when something new appears, a fresh host, a new exposure, a lookalike domain, so the question gets asked the week the surface changes instead of at the annual review.

The end state worth aiming for is not zero surface. It is a surface where everything public is public on purpose, owned by someone, and watched. Count, retire, gate, fix in exploit order, hold the line. Four of those five moves are decisions your team can start this week; we built Resensor to do the counting, the ranking, and the watching around them.