Most MSP Failures Look the Same. Here's What to Watch For.

Every business gets to a point where it cannot keep running its own IT. The reasons are not exotic. Nobody on payroll wants to be the one who patches the file server at midnight. The good systems person who used to handle all of it left for somewhere bigger, and the person hired to replace her can do about half of what she did. The auditor is asking for documentation that nobody on staff has time to produce. So the business hires a managed service provider, signs a contract for a flat monthly fee, and starts to feel like the IT problem has been put somewhere else.

It is rarely put somewhere else as cleanly as the brochure suggests. Some of the worst incidents I have watched up close did not come from a clever attacker getting past a careful defender. They came from an MSP that looked fine for three years and then suddenly did not. The pattern is consistent enough now that it is worth describing, and worth saying out loud what a good MSP actually does differently, because the two pictures are easier to tell apart than the marketing makes them look.

The Tool That Was Supposed to Protect You Becomes the Way In

The most expensive single lesson the MSP industry has ever received was the Kaseya VSA incident in July 2021. The REvil ransomware group exploited a vulnerability in the remote monitoring and management software that around sixty MSPs were using to keep an eye on their clients' systems. Through those sixty MSPs, the attackers reached more than a thousand downstream organisations in a single afternoon. The vehicle was not a phishing email and it was not a stolen password. It was the tool the MSPs had bought to make their clients safer.

You might think the industry would have repriced its assumptions after a lesson like that. In some places it has. In many it has not. In June 2025, CISA and the FBI issued a joint advisory about active exploitation of SimpleHelp RMM, another popular MSP tool, by ransomware groups including affiliates linked to the Play gang. Same idea, different logo. Compromise the management software, ride it into every customer the provider is managing, encrypt or exfiltrate at leisure. Ingram Micro, the GJTec compromise in South Korea that fed the Qilin group dozens of downstream victims, a long line of car dealership platforms — the supply-chain incident tally through 2025 has put paid to the idea that the MSP channel is a fluke target. It is the front door.

MSPs are not the villains here. But an MSP is, by construction, a high-leverage point in your security model. They have privileged access to your systems because they have to in order to do the job. Whatever discipline they bring to their own security is being quietly extended to yours. If they cannot answer specific questions about how they protect their RMM tooling, their credentials, and their people, you have inherited the risk of an organisation nobody assessed.

The Quiet Kind of Failure

Supply chain attacks get the headlines. The more common kind of MSP failure does not. It is slower, less photogenic, and tends to be noticed only after something has already gone visibly wrong.

It looks like this. A monthly invoice arrives like clockwork. The help desk picks up the phone, mostly. Tickets get closed eventually. Patches happen sometimes, on a cadence nobody on the client side really tracks. The backup system was configured by someone four years ago, who has since left both organisations. Reports go out, when they go out at all, in a format nobody reads. The relationship feels fine because nothing has blown up.

Then something blows up. A storage volume fails on a Friday afternoon. The on-call engineer the client thought they had has actually been off the account for nine months because of an internal restructure nobody mentioned. The most recent successful backup is from a date everyone hopes is recent enough. The disaster recovery runbook lives in a Google Doc that references a person who no longer works there. Recovery happens, eventually, at a cost in real money and real hours that nobody had budgeted for, and the post-mortem turns up signs that had been there for a long time. They just had not been measured.

I have watched this kind of failure twice in the past year alone. Different industries, different MSPs, almost identical playbook. Neither one ended with anyone losing their job. The relationship continued, slightly chastened, because changing MSPs felt like more pain than carrying the one they had. That bias toward inertia is exactly the thing a marginal provider quietly relies on.

Restores That Have Never Been Tested

Of all the questions worth asking an MSP, the one that sorts the serious from the unserious most reliably is about backups. Specifically about restores. Almost any provider will tell you backups are running. A much smaller number can tell you when the last successful restore was actually performed, what was restored, how long it took, and where the documentation of that test lives. The gap between "we have backups" and "we restored a representative workload last Tuesday and it took forty-one minutes" is the gap between a vendor and a partner.

The same goes for most of what an MSP claims to do. Patching is not a status. It is a logged event with a date on it. Monitoring is not a license you paid for. It is a set of alerts that someone actually responds to within a defined time. Endpoint protection is not a sticker on the homepage. It is a configuration that has been reviewed for your environment and tuned for the things you actually run. Each of these is testable. The good provider will welcome the test and will usually have run it on their own initiative before you thought to ask.

Lock-In, Politely Dressed Up

The other place these relationships go quietly wrong is at the exit. A good provider treats your data, your documentation, and your credentials as yours. They keep an inventory of your environment that you can access. They store your administrative accounts in a way that does not require their continued cooperation to retrieve. If you decided tomorrow to bring everything in-house or move to a different provider, they would hand you a clean package within an agreed window. The transition would be tedious without being adversarial.

A weaker provider does not say no when you ask about any of this. They just make leaving slightly harder than staying. Documentation lives only inside their ticketing system. Credentials live only inside their password manager. The network diagram lives in someone's head, and the someone in question is on their payroll. None of this is presented as lock-in. It is presented as service. The practical effect is that the cost of switching keeps quietly going up, and the leverage in the relationship keeps quietly shifting in the wrong direction.

A useful test is to ask, before signing, what offboarding looks like. Not in the abstract. In writing, in the contract, with timelines and deliverables. The providers worth working with will already have an answer drafted. The ones to be wary of will look briefly annoyed that you asked.

What Good Actually Looks Like

It would be reasonable to conclude from all of the above that hiring an MSP is a uniformly bad idea. It is not. The good ones materially improve their clients' security and resilience, often by more than the client could ever do on their own at any reasonable internal cost. They tend to share a handful of traits.

They run their own internal security to a standard at least as high as what they are selling. If they are helping you toward SOC 2, they have been through it themselves and can show you the report. If they are talking to you about multi-factor authentication on every account, they have it on every one of their own, including the RMM tooling that touches your network. The bar they hold themselves to is the floor of the bar they hold for you.

They report unprompted. The monthly report shows up before you ask, contains numbers tied to things you actually care about, and flags issues you did not know to ask about. When the backup system has had a degraded week, they tell you before you find out from a failed restore. When a phishing campaign is making the rounds in your industry, they tell you what they have already done about it on your behalf.

They are clear about what is in scope and what is not. The provider that gives you a flat fee for the predictable work and a clear hourly rate for the unpredictable work is being honest with you. The provider that promises everything for everything is either underpricing the contract or quietly planning not to do all of it, and you only find out which one after the ink is dry.

They take their own incident response seriously, with you in the loop. They have a defined process for what happens if they get breached, not only for what happens if you do. They will tell you that process before you ask, and they will not be insulted by the question. They are not evasive about their own posture, because they are quietly proud of it.

And they show their work. Patching has logs. Restores have evidence. Alerts have runbooks. Tickets have an owner with a name. None of it is a marketing line. It is operational, and they can put it on the screen on a call without rehearsing.

The Questions That Get You the Truth

There is a separate one-page MSP Vetting Checklist alongside this article with the specific questions worth putting in front of a prospective or current MSP, and what good and bad answers actually sound like in each case. The short version is this. Ask what security framework they hold themselves to, and ask to see proof. Ask when they last restored a real workload from backup, and how long it took. Ask how they handle their own credentials and their own remote access tooling. Ask what offboarding looks like and get it in writing. Ask about the last security incident they handled — their own, or on behalf of a client — and what they changed in their practice afterwards. The providers worth signing with will treat those as fair questions and answer them properly. The ones to walk away from will treat them as suspicion to be managed.

What This Means for Whoever Is Signing the Contract

Hiring an MSP is a security decision before it is a procurement one, and it does not stop being a security decision once the contract is signed. The vendor you chose three years ago is not necessarily the vendor you have today. Their staffing has changed, their tooling has changed, the threat landscape they work in has changed, and whether any of that has been re-examined in your specific contract is something only you can find out by asking.

The work is unglamorous and cheap. A serious annual review of the MSP relationship — what they have actually done, what they have not done, what has changed on their side, what you have stopped tracking on yours — is one of the highest-yield exercises in most security programmes. It surfaces either real confidence in the provider, which is genuinely useful, or a quiet set of issues that have been accumulating below the surface, which is exactly what you would rather find before something forces you to.

The MSP failures I have watched all had warning signs months in advance. None of the signs were exotic. They were just the kind of question nobody on the client side had asked recently enough to notice the answer had quietly changed.

You cannot fully predict the incident that will test your organization. You can absolutely control the quality of the people, processes, and authority structures that respond to it. That preparation is the difference between organizations that recover in days and those that recover in quarters.