The ConnectWise Cloud Backup Incident: What MSPs Must Learn About Permissions and Supply-Chain Risk

When a backup integration becomes an identity risk

Managed service providers rely on integrations to deliver consistent backup, security, and administration across many customers. These integrations save time, but they also create an obligation: MSPs must understand what each vendor application can access and what happens if the application identity is compromised.

The incident involving ConnectWise Cloud Backup, formerly SkyKick, is a timely example. On October 21, ConnectWise reported unauthorized access to application credentials associated with the service and said it had begun restoring services in controlled phases after containment and security validation. The company stated that stored backup archives remained encrypted, isolated, and preserved, with no indication those archives had been compromised. That statement does not establish whether individual customers' live Microsoft 365 environments were affected.

The distinction matters. Backup archive integrity, Microsoft 365 tenant security, and the ability to perform a restore are three different questions. A service can have preserved backup data while access to the service is temporarily interrupted and while customer tenants still require investigation.

What researchers observed

On October 15, investigators at Huntress and Todyl observed unauthorized authentication to Microsoft 365 using the identity of the legitimate ConnectWise Cloud Backup application. The app already held consented permissions in customer environments; the attacker did not need to sign in as an ordinary employee to use that application-level access.

Huntress had confirmed unauthorized application sign-ins in 162 tenants as of October 16 at 19:00 UTC. That was a point-in-time research count, not a final number of affected customers. Huntress also documented post-access changes involving another ConnectWise Cloud Management identity in a small number of environments, including the addition of credentials to other applications. In contrast, Todyl reported that it had not seen those directory changes in the tenants it examined. These findings describe different observed samples and should not be treated as universal outcomes.

The central lesson is not a particular tenant count. When a privileged multitenant application is trusted by many customers, a credential problem at the vendor can create exposure across multiple organizations.

Why application permissions matter more than a familiar vendor name

Backup tools often need substantial access to mailboxes, OneDrive, SharePoint, and other workloads to protect customer data. In Microsoft Entra ID, an application's service principal represents that integration in a customer tenant. Application permissions may allow access without an interactive user session.

That is why traditional advice such as “reset all user passwords” or “enable MFA for employees” is important but not sufficient for application-identity incidents. A workload can authenticate through its own credential, and its effective access depends on the permissions administrators granted earlier.

For MSPs, an application access review should answer:

• Which third-party and internally developed applications exist in each tenant?
• Who owns each integration, and which workloads does it need to access?
• Which application and delegated permissions were granted, and by whom?
• Are privileged roles, secrets, certificates, owners, and consent grants reviewed?
• How will the MSP detect an unusual service-principal sign-in or credential change?
• What happens to customer protection if a vendor connection must be disabled?

The cascading-risk problem for MSPs and MSSPs

An MSP might manage dozens or hundreds of independent tenants, but its operating model may still depend on a small number of common platforms, vendor applications, or management identities. That is a concentration of operational and security risk.

If an attacker gains access through a shared integration, the blast radius can extend beyond a single customer. An organization may also be affected by a vendor-led shutdown designed to contain an incident, even if its own tenant has no evidence of compromise.

MSPs should distinguish tenant isolation from shared control-plane dependencies. Separate customer tenants are valuable boundaries, but they do not remove the risks created by a common vendor identity, overprivileged management account, or unavailable central service.

For MSSPs, the event adds another requirement: security monitoring must cover service principals, permission changes, and cloud application identities—not only endpoints and human logins.

A practical response checklist for managed service providers

MSPs using affected ConnectWise or legacy SkyKick services should follow the vendor's current technical investigation and remediation guide, coordinate with the customer's authorized administrator and incident response team, and avoid broad changes without preserving evidence. The following is an editorial checklist, not a replacement for the vendor's incident-specific instructions.

1. Inventory every tenant. Include the MSP's own Microsoft 365 tenant, each managed customer tenant, and dormant legacy integrations. Match applications by Application ID rather than display name alone.
2. Verify containment. Confirm that the affected enterprise applications are disabled as instructed, document their local status, and do not re-enable them until ConnectWise issues formal reconnection guidance.
3. Preserve evidence. Export available Entra sign-in and audit logs, Microsoft 365 audit records, and relevant security alerts. Record collection times and missing retention periods.
4. Inspect workload identities. Review service-principal sign-ins, application secrets and certificates, newly granted permissions, owners, privileged roles, and consent changes. Disabling the original app does not automatically remove attacker-added access elsewhere.
5. Check for downstream activity. Investigate suspicious mailbox forwarding, inbox rules, delegation, and relevant SharePoint, OneDrive, and Teams activity using the logs available to the tenant.
6. Measure the protection gap. Determine the last successful backup and which restores are currently possible. Document the operational impact and discuss approved contingency measures with the customer.
7. Communicate per tenant. Distinguish confirmed findings, indicators that require investigation, and areas with insufficient logs. Assign an owner to each customer's remediation and follow-up.

ConnectWise's official guidance identifies the Cloud Backup application ID as 506e08f9-6e9a-4da4-942b-a099a03644ae and includes additional Cloud Management application IDs and investigation steps. A suspicious sign-in or IP match warrants investigation, but it is not by itself proof that data was exfiltrated or the tenant was compromised.

Backup availability is also a business continuity issue

During containment, ConnectWise suspended affected services, interrupting scheduled jobs, archive access, and restores. By October 21, the vendor had announced a phased restoration process, rather than claiming every capability was immediately available.

For MSP customers, this raises questions beyond cybersecurity: How old is the most recent recovery point? What are the contracted recovery time and recovery point objectives? Is there another approved recovery path if the primary backup control plane is unavailable? Who communicates these limitations to the customer?

It is not realistic to assume every business needs multiple full backup vendors. But each MSP should document critical dependencies and evaluate redundancy, recovery options, and business impact according to customer risk and contractual commitments.

Seven preventive measures worth reviewing now

• Least privilege: grant only permissions required for each workload, and revisit permissions as integrations change.
• Application governance: maintain an inventory of enterprise apps, service principals, owners, credentials, and consent grants.
• Customer segmentation: limit cross-tenant privilege and avoid unnecessary shared administrative access.
• Monitoring and detection: collect service-principal sign-ins and alerts for unexpected locations, credentials, grants, and privilege changes.
• Incident-ready logging: understand audit retention and ensure critical evidence is preserved promptly.
• Recovery validation: test restores and document what remains possible if a cloud management platform is unavailable.
• Vendor risk management: review third-party access, incident notification channels, restoration processes, and contractual responsibilities.

These controls do not eliminate supply-chain risk. They help MSPs recognize it earlier, reduce the blast radius, and respond with better evidence and less guesswork.

What this means for the MSP business model

The incident is a reminder that managed backup is not just a storage service. Customers depend on their MSP to know whether backup jobs are succeeding, whether access is appropriately protected, whether recovery remains available, and how incidents will be handled.

For MSPs and MSSPs, a stronger service offering combines backup operations, identity governance, monitoring, tested recovery procedures, clear SLAs, and transparent incident communications. A dashboard marked “green” is not a substitute for a demonstrable recovery capability.

SafetyOnCloud's perspective is that a backup strategy should be evaluated by its ability to support recovery—not merely by the existence of stored copies. Providers should assess their own configurations, platform dependencies, and customer requirements before promising specific controls or recovery times.

Conclusion: trust the integration, but verify its boundaries

The ConnectWise Cloud Backup incident is not proof that all backup providers or all customer tenants were compromised. It is evidence that application identities, third-party permissions, and shared service dependencies deserve the same attention as endpoints, passwords, and backup retention.

For every MSP, the next useful step is a tenant-by-tenant review: inventory integrations, verify permissions, preserve the right logs, confirm current recovery points, and rehearse the response to a vendor service interruption.

For an MSP, backup security is not only about protecting a customer's data. It is also about controlling who can reach it—and proving how it can be recovered.