ConnectWise Suspends Cloud Backup After Microsoft 365 Tenant Compromise: What IT Teams Should Do Now

The incident involves ConnectWise Cloud Backup, formerly sold as SkyKick backup, and related Cloud Management apps that hold delegated permissions in Microsoft Entra ID. According to The Hacker News, ConnectWise identified the problem on October 14 and took action on Saturday, October 17. BleepingComputer reported that Microsoft described the activity as an active supply chain attack.

This report summarizes what is confirmed, what is still unknown, and what IT teams and managed service providers should check. It is based on the two reports above and Microsoft documentation; the vendor's own advisory page was not accessible to our tools, so treat details as reported by the press. Related coverage: our guide to backup and archiving software.

What Happened and When

Attackers obtained access to application identities in the ConnectWise Cloud Backup environment and used them to request Microsoft Entra ID tokens, reaching customer Microsoft 365 tenants without stealing user passwords. ConnectWise disabled seven identities on October 17, 2026 and suspended Cloud Backup.

• October 13 to 15: Huntress tied scripted sign-in activity from one IP address to these dates, with manual activity on October 15.
• October 14: ConnectWise says it identified the issue through monitoring.
• October 17: ConnectWise disabled seven application identities, one for Cloud Backup and six for Cloud Management, and suspended Cloud Backup. SaaS Security and Cloud Management were also taken offline as a precaution.
• October 18: an update said scheduled backups were not running and restores remained unavailable.

ConnectWise says its encrypted backup archives are isolated and that it has no indication they were breached. Those statements do not cover live Microsoft 365 data, and the company has said disabling its side of the connections does not undo changes already made inside customer tenants.

How Big Is the Impact

Huntress reported at least 162 compromised tenants in its monitored environment as of October 17, while the full victim count and extent of data theft remain unclear. Different analysts are seeing different slices, so scope should be established tenant by tenant.

Huntress also saw roughly 50 monitored tenants where service principals assigned themselves directory roles, mostly Exchange Administrator. In one tenant, a Cloud Management Teams app was granted Global Administrator and credentials were added to other applications. Todyl, analyzing nine intrusions, reported sign-in activity without evidence of account creation or persistence through the backup app. These findings differ, which is why local log review matters.

How the attackers first obtained the credentials has not been disclosed, and it is not confirmed that a product vulnerability was involved.

Why It Matters for B2B SaaS Buyers

The incident shows that a backup vendor's app identity can be as sensitive as an administrator account. Because the attackers authenticated as an application, multi-factor authentication on human users did not stop them, and revoking user sessions does not end app-based access.

• Third-party apps with broad Graph permissions such as directory write access create a concentrated risk.
• MSPs and their clients share exposure, because one vendor identity can touch many tenants.
• Backup outages compound the problem: the service meant to help you recover is itself unavailable.

If you rely on a vendor for tenant backup, review our Backup & Archiving Software category and consider keeping an independent copy of critical mailboxes and files. MSPs should also review their RMM tooling and vendor access paths.

What IT Teams and MSPs Should Do Now

Start by preserving logs, then confirm the status of the affected ConnectWise apps in each tenant, review service principal sign-ins and hunt for new credentials, role assignments and mail rules. Do not re-enable the apps until ConnectWise issues recovery instructions.

• Export Entra ID sign-in and audit logs now; default retention can be short.
• Review service principal sign-ins for the listed ConnectWise app IDs and the reported attacker IP 144.172.64[.]128, using the method in Microsoft documentation.
• Check for client secrets or certificates added to applications since October 13, plus new apps and new consent grants.
• Audit directory roles, especially Exchange Administrator and Global Administrator held by service principals.
• Review mailbox forwarding, inbox and transport rules, and delegated access.
• Look for dormant connections; older tenants may list the apps as SkyKick Cloud Manager.
• Leave the affected apps disabled and do not delete them until you have preserved evidence.

Longer term, restrict who can add credentials to apps, limit client secret lifetimes, apply Conditional Access to workload identities and monitor risky service principals. The NIST incident handling guide (SP 800-61) is a useful framework for the response. The vendor is ConnectWise; check its trust center for official updates.

What We Do Not Yet Know

Several key facts are still unconfirmed, including how the credentials were obtained, the final list of affected tenants and whether data was exfiltrated. Treat any single report's numbers as provisional until ConnectWise and Microsoft publish final findings.

• Initial access method for the vendor credentials.
• Total number of affected tenants and customers.
• Whether other vendor identities beyond the seven disabled ones were used.
• When Cloud Backup restore capability will return.

Frequently Asked Questions

Is my Microsoft 365 data safe if I use ConnectWise Cloud Backup?
ConnectWise says its encrypted backup archives are isolated and it has no evidence they were breached, but that does not cover your live Microsoft 365 tenant. Review your own sign-in and audit logs to check for unauthorized access.

Should I delete the ConnectWise or SkyKick apps from my tenant?
Keep them disabled but do not delete them until you have preserved logs and evidence. Deleting an app can remove information you need for investigation. Wait for official recovery guidance before re-enabling anything.

Does multi-factor authentication protect against this attack?
Not directly. The attackers authenticated as an application using its credential, so user MFA did not apply. Limit app permissions, control client secrets and apply workload identity protections such as Conditional Access.