Attack Surface Management: the complete guide for MSPs

A modern attack surface is no longer just a website. Every client you manage exposes endpoints, cloud tenants, SaaS apps, identities, home-office networks and a long tail of shadow IT — and all of it changes every week. Attack Surface Management (ASM) is the discipline of continuously discovering, inventorying and monitoring that entire footprint. This guide breaks the surface into its real layers, walks the ASM lifecycle, and shows how an MSP runs it across a whole client portfolio.

What attack surface management is

Attack surface management is the continuous discovery, inventory, assessment and monitoring of everything a client exposes to an attacker — not just what faces the internet, but the endpoints, cloud tenants and identities behind it too.

Unlike a point-in-time penetration test or annual audit, ASM treats the surface as a live system that changes constantly. It has three standing jobs: know what you have (inventory), know what’s weak (assessment), and know what changed (monitoring).

The layers of a modern attack surface

Most “attack surface” conversations stop at the perimeter. For an MSP, the real surface spans seven layers — and a gap in any one of them is a way in:

External / internet-facing — domains, subdomains, public IPs, open ports, TLS certificates, email authentication (SPF/DKIM/DMARC), and forgotten admin panels or services. The classic “EASM” layer — and only the first.
Internal endpoints & servers — workstations and servers behind the firewall: unpatched and end-of-life software, missing or disabled EDR, open SMB/RDP, local-admin sprawl, unencrypted disks and weak baseline configuration. Invisible to any external scan.
Cloud & SaaS posture — AWS, Azure and Microsoft 365: public storage buckets, over-permissive IAM roles, exposed databases, disabled logging and risky network rules.
Identity — the real perimeter today: user and admin accounts, MFA coverage, privileged-role assignments, stale or orphaned accounts, risky OAuth app grants, and partner / GDAP delegated access into client tenants.
Remote workers & home networks — laptops that roam off the corporate LAN, split-tunnel VPNs, home routers and personal / BYOD devices that never touch your monitored network but still hold client data and credentials.
Shadow IT & unmanaged assets — the long tail nobody documented: unsanctioned SaaS sign-ups, dev/test and staging environments, marketing microsites, abandoned cloud accounts and expired-but-live subdomains.
Third-party & supply chain — the vendors, integrations and embedded scripts a client trusts. A breach or misconfiguration upstream becomes their exposure — and yours.

The ASM lifecycle

ASM is a repeatable loop, not a one-off project. Each pass runs the same six steps:

Discover — enumerate every asset across all seven layers, including the ones nobody told you about.
Inventory — build a living asset register: what each asset is, who owns it, and where it lives.
Assess — test each asset for weaknesses: known CVEs, misconfiguration, weak crypto and needless exposure.
Prioritize — rank by real-world risk using exploitability signals (KEV/EPSS) and business exposure, not raw CVSS alone.
Remediate — drive each issue to closure through a workflow with clear owners and deadlines.
Monitor — re-run continuously and diff against the last baseline, so new or changed assets surface as alerts instead of surprises.

Why MSPs are uniquely exposed

You manage dozens of environments, each with its own shadow IT and forgotten assets — you inherit unknowns you didn’t create. A single dangling subdomain, public bucket or unpatched edge device in any one client can become a breach, and your reputation rides on it.

Per-client spreadsheets don’t scale. What scales is portfolio-wide visibility with per-client drill-down — one place that answers “which of my clients is drifting, and where.”

Running ASM across a portfolio

Baseline every client at onboarding, then scan on a schedule. Diff each scan against the last and alert on new, changed or removed assets so discovery becomes a feed rather than a project. Roll the results up into a portfolio view of which clients are drifting, with the detail one click away, and track each client’s posture as a score over time so you can show trend — not just a snapshot.

Turning findings into action

Discovery only matters if it drives remediation. Give every finding an owner and an SLA by severity, and push it into your PSA as a ticket so it lives in the workflow your techs already use. Then report posture back to each client under your own brand — a clean view of what you found and fixed is what builds the trust that renews contracts.

How SBCMSP covers the whole surface

SBCMSP maps every layer above to a module in one multi-tenant console: external scanning, an internal agent for Windows, Linux and macOS, cloud posture for AWS, Azure and Microsoft 365 / Entra, identity and email-security checks, and third-party software with CVE matching.

All of it — 5,588 checks — runs continuously and diffs against the last scan. Findings flow into one remediation workflow with KEV/EPSS-aware prioritization, AI remediation guidance, PSA tickets and white-label client reporting. See the full platform for how the pieces fit together.

Getting started

Pick a pilot client and run a free external scan to map the internet-facing layer in minutes.
Deploy the internal agent to a handful of endpoints to surface the internal layer.
Connect one cloud tenant — Microsoft 365, AWS or Azure — to reveal cloud and identity exposure.
Set a scan cadence, wire findings into your PSA, and turn on white-label client reporting.
Expand across the portfolio once the loop is running.