How do you reduce your attack surface in practice?

Reducing your attack surface means giving an attacker fewer things to try: fewer exposed services, fewer accounts, fewer features and fewer dependencies. The order is simple. Find everything, remove what is unnecessary, restrict what must stay, then watch for changes. Deletion beats defense every time.

What is the attack surface?

It is the sum of the places where an attacker could get in or get data out: open ports, web endpoints, APIs, user accounts, installed software, code libraries, cloud storage and third-party integrations. Each one is a thing that can have a flaw, a bad setting or a stolen key.

NIST SP 800-53 control CM-7, least functionality, states the principle for systems: configure them to provide only the capabilities you decided are essential, and prohibit or restrict the functions, ports, protocols and services you did not. That one control covers a lot of practical hardening.

What are the main strategies?

Remove. Turn off unused services, delete old test environments, retire forgotten domains, uninstall software nobody uses, drop unused dependencies, and disable features nobody asked for.

Restrict. For what remains, narrow who can reach it. Put administration interfaces behind a VPN or an identity-aware gateway, limit database access to the application that needs it, and use allow lists for outbound connections.

Reduce privilege. Accounts and tokens with narrow permissions turn a successful attack into a small one.

Reduce code. Every dependency adds code you do not control. Fewer, better maintained libraries mean fewer chances for a vulnerable component. And a vulnerability in code that your application never calls is less urgent than one on a live path.

Patch what is exposed first. CISA's Known Exploited Vulnerabilities catalog is a list of flaws attackers are actually using. Anything exposed to the internet that matches it should jump the queue.

A constructed example

A software company inventories its internet-facing assets and finds 140 hostnames. Thirty belong to marketing campaigns that ended years ago. Twelve point at a staging cluster with a default admin password. Four expose a database port directly. The team deletes the dead campaign sites, takes staging behind single sign-on, closes the database port and puts the database in a private network. Nothing was patched, and the exposed surface dropped by about a third. The riskiest items went to zero.

The same method applies to code. A service pulls in 400 packages, and a scan flags 60 vulnerabilities. Reachability analysis shows that eight are in functions the service actually calls. The team fixes those eight now, schedules the rest, and removes five packages that were never used. Safeguard's exploitability check does this kind of triage, and the demo below shows it.

See the full walkthrough at /demos/exploitability-check.

What gets in the way?

• Unknown assets. Shadow IT and acquisitions create surface nobody inventoried.
• Fear of breaking things. Nobody wants to remove a service that might matter. A short scream test, where you disable it and wait for complaints, with a way to roll back, answers the question.
• Growth. The surface expands with every release, so reduction must be a recurring job.

How do you keep it from growing back?

Treat the surface as a budget. When a team adds an internet-facing service, a new third-party integration or a large dependency, the change request names the owner, the reason and the end date or review date. Run the external inventory weekly and compare it with the last run, so a new open port or hostname is noticed in days. In code, set a rule that new dependencies need a short justification, and prune unused ones during each release cycle. Reduction that happens once decays quickly. Reduction built into change control stays done.

How to check or apply this

1. Inventory external assets: domains, IP addresses, services, APIs, cloud storage and third-party tools.
2. Inventory internal assets that matter: servers, applications, accounts and dependencies.
3. For each item, ask whether it is needed and who owns it. Remove anything without an answer.
4. Restrict reachable services to the smallest audience, and require strong authentication for administration.
5. Compare internet-facing software against the Known Exploited Vulnerabilities catalog and patch matches first.
6. Repeat the inventory on a schedule and alert on new exposed services.

Quick check

Sources

• NIST SP 800-53 Rev. 5, CM-7 Least Functionality
• CISA, Known Exploited Vulnerabilities Catalog
• NIST SP 800-218, Secure Software Development Framework

Last reviewed: 18 October 2026.