What happened
ConnectWise cut off customer access to its Cloud Backup service, previously known as SkyKick Cloud Backup, after discovering unauthorized access to application identities inside that environment. The service backs up Microsoft 365 and Google Workspace data for managed service providers and their clients, and it reaches that data through permissions granted in Microsoft Entra ID.
The mechanism matters more than the vendor name. A service principal represents the backup application inside each customer tenant and acts with whatever permissions the customer approved. According to investigators quoted by BleepingComputer, the attacker authenticated as the backup application using its secret, and inherited the access customers had already granted. No phishing campaign was needed. The trusted software simply signed in.
Huntress reported at least 162 compromised tenants in its own visibility, and Microsoft confirmed unauthorized authentication attempts from a single address on October 15. Sign-in activity appears to have been scripted, with automated tooling recorded across October 13 and 14. One administrator reported an alert from Microsoft Privileged Identity Management showing a SkyKick service principal assigning itself the Exchange Administrator role, from an application the tenant had not used in years.
ConnectWise said it has no indicators that partner backup data was taken and that the stored archive is unaffected, while it investigates and restores service.
Why this is a GRC story
Consent outlives the relationship. The role assignment that enabled this access was granted years earlier and never revisited. Application permissions are a register entry with a date, an owner and a purpose, and most third party registers do not list them at all. If your inventory records the vendor but not the application identity and its scopes, you cannot answer the first question an incident like this raises.
High privilege delegated to a backup tool is normal and dangerous. Backup products need broad read access, and often the ability to write or restore, which makes them a standing target. That is not a reason to remove them. It is a reason to monitor role assignments to service principals with the same attention given to human administrators, and to alert on privilege escalation by an application nobody has touched in a year.
Third party incidents arrive as a vendor statement, not a breach report. Customers learned about this from vendor advisories, a security platform's telemetry and each other. Contract clauses on notification timelines and evidence sharing are the only thing that shortens that gap, and they are usually the clauses nobody reads until they are needed.
What to watch
Watch for the scope of notification and for whether regulators treat this as a personal data breach in the jurisdictions where affected tenants operate. For practitioners, the immediate work is unglamorous: search Entra ID for service principals with elevated roles, match them to a current business need, and remove the ones tied to tools you no longer use. Then check whether your monitoring would have flagged an application granting itself Exchange Administrator. In this case somebody did get that alert, which is the only reason the pattern became visible as quickly as it did.
Attribution: Analysis based on BleepingComputer and related public reporting. This article is original commentary, not a repost of the source material.