Most guides to attack surface management for MSPs stop at "your clients have more exposure than they think." True, and not much use on a Monday morning. This one is about running it: how to onboard client domains, how to keep one client's alerts out of another client's inbox, what belongs in the monthly report, and how to price the service so it makes money. We build an external monitoring tool with an MSP plan, so read the product specifics as first-party; the process works with any tool that meets the criteria further down.
Why MSPs need external attack surface management
MSPs need external attack surface management because they answer for client exposure they did not create and often cannot see: the marketing site a contractor launched, the forgotten staging subdomain, the DNS record still pointing at a deleted cloud bucket. Four pressures make that visible.
- Client estates sprawl without you. Clients buy SaaS, hire agencies and spin up landing pages without opening a ticket. Certificate transparency logs and DNS show those changes even when your RMM does not, because none of it runs on a device you manage.
- Liability follows the relationship. When a client's certificate expires or a subdomain is taken over, the first call goes to their IT provider. The joint advisory from CISA, the NSA, the FBI and Five Eyes partners on threats to MSPs tells organizations to periodically review their internet attack surface, and tells MSPs to spell out in contracts which services the customer is and is not buying. Monitoring plus a clear scope statement covers both.
- Cyber insurance is already looking. Some insurers now watch policyholders from the outside. Coalition, for example, gives policyholders attack surface monitoring that shows exposures "in the same way threat actors see them." If the carrier sees an open RDP port or a lapsed DMARC record before you do, that is an awkward renewal meeting.
- It is recurring revenue that needs no agents. External monitoring needs a domain name and proof of control, not software on client machines. That makes it one of the easiest security services to add to an existing contract, and each finding is a natural conversation about remediation work you can quote.
How attack surface management works, in three components
Attack surface management works as a loop of three components: discovery (finding what exists), assessment (checking how each thing is configured) and monitoring (re-checking on a schedule and alerting on change). For an MSP, each one has to run per client.
| Component | What it does | What it catches for a client |
|---|---|---|
| Discovery | Enumerates subdomains from certificate transparency logs and DNS, and spots lookalike domains | The forgotten staging. host, a vendor-run subdomain, a newly registered typosquat |
| Assessment | Checks TLS, security headers, SPF/DMARC/MTA-STS/CAA records and exposed ports | Weak or missing DMARC, a certificate from an unexpected CA, an exposed database port |
| Monitoring | Re-runs checks on a schedule and diffs against the last result | A certificate that stopped renewing, a DNS record someone changed on Friday night |
The monitoring step is the one that turns a one-off assessment into a service. A single scan is a sales tool; the diff against last month is what a client pays for. For the longer version, see what external attack surface management is.
How to run attack surface management across a client book
Run it as a standard onboarding and reporting routine, identical for every client: verify, separate, route, review, report. Once DNS access is sorted, setup is a short, repeatable checklist per client.
1. Onboard with ownership verification, not assumptions
Before you monitor a client domain, prove the client controls it and that you are authorized to watch it. Attack Surface Scan accepts any one of four proofs: a DNS TXT record, a file served from the client's site, signing in with an email address at the domain, or an emailed approval from someone with a mailbox there. The approval is usually the fastest path for an MSP: send a request to your contact at the client, they click approve, and nobody touches DNS. Where you already manage the client's DNS, adding the record yourself works just as well.
Also put monitoring in writing. Add a clause to the MSA or statement of work naming the domains in scope, the type of testing (passive external monitoring), and what is out of scope. That is exactly the "services the customer is not purchasing" clarity the CISA advisory asks for, and it protects you if a client later asks why you did not catch something the service never covered.
2. Give every client its own workspace
File each client's domains under a separate workspace so that dashboards, findings and reports never mix. The test is simple: could you export one client's report and hand it over without redacting anything? If not, your tenancy model is wrong. On the MSP plan, client workspaces group domains per end customer, and subdomains found in certificate transparency are added to that client's monitoring automatically, counting against the per-domain host allowance (250 hosts per domain) rather than your domain slots.
3. Route alerts per client, by severity
Critical changes (a certificate about to expire, an unknown certificate issued for a client domain, a new exposed service) should land in the client's queue immediately; everything else can wait for a weekly digest. Scope a notification channel to one client, pointed at email, Slack or a webhook into your PSA, so an alert becomes a ticket against the right company. The failure mode to avoid is one shared inbox that receives everything and that nobody owns.
4. Review weekly, report monthly
Spend a few minutes per client each week on the digest: close what is expected, ticket what is not. Then send a monthly report. Monthly is the cadence that matches most managed service agreements and QBR prep; quarterly is too slow to catch certificate and DNS drift, and weekly reports go unread.
How to generate security reports for MSP clients
A good MSP security report is short, dated, branded as yours, and answers three questions: what changed, what is still open, and what the client has to do. Generate it from the monitoring tool as a dated PDF per client workspace, then add two or three sentences of your own at the top. The human summary is the part clients read.
What to put in a monthly client report:
- One-paragraph summary in plain language: overall posture, and whether it improved or slipped since last month.
- Changes since the last report: new subdomains discovered, DNS and email authentication record changes, new certificates issued.
- Open findings by severity, each with an owner (you, the client, or a named vendor) and a target date.
- Certificate expiry calendar for the next 60 days, which matters more every year as certificate lifetimes shrink toward 47 days.
- Email authentication status: SPF, DMARC policy level, MTA-STS. Clients understand "someone could send email as you" faster than any other finding.
- Lookalike domains registered during the month, if any.
- Resolved this month, to show the service is doing work.
- Scope statement: what the monitoring covers and what it does not. For Attack Surface Scan that means stating plainly that it is passive external monitoring, not authenticated vulnerability scanning or active web application testing.
The same dated reports double as evidence when a client faces an audit or an insurance questionnaire; see attack surface monitoring as audit evidence.
White-label security reporting
White-label means the client sees your brand, not the vendor's: your logo, firm name and accent color on the PDF, and alerts arriving through your tooling. It matters less for vanity than for the relationship. A report that looks like it came from a third-party vendor invites the client to ask why they are not buying from that vendor directly. On the Attack Surface Scan MSP plan, you set branding once and every generated report carries it.
How to package and price EASM as a managed service
Price attack surface monitoring on the analyst time it takes, not on the tool cost, because the tool is the smallest line item. Sell it either as a line item on every managed contract or as a security add-on tier, and put the review time in the price.
A worked example using our own MSP plan ($149/month for 25 verified domains). The labor rate and review times are assumptions; replace them with your own.
| Line | Assumption | Monthly |
|---|---|---|
| Client book | 10 clients, 25 domains total | |
| Tool cost | MSP plan, flat | $149 |
| Analyst time | 30 min per client per month (weekly triage plus report), 5 hours at a loaded $75/hour | $375 |
| Total cost | $524 | |
| Revenue at $49 per client | Sold as a cheap add-on | $490 (a loss of $34) |
| Revenue at $99 per client | Sold as a monitoring and monthly report line item | $990 (gross margin $466, about 47%) |
Three honest takeaways from that table:
- The tool is about $6 per domain ($149 divided by 25), so it rarely decides whether the service is profitable. Labor does.
- Underpricing is the real risk. At $49 per client the service loses money unless review time falls well under 30 minutes. Either price for the time or automate the triage (routing criticals straight into the PSA helps most).
- Remediation is billed separately. Monitoring finds the expired certificate and the missing DMARC record; fixing them is project or ticket work at your normal rates, and that is where much of the upside sits.
If your book grows past 25 domains, the MSP plan is no longer the right fit and it becomes an Enterprise conversation; the arithmetic above changes with the quote. Plan details are on the MSP partners page and pricing.
What to look for in attack surface management for MSPs
The best attack surface management tool for an MSP is the one whose tenancy, pricing unit and reporting match a client book, not the one with the longest feature list. Use these criteria to shortlist.
| Criterion | Why it matters to an MSP | What to ask the vendor |
|---|---|---|
| Multi-tenant client workspaces | Findings and reports must never cross clients | Can I export one client's report with nothing from another client in it? |
| White-label reports | The client relationship stays yours | Can I set my logo, name and colors on every PDF, and is it included or an extra fee? |
| Per-client alert routing | Alerts must land in the right PSA queue | Can a Slack channel or webhook receive only one client's alerts? |
| Pricing model | Per-asset metering makes client pricing unpredictable | Is it flat per domain or workspace, or metered per discovered asset? |
| API or MCP access | Automate onboarding, pull findings into your own tooling or AI assistant | Is there an API or hosted MCP server, and on which tier? |
| Passive vs. active scanning | Active probing of client systems needs explicit written authorization | Exactly what traffic does the tool send to client hosts? |
| Ownership verification | Protects you from monitoring a domain the client does not control | How is control of each domain proven before scanning starts? |
| History and dated reports | Audit and insurance evidence needs a record over time | How long are results kept, and are reports dated? |
Be clear about what you are buying. Attack Surface Scan is passive external monitoring: it does not do authenticated CVE scanning, active web application testing or DMARC aggregate report processing. If a client contract requires credentialed vulnerability scanning, pair it with a scanner built for that; our comparisons with Intruder and OpenVAS cover where each fits. For a wider market view, see the best external attack surface monitoring tools and what attack surface management costs.
Free attack surface management for MSPs: what it really costs
Free and open-source tools can do most of the discovery and assessment work, but for an MSP the hard part is not scanning: it is running the scans per client, keeping history, routing alerts and producing a branded report every month. That glue is what you end up building.
| Tool | Covers | What you still build |
|---|---|---|
| OWASP Amass, Subfinder | Subdomain discovery | Scheduling, per-client storage, diffing new hosts |
| nuclei | Templated checks against hosts | Template curation, false-positive tuning, authorization tracking |
| testssl.sh | TLS configuration and certificate checks | Expiry calendar, alert thresholds |
| dnstwist | Lookalike domain permutations | Recurring runs, noise filtering per client brand |
| (all of the above) | Tenancy, alert routing, branded PDF reports, uptime of the pipeline itself |
At the same assumed $75 an hour, eight hours a month to keep a multi-client pipeline healthy is $600, four times the MSP plan price, before anyone builds the report template. Self-hosting can still be the right call for an MSSP with engineering staff and custom needs; it is rarely the cheap option for a ten-person MSP. There is a longer comparison in the best open-source attack surface management tools, and our free security tools (such as the dangling CNAME checker and SPF and DMARC checker) are useful for a quick look at a prospect's domain before a sales call.
A 30-day rollout plan
- Week 1: pick three friendly clients, add the monitoring clause to their agreements, verify their domains.
- Week 2: set up workspaces and per-client alert channels into your PSA; tune which alerts are ticket-worthy.
- Week 3: produce the first report for each, fix the obvious findings, and note how long review actually took.
- Week 4: set the price from measured review time, then roll it into your standard contract for the rest of the book.
Frequently asked questions
What are the best attack surface management platforms for MSPs?
The best fit for an MSP has multi-tenant client workspaces, white-label reports, per-client alert routing and a flat pricing unit you can resell. Enterprise EASM platforms suit large MSSPs with big budgets; lightweight monitors priced per domain suit most MSPs. Shortlist on those criteria first, then compare features. Attack Surface Scan's MSP plan is $149/month for 25 domains with those four features included.
How does attack surface management work?
It discovers internet-facing assets (subdomains from certificate transparency logs and DNS, lookalike domains), assesses how each is configured (TLS, headers, DNS and email authentication, open ports), then re-checks on a schedule and alerts when something changes. For an MSP, the same loop runs separately for each client.
What are three key components of attack surface monitoring?
Discovery, assessment and continuous monitoring. Discovery finds what exists, assessment checks how it is configured, and monitoring re-runs the checks and alerts on change. Without the third, you have a one-off audit rather than a service.
Is there free attack surface management for MSPs?
Open-source tools such as OWASP Amass, Subfinder, nuclei, testssl.sh and dnstwist cover discovery and many checks for free. What they do not provide is client separation, alert routing, history and branded reports, and building and maintaining that usually costs more in engineer time than a paid MSP plan. Most paid tools, including ours, offer a free trial.
How do I generate security reports for MSP clients?
Generate a dated PDF per client from your monitoring tool each month, branded with your logo, and add a short plain-language summary on top. Include changes since the last report, open findings with owners, upcoming certificate expiries, email authentication status, what was fixed, and a clear statement of what the monitoring does not cover.
Do I need client permission to monitor their attack surface?
Yes. Get written authorization in the service agreement naming the domains and the type of testing, and prove control of each domain before monitoring starts. Attack Surface Scan requires proof for every domain (a DNS record, a file on the site, a work email at the domain, or an emailed approval from someone there), so it cannot be used to monitor a client without their knowledge.