The Door the MSP Installed
The breaches MSPs prepare their clients for usually start with a person logging in. The incidents landing on MSPs start with the MSP’s own tools.
A quick disclosure before we start. I own shares in N-able, which is part of this story.
Start with an update on N-able. On this show, I reported that N-able took its hosted N-central platform offline after a researcher published more than 30 alleged vulnerabilities. N-able has now released a hotfix, N-central 2026.4 HF2. It says all hosted servers across every region have been upgraded and are back online. Customers running N-central on their own servers were told to apply the hotfix before restoring internet access. N-able hasn’t flagged the flaws as exploited, but threat intelligence firm Defused says attackers have started scanning for vulnerable systems. The Shadowserver Foundation counted 1,338 N-central servers exposed to the internet, and later just over 148. The disclosure itself is in dispute. The researcher, Sean Bales, says he went public because earlier reports about another N-able product went unpatched. N-able says that claim is inaccurate.
Now a follow-up on ConnectWise. On October 20, I told you about one ConnectWise Cloud Backup credential that signed in to 173 Microsoft 365 tenants in a little over two hours. The fuller picture is larger. Channel Insider reports the outage disrupted more than 2,300 MSP partners. Huntress found suspicious sign-ins across nearly 1,000 accounts, and more than 300 were successful intrusions. The secrets attackers planted in other trusted tools were set to expire in 2028. That’s access built to outlast the cleanup. And ConnectWise says it can’t tell individual MSPs whether their clients’ tenants were accessed or changed.
Set that against what the industry measures. GTIA’s quarterly cybersecurity tracker surveyed 309 North American providers. Ninety-three percent offer cybersecurity. Only 42 percent have multifactor authentication on all critical systems for more than half their customers.
Hear what that adds up to. The industry is still counting how many clients have MFA. The incidents keep arriving through the MSP’s own tools, not through a client’s login.
In plain terms, the door that keeps opening is one the MSP installed.
So why doesn’t the client ever see it?
Consent the Client Never Gave
Underneath all of this is one dynamic. Microsoft built the partner model so an MSP can act on a client’s behalf, and that includes saying yes on the client’s behalf. Every tool the MSP connects inherits that yes.
Start with how the consent works. Microsoft’s own partner documentation explains that under granular delegated admin privileges, either the customer or an admin with an on-behalf-of relationship to the customer consents to let partner-managed applications use the customer’s tenant. In practice, that admin is usually the MSP. The credential that comes out of that consent replaces a person. Microsoft’s guidance says the stored refresh token is used by the application or script instead of user credentials when it authenticates. No one signs in, so there’s nothing for MFA to check.
Now look at what happens when a vendor in the middle is breached. MSP Process makes identity and user-management tools for more than 1,000 MSPs, connected to the major PSA platforms. Its apps typically hold permissions in client tenants to read and write user accounts and their authentication methods. The company told customers that anyone holding one of its app secrets could use those permissions without a user sign-in or MFA. Reportedly stolen: app IDs and secrets, administrator refresh tokens, and the lists of which client tenants each MSP has delegated access to. That’s the keys and the map.
A Huntress staffer responding to the breach reported successful malicious token grants in 47 tenants. Chief executive Patrick Leonard said containment on its platform “does not, on its own, confirm” that partner tenants are clean. And the cleanup advice for MSP Process users tells you where the consent came from: revoke sessions for the admin who originally connected the tool. That admin works for the MSP.
Now, a fair objection: clients hired the MSP to make exactly these decisions. True. They agreed to trust the MSP. They never saw the list of vendors the MSP extended that trust to, or what each one can touch. That’s a building manager handing copies of your key to every contractor he uses, and never telling you their names.
In plain terms, the consent runs through the MSP, so the access the client never chose is access the client never sees.
And there’s already a model for making that list visible.
Who Gets to See the Keys
For the MSP, the consequence is that the client is the last to know who can reach their business. The market is starting to show what knowing looks like.
Start with Microsoft. Microsoft will turn on access to Anthropic’s Claude models for UK Copilot tenants by default on December 9, unless an admin chooses otherwise. You can argue about that default. But look at what comes with it. Microsoft names Anthropic as its subprocessor. It says the relevant data is processed in the United States. It gives a date, and admins have until then to decide whether that meets their requirements. That’s a notice: who gets access, to what, where, and when. Your client gets that from Microsoft. Most get nothing like it about the tools their MSP has connected to their tenant.
Then there’s Action1, which deserves to be heard with some skepticism. The company published an open call inviting endpoint-management and RMM vendors, its competitors, to adopt its design. The idea: running scripts, deploying software and opening remote sessions each require cryptographic authorization from a private key the customer controls, so compromising the vendor’s platform isn’t enough on its own. Chief executive Alex Vovk says “no vendor can promise its platform will never be compromised.” Fair. But an offer to share architecture with competitors can be made privately, to their security teams. Making it by press release is a pitch. The release includes no independent testing, and it names no other vendor that has signed on. Take the idea. Discount the delivery.
Put those together. Both point the same way: the party whose business is at risk should be able to see the standing access and have a say over what it does. Today, for most MSP clients, neither is true.
So here’s the choice. Give each client a written list of every vendor holding standing access in their tenant: what it can touch, and where its credential lives. Get the client’s sign-off before you add another, and tell them when one changes. Or keep the access map as internal plumbing, and let your clients read it for the first time in the next vendor’s breach notice.
And which side of that choice you’re on decides who your client calls first, and whether you have the answer.
Because the next time a vendor in the middle is breached, every client will ask their MSP the same question, and only some MSPs will be able to answer it within the hour. Those MSPs had the conversation first. At a regular review, they walked the client through every vendor that can reach their tenant, what each one can touch, and the one they proposed to add, and asked whether there was anything the client would rather they didn’t connect. When the breach notice lands, that MSP can say which vendors were in the tenant and what’s been rotated, while the one that never had the conversation is explaining its own plumbing for the first time, mid-incident.
What to Consider
- Build the list from the tenant, not from memory. Pull every app with consent in each client tenant, and match it to the vendor holding its credential and the permissions it carries. Anything nobody can name an owner for comes off before the list goes to the client.
- Write the sign-off into the agreement. Attach the current vendor list as an exhibit, and require client approval before a new vendor gets standing access, with notice when an existing vendor’s permissions change. Microsoft gives admins a date and a decision when it adds a subprocessor, so give your clients at least that much.
- Use the review to shorten the list. Each vendor on it should be able to justify its standing access to the client in one line. If you can’t write that line, the vendor may not need tenant-wide access, or may not need to be there at all. A shorter list is easier for the client to approve and leaves less for the next breach to reach.
If this trend continues: By the end of 2027, a written list of vendors with standing access to the client’s tenant will be a routine question in client security reviews and cyber insurance applications, and MSPs that can’t produce one will be explaining why.