Most MSPs already run some kind of vulnerability service. A scanner finds issues, tickets get opened and a report goes out each month. Then it stalls. The cause is rarely effort. It is five specific problems, and each one has a fix.

I'm Richard Daly, Partner Lead for the UK and Ireland at Nanitor. I work with MSPs, and I read the open threads where MSP owners and engineers compare notes. The same five problems come up again and again. This post names them and shows what a better answer looks like.

If you want to see how we handle them, there is an easy way to do that at the end. There is no commitment, and you can get started today.

Why does a vulnerability service stall inside an MSP?

A scanner finds problems. A service fixes them, proves it and gets paid for it. Most MSPs have the first part. At least one of the other three is usually missing.

That is the gap. The five problems below are where it opens up.

Problem 1: Tools that were not built for many clients

Many vulnerability products were designed for one company with one security team. MSPs end up using them anyway. Multi-tenant support can be thin, so you rebuild the same settings for each client and dig through alerts to work out which client they belong to.

Agents are the other weak point. An agent that quietly stops reporting is worse than a noisy one, because a silent device looks like a clean device.

Whatever you evaluate, ours included, ask four questions:

• Can I see every client in one view and keep their data separate?
• How will I know when an agent stops reporting?
• Can I set a policy once and apply it across clients?
• How much of the alert volume is noise?

Nanitor is a multi-tenant platform built for MSPs and MSSPs, with agent status and security posture for all customers in one view. Agents can be rolled out through the RMM tools you already run, with integrations for NinjaOne and Datto RMM

Problem 2: One ticket per CVE

Scanners report in CVEs, the public identifiers for known vulnerabilities. People work in priorities. If every CVE becomes a ticket, your service desk drowns and your clients' real risks sit somewhere in the pile.

Severity scores alone do not solve it. A critical flaw on a spare laptop is not the same as a medium flaw on the server that runs a client's finance system. You need to rank by how serious the flaw is and how much the asset matters, then work from the top.

That is what Nanitor Diamond is for. It goes beyond the CVSS score and plots issues by how critical they are and how critical the affected asset is. Serious issues on important systems sit at the top, so your engineers start there instead of with a list of thousands.

The goal is not fewer findings. It is fewer, better-aimed decisions.

Problem 3: Nobody agreed who fixes it

“Vulnerability management” means different things to different clients. One expects you to patch everything. Another expects a report. A third patches its own servers and wants you for the rest. If the scope is not written down, the first unpatched server turns into an argument.

Define the service in three levels and put the level in the contract:

• Find: you identify and report. The client remediates.
• Coordinate: you prioritise, raise the work and track it to closure.
• Fix: you remediate within agreed windows.

For co-managed clients, add a simple RACI (who is responsible, accountable, consulted and informed) for each step, including who approves a reboot.

This is a service design problem, not a tooling problem. No platform can settle it for you. But the right one makes each level easy to deliver and easy to show.

Problem 4: The client thinks they could do this themselves

If your service is a list of findings and a stack of tickets, clients are right to ask what they are paying for. Anyone competent can run a scan. The value is in the outcome: the right things fixed first, and evidence that they were.

That means reporting a client can use without a login. Nanitor management reports export as PDF or CSV and can go to managers and auditors who never open the platform. Nanitor HealthScore turns how well an estate is patched, configured and secured into a single percentage, so a client can see their direction of travel in one number.

A scan shows what is wrong today. A trend shows what you fixed.

Problem 5: Enterprise tools that cost too much to run

Enterprise scanners can be strong. They also assume a team to set them up, tune them and keep them running. For an MSP serving small and mid-sized businesses, that overhead can wipe out the margin on the service. Heavier tooling is rarely the answer. A repeatable routine that fits the client's size and maturity usually matters more, run on a platform you can afford to operate.

Nanitor is a SaaS-based, multi-tenant platform. The Icelandic MSP Tölvuþjónustan ran a proof of concept on its own systems before offering it to its customers. That is how I would suggest any MSP starts: on your own estate first, before a single client sees it.

What does a working MSP vulnerability service look like?

Put the five fixes together and the picture is simple. One view across clients. Issues ranked by what matters. A clear scope for each client. Evidence clients can read. And tooling that does not eat the margin.

Nanitor is a Continuous Threat Exposure Management (CTEM) platform. It keeps discovering assets and exposures and ranks them by real business impact. One honest point about where it fits: Nanitor does not apply patches. Your RMM or patching tool does that. What Nanitor does is tell you what to fix first and keep checking the real state of each host, so a fixed issue shows as fixed and a failed patch is much harder to miss. We wrote up how we know our own automated patching works if you want to see that in practice.

I will go deeper on each of these problems in the posts that follow.

Findings are cheap. A service that fixes, proves and reports is what clients keep paying for.