ConnectWise Backup Is Shut Down: Which Microsoft 365 Apps Should You Check?
Updated October 17, 2026. ConnectWise has interrupted Cloud Backup access during a security investigation. This guide explains what Microsoft 365 administrators and managed service providers should check. Follow the current vendor advisories before making changes.
Cloud Backup being shut down is not the same as finishing your tenant investigation. ConnectWise says it interrupted Cloud Backup access after identifying unauthorized access to application identities. It says the existing backup archive is unaffected by that interruption and will be accessible after restoration; it has not announced a restoration deadline in the checked notice. That is a statement about the vendor's backup archive, not proof that every customer's Microsoft 365 environment is safe.
Source: ConnectWise advisory, updated October 17 at 05:01 UTC
Service status, October 17 update at 05:11 UTC
Which Microsoft 365 applications should you check?
Huntress's October 17, 10:30 a.m. ET (14:30 UTC) update names additional Cloud Management applications. Its advice extends beyond the Backup integration. Do not confuse these distinct app identities merely because their names contain SkyKick.
- Cloud Backup: 506e08f9-6e9a-4da4-942b-a099a03644ae
- Cloud Management – MS Teams: 24205314-2b89-4e07-a2a4-579e898a5640
- Cloud Management – Exchange Online: b78f6a77-d4e5-46fb-87e5-d1648bd02519
- Cloud Management – SharePoint Online: b2b55f5b-7758-4719-8d8f-88ae172e6bdb
Huntress recommends disabling affected applications, not deleting them, reviewing other application credentials, and waiting for vendor confirmation before re-enabling. Its fuller list and investigation guidance remain the authoritative starting point:
Huntress guidance on unauthorized access via vendor credentials
Two separate questions for your response team
First: Is a named application still enabled in this tenant? Second: Did earlier activity leave unexpected roles or credentials elsewhere? A status-page recovery answers neither question on its own. Keep separate records for containment, investigation and backup continuity rather than marking the entire incident resolved after one change.
What the Microsoft control actually changes
Microsoft documents a tenant-local control: Enterprise apps > All applications > select the exact application > Properties > set “Enabled for users to sign-in?” to No > Save. An appropriately authorized administrator should use the documented prerequisites and preserve evidence before making changes. This disables that tenant's service principal; it is not a universal shutdown of every similarly named app in every customer tenant.
Microsoft documentation on disabling user sign-in in the portal
A short handoff checklist
For each tenant, record the exact app ID found, who approved the response, the time it was checked, the evidence retained, and the owner of the next review. Separately record the latest successful backup and which recovery requirement may be affected by the service interruption. Ask your provider to confirm retention and restore arrangements for your actual contract. Do not promise customers that a green status page alone closes the investigation.
Knowledge check — two practical distinctions
Containment Check: Two Practical Distinctions
Disabling one app does not clean up credentials added elsewhere. Microsoft's control acts on the selected tenant's service principal. Treat these as separate review steps, not a certificate that a tenant is safe.
Before you re-enable
Follow the current vendor and incident-response guidance, not a fixed waiting period from a news article. This page explains a checking workflow; it is not a forensic verdict on your environment.
