ConnectWise Backup Exposure & Third-Party Risk Management for MSPs

In mid-October 2026, a credential belonging to ConnectWise’s Cloud Backup platform was used to sign into customers’ Microsoft 365 tenants. The tool that exists to protect client data became the path to it. For MSPs, that should change how vendor access gets reviewed, starting this week.

What Happened in the ConnectWise Cloud Backup Incident

CSO Online reports that security firm Huntress flagged suspicious sign-ins across 162 organizations by October 16. No user password was stolen and no MFA prompt was bypassed. The backup application requested Microsoft Graph tokens on its own, from an unfamiliar hosting-provider IP address. Nothing about the activity looked like a user getting phished. It looked like software doing what software does, which is why it was easy to miss.

In one partner tenant, a related ConnectWise app granted itself Global Administrator and added credentials to two other applications. All of it took about five minutes. ConnectWise responded by disabling seven application identities and revoking certificates. It also suspended Cloud Backup, SaaS Security and Cloud Management. That containment was a reasonable call, but it left partners without scheduled backups or restores, and no restoration timeline was announced.

Why Backup Tools Are Such an Attractive Target

Backup software needs deep access to do its job. It reads mail in Exchange Online, files in OneDrive and SharePoint, and conversations in Teams. That access is usually granted once, scoped broadly and left in place. A single credential with standing, tenant-wide permissions can reach every client an MSP supports at the same time.

The compromised credential lived in ConnectWise’s own tenant, not in any customer’s. Clients did nothing wrong and were exposed anyway. Huntress also warned that some Graph directory reads leave no audit trail. “No evidence of data theft” is not the same as proof that nothing was taken, and clients should hear that distinction from their MSP before they hear it from anyone else.

Why This Is a Third-Party Risk Management Problem

Third-party risk management is the practice of identifying, assessing and controlling the risk that comes from vendors and service providers with access to your systems or data. Most programs lean on questionnaires and annual reviews. Those tools tell you what a vendor says about its controls. They don’t show you what access that vendor holds in your environment today, or what happens when its credentials end up in the wrong hands.

This incident is a supply chain attack in practice. The weak point sat upstream and the impact landed downstream. MSPs sit in the middle of that chain, so one tool with standing permissions can touch every client at once.

5 Steps MSPs Should Take Now to Reduce Vendor Risk

1. Hunt in every client tenant

Start with Entra ID sign-in logs. Look for service principal activity from unexpected IP addresses, including 144.172.64.128, .99 and .60. Then widen the search to new app credentials, role assignments, consent grants, policy changes and mailbox forwarding rules. Quiet configuration changes are easy to overlook, so the review should cover what was changed as well as who signed in. Run it for every client, including those who don’t use ConnectWise backup. The same hunt tends to surface other integrations nobody has looked at in a while.

2. Inventory and right-size third-party app permissions

List every enterprise app in each tenant along with its Graph permissions. Most MSPs find integrations nobody remembers approving. Remove what is unused. For the rest, scope permissions to what the app actually needs. A backup tool needs to read and restore data. It rarely needs the ability to change roles or add credentials to other apps. Record an owner for each integration so someone is accountable when it comes up for review.

3. Lock down workload identities

Service principals don’t use MFA, so network and behavior controls carry more weight. Use Conditional Access for workload identities to restrict them to known IP ranges. A token request from an unfamiliar hosting provider is the kind of event this control is built to stop. Confirm licensing requirements before you roll it out. Then set alerts for any app that is added to a privileged role or gains new secrets. A five-minute escalation leaves no room for a weekly review, so those alerts need to reach someone who can act on them.

4. Don’t rely on a single backup path

Keep an independent, immutable copy of critical Microsoft 365 data, stored outside the platform that handles your primary backups. This incident left partners without backups or restores for an open-ended period. Immutability matters because a copy that can be altered or deleted with the same credentials isn’t much of a safety net. Test restores on a schedule so the second path is proven before you need it.

5. Formalize vendor risk management

Risk-rank vendors by the access they hold, not by contract size. A small tool with tenant-wide permissions can matter more than a large vendor with none. Require breach notification terms and incident response commitments in contracts, and reassess high-risk vendors on a set schedule. Ask how each vendor protects its own credentials and certificates, and how quickly it would tell you about an exposure. Those answers should shape whether a vendor keeps the access it has.

How Compass IT Compliance Can Help

Incidents like this are why we treat vendor oversight as an ongoing program instead of a once-a-year questionnaire. Our Vendor Management services cover policy development, program implementation and vendor IT risk assessments. That gives you a way to risk-rank vendors, set review schedules, standardize due diligence for new providers and map controls and remediation for each one. Paired with our Risk & Business Resiliency services and Virtual CISO support, it gives MSPs and their clients a structure that holds up when a vendor has a bad week.

Contact us to assess your third-party risk before the next vendor incident becomes yours.