What happened
ConnectWise said on October 28 that it had begun a phased restoration of its Cloud Backup service, formerly known as SkyKick. The first phase covers Microsoft 365 backup and restore operations. The company is bringing that capability back through a new application called ConnectWise Cloud Backup for M365, which it describes as security-hardened.
The restoration follows an incident disclosed on October 16. ConnectWise said it was investigating attempted unauthorized access associated with the Cloud Backup environment and had initiated incident-response procedures. At that point, it said there was no indication that partner backup data had been accessed. The company later said it had identified unauthorized access to application identities associated with Cloud Backup.
On October 17, ConnectWise suspended Cloud Backup application access as a protective measure, warning that backup service would be interrupted. It subsequently said it had revoked certificates used for affected application connections across all users. According to the status update, this removed ConnectWise access through those connections, and shared credentials previously used for Cloud Backup were no longer valid. The company said existing backup archives remained encrypted and isolated, while access and restoration were unavailable during the interruption.
The new Microsoft 365 restoration flow is not simply a service switch being made by ConnectWise in the background. Partners must reset passwords, configure multifactor authentication, and re-authorize each Microsoft 365 tenant using the replacement application before backup and restore can resume. ConnectWise said other Cloud Backup features would return in phases over the following days. An October 29 advisory added password-reset troubleshooting. A report summarized in the supplied material said early partners had tested restores and that the service was back up, citing ConnectWise's CTO.
The source does not present the restoration as complete. It describes a phased return centered first on Microsoft 365 and makes tenant re-authorization a prerequisite for affected partners. The status history also distinguishes the availability of encrypted archives from the availability of the service needed to access or restore them. In practice, preservation of stored data did not remove the disruption created by disabling the application identities and connection credentials used to operate the backup service.
What the archive adds
This is a new fact on a known story. Our earlier Field Note reported that ConnectWise had missed its October 26 target for Cloud Backup restore onboarding: ConnectWise misses October 26 Cloud Backup restore onboarding target. The October 28 update supplies the next operational milestone: a phased Microsoft 365 restoration path, plus the replacement-app and re-authorization requirements.
Trend signal
This supports the narrow operational reading of Agent security moves to runtime boundaries. ConnectWise's response was not a request for users to behave differently in a prompt or interface. It revoked certificates, invalidated shared credentials, required MFA, and moved access to a new application. The evidence is about cloud-backup identities rather than autonomous agents, but it illustrates why enforceable identity and execution boundaries matter when a service acts across customer environments.
Why now
The timing is explained by the earlier containment action. ConnectWise suspended application access after identifying unauthorized access to Cloud Backup application identities, then revoked affected connection certificates. The October 28 restoration is therefore a controlled return from that shutdown, with a new application and fresh authorization steps rather than a simple reversal of the prior access configuration.
Connections to other events
The direct connection is the previously reported missed October 26 restore-onboarding target. That report established that recovery had not met the stated milestone; this update establishes that Microsoft 365 backup and restore onboarding had begun two days later. Both events concern recovery from the same Cloud Backup interruption, not a separate feature launch or a general product upgrade.
Why it matters
Teams often treat backup automation as an invisible control plane: authorize it once, then expect it to run and restore when needed. This incident shows the operational consequence when the identity layer behind that automation must be contained. Data may remain encrypted and isolated while the ability to back up or restore is still unavailable.
For builders of AI-enabled or conventional automation, the useful lesson is not that MFA alone prevents incidents. It is that recovery plans need to include credential rotation, tenant-by-tenant reauthorization, replacement integration paths, and a way to verify real recovery work. If a system has access across many customer tenants, its identity design determines both blast radius and the amount of manual work required to return safely.
What happens next
- Additional Cloud Backup features move into later restoration phases. (3 months, 70%). Watch for: a ConnectWise status update naming returned features and eligibility.
- Partners complete Microsoft 365 re-authorization in uneven waves. (3 months, 75%). Watch for: revised onboarding guidance or support advisories about tenant authorization.
Limits and uncertainty
The supplied status material establishes that phased Microsoft 365 restoration began and lists the required partner actions. It does not establish how many tenants had completed re-authorization, how many restores succeeded, a final restoration date, or whether all Cloud Backup functions had returned. ConnectWise said it had no evidence that encrypted backup archives had been accessed, but that is not equivalent to an independently verified account of the incident's full scope. The material also does not provide technical details of the new application's security architecture, permissions, or review process.
Skill to build now
Map the non-human identities behind one production automation this week. Record which certificates, service principals, shared credentials, and tenant permissions it needs; identify who can revoke them; and test what happens to service delivery after revocation. Then write a re-entry runbook that includes credential replacement, MFA where applicable, explicit tenant reauthorization, and a verified end-to-end task such as a restore or export. A backup or agent system is not recovered merely because its stored data remains intact.
Reader takeaway
ConnectWise's restoration is a reminder that service recovery after an identity incident is an access migration, not only an uptime event. Microsoft 365 backup and restore are returning through a new application, but partners must re-establish trust tenant by tenant. Design automation so that this work is visible, repeatable, and testable before an incident forces it.
Open question
How quickly can ConnectWise complete tenant re-authorization and restore the remaining Cloud Backup capabilities without recreating the access model that required containment?