How MSPs Deliver Continuous Penetration Testing Without Hiring Pentesters

The bottleneck in MSP penetration testing has never been demand — it is senior tester hours. Here is the operating model that lets a managed service provider run continuous, evidence-backed pentests across every client tenant without growing the offensive team.

Prancer Research · 2026-08-25 · 9 min

Every managed service provider that sells security eventually hits the same wall. Clients want penetration testing. Cyber insurance underwriters ask for it. PCI DSS 4.0, SOC 2 and NIS2 all reference it. The MSP has the relationship, the access and the trust to deliver it — and no way to scale it.

So the MSP subcontracts. A consultancy runs a two-week engagement per client per year, invoices per engagement, and hands back a PDF with someone else's logo on it. The MSP marks it up, absorbs the scheduling pain, and books a thin margin on a service it does not control.

That model does not break because it is badly executed. It breaks because its unit of delivery is a human week, and human weeks do not multiply.

The real constraint: senior tester hours

Work backwards from the delivery capacity of a manual engagement.

| Input | Typical reality |

| --- | --- |

| Duration of one engagement | 1–2 weeks of tester time |

| Reporting and QA | 3–5 additional days |

| Engagements per tester per year | 25–35, realistically |

| Clients covered annually per tester | 25–35, at one test each |

| Cadence each client receives | Once per year, if that |

A 200-client MSP would need six to eight full-time senior testers to give every client a single annual test — before accounting for retests, scope changes, incident-driven work or attrition. Senior offensive security people are among the hardest hires in the industry, and the ones you find do not want to spend their careers re-running the same external network methodology against the 41st dental practice.

Meanwhile the client's attack surface changes weekly. An annual test is a photograph of a moving object.

What "continuous" actually has to mean

"Continuous penetration testing" is a phrase that gets attached to a lot of products that are really just scheduled vulnerability scanning. For an MSP the distinction is commercially important, because a client who has already bought a vulnerability management service will not pay twice for the same output with a different label.

Continuous pentesting, in a form a client will actually pay for, requires four things:

1. Exploitation, not inference. A scanner says "this version is affected by CVE-2023-XXXX." A pentest says "we exploited it, here is the shell, here is the data we reached." The second one changes behaviour; the first one generates a ticket that gets deferred. 2. Chaining. Real compromise is rarely one finding. It is a low-severity information leak that yields a credential that unlocks an internal service that grants a role that reaches the crown jewels. Chains are what separate a pentest from a scan. 3. Authenticated depth. Most of a modern estate — SaaS admin consoles, internal apps, cloud control planes, Active Directory — is invisible without credentials. Testing that stops at the login page tests almost nothing. 4. Repeatability without re-cost. If the second run costs the same as the first, it is not continuous. It is just more frequent.

Automation only solves the MSP's problem if it does all four. Automating step 1 alone gets you a scanner.

The autonomous operating model

This is where an agentic engine changes the arithmetic. SwarmHack™ decomposes an engagement into specialist agents that plan, act, observe the result and re-plan — the same loop a human tester runs, executed continuously and in parallel across tenants.

A run against a client tenant proceeds roughly like this:

Discovery. Enumerate the authorized scope: hosts, services, web applications, REST and GraphQL APIs, cloud accounts, Kubernetes clusters, Active Directory domains, identity providers.
Credential production. Harvest, spray within authorized limits, extract from misconfigured stores and exposed artifacts, and reuse what earlier stages produced.
Authenticated re-enumeration. Feed those credentials back into discovery. The second pass sees an order of magnitude more surface than the first.
Lateral movement and escalation. Chain what has been proven, hop by hop, recording each transition.
Evidence capture and grading. Every finding lands with the artifact that proves it and a grade: Exploited, Observed, AttackPathIdentified or Simulated.

That last item is the one MSPs should care about most. Evidence grading is what lets a service desk triage findings without a pentester in the room, and what lets a client's engineering team stop arguing about whether a finding is real.

For a worked example of what this produces end to end, the 200-IP AWS lab engagement documents 18 surfaces, 45 findings, 19 of them graded Exploited, and a complete four-hop IAM trust-chain compromise — with zero cloud-native attack detections raised.

Multi-tenancy is the part that has to be boring

An MSP cannot run one shared engine loosely pointed at many clients. The isolation model has to be structural, not procedural:

Each client is a separate tenant with its own scope definition, credential store, schedule and reporting boundary.
Every target is authorized per tenant before any packet is sent. Out-of-scope assets are refused, not warned about.
Execution is sharded across agent hosts under a shared rate limiter, so a large tenant cannot starve a small one and no client's environment absorbs the aggregate load.
Findings, evidence and artifacts never cross tenant boundaries — not in storage, not in reports, not in the search index.

Nothing here is glamorous. It is exactly the part that has to be right, because a cross-tenant leak in a security service is an existential event for an MSP.

What the analyst role becomes

The fear inside MSPs considering this shift is usually "does this replace my security team." In practice it inverts what the team spends time on.

| Before | After |

| --- | --- |

| Re-running the same external methodology per client | Reviewing graded evidence across the tenant base |

| Writing reports from scratch | Adding client-specific context to generated reports |

| Scheduling and scoping calls | Business-logic testing where automation genuinely stops |

| One engagement at a time | Oversight of continuous validation across dozens of tenants |

The automatable work — discovery, enumeration, known-technique exploitation, evidence capture, report assembly — is exactly the work that senior testers find least interesting. What remains is judgement: business logic abuse, client-specific threat modelling, remediation strategy and the executive conversation. That is also the work clients value most and pay most for.

Where this lands commercially

Three changes matter to the P&L.

Cadence becomes a product feature. Selling "quarterly validation with automated retests" is a different conversation from selling "an annual test." It justifies a recurring line item rather than a project fee.

Cost decouples from client count. A subscription spread across the tenant base means the marginal cost of the 80th client is close to zero. Under subcontracting it is the same as the first.

Retesting stops being a negotiation. When proving remediation costs nothing extra, you can promise it — and closing the loop is the single most visible thing a security service can do for a client's board.

You can model the specific numbers for your own book in the pricing calculator.

Getting started without betting the practice

The sane rollout is narrow and evidence-driven:

1. Pick three tenants with different shapes — one cloud-heavy, one with a significant Active Directory estate, one SaaS-and-web-app only. 2. Run continuous validation for one quarter alongside whatever you do today. 3. Compare on the metrics that matter to your clients: findings graded Exploited, mean time to first proven finding, and remediation verified. 4. Price the productised service from real delivery cost, not from a guess.

The MSPs that win this category will not be the ones with the largest offensive teams. They will be the ones whose delivery model does not need one.