ConnectWise Backup: Evidence Before Reconnection

ConnectWise's Cloud Backup incident requires two separate conversations: when the provider can restore service, and what your administrator has established about your Microsoft 365 environment. Do not treat progress on the first as an answer to the second.

ConnectWise first published its advisory on October 16, 2026. In the latest Cloud Backup update retrieved for this article, dated October 23, 2026 at 14:00 UTC, it reported that restoration testing and security validation were continuing. Its instruction remained to keep affected application connections disabled until service-specific instructions were provided. These are the vendor's reported findings and directions, not confirmation that any particular customer environment is safe.

For business owners, the practical next step is to request a documented handoff from the administrator responsible for the affected environment. The checklist below is an editorial recommendation based on that guidance, not an official ConnectWise clearance form.

Read the restoration update as a conditional timeline

ConnectWise says it identified unauthorized access to application credentials associated with Cloud Backup, formerly SkyKick. Its October 23 update anticipated completing testing and security validation by the end of the weekend. Successful completion would allow capabilities to return in phases.

The proposed sequence matters. ConnectWise anticipated enabling access to restore existing backups early the following week, after successful testing and validation. Full service re-enrollment would follow, supported by instructions, tutorials and webinars. Neither forecast was a statement that those capabilities were already available in the retrieved update.

Ask your provider to distinguish three things in its next report:

• What ConnectWise has actually confirmed as available.
• What remains an anticipated milestone.
• Which formal instructions apply to the service your business uses.

Record the advisory update being relied on. Avoid approving reconnection against a general announcement that restoration has begun. The vendor explicitly requires affected connections to remain disabled until instructions apply to the relevant service.

Keep archive status separate from tenant findings

ConnectWise reported that existing backup archives remained encrypted, isolated and preserved, with no indication of compromise. It also said investigation and monitoring continued. That wording should remain attributed to the vendor; it is not a guarantee covering every customer environment.

The distinction is explicit in the advisory. In its October 21 update, ConnectWise said that containing affected connections and restoring services did not remove unauthorized access that might already have been established inside individual customer tenants. It separately warned that its archive findings did not establish whether individual Microsoft 365 environments were affected. Both points appear in the Trust Center advisory.

Request separate answers about archive availability and tenant investigation. For the latter, ask what was examined, what was found, what was remediated and what remains unresolved. Do not accept a statement about preserved backups as a substitute for those answers.

This is also why this article does not offer a software version to install as the complete remedy. The cited Cloud Backup updates describe an application-credential incident and tenant review, not a versioned patch advisory with a specified CVE, affected release range, fixed version or CVSS score.

Assign the tenant review to a responsible administrator

ConnectWise's guidance covers partners' own environments, managed customer tenants and legacy SkyKick integrations. Its October 21 update also asks resellers, distributors and marketplace partners to ensure that guidance reaches the responsible customer administrators. Buying through an intermediary does not replace that customer-level review.

Ask your provider to identify who owns the investigation for your environment. Where different teams manage backups and Microsoft 365, request one coordinated report rather than assuming either team's service update covers the other's work.

A useful review request should specify:

• The affected service and environment within the agreed review scope.
• Whether relevant legacy backup integrations were included.
• The administrator responsible for investigation and remediation.
• The evidence reviewed and the limitations of that review.
• Outstanding questions requiring specialist or vendor assistance.

Treat these as requested reporting fields, not proof that an investigation has happened. A named owner should explain the findings and limitations before you consider the review complete.

Ask for application-access evidence, not only user logins

ConnectWise's technical investigation webinar page identifies the review areas: Microsoft Entra ID sign-in and audit logs, application registrations, credentials and permissions, including legacy backup integrations. Use those categories to structure your evidence request without attempting to run an investigation from a business-owner checklist.

Microsoft's documentation distinguishes interactive user sign-ins, non-interactive user sign-ins, service principal sign-ins and managed identity sign-ins. It also notes that the legacy sign-in logs experience includes only interactive user sign-ins. Ask which types were examined; a report limited to human logins should not be presented as the complete application-access review described by ConnectWise.

For an authorized administrator, Microsoft's documented read-only starting point is to sign into the Entra admin center with at least the Reports Reader role and navigate to Entra ID > Monitoring & health > Sign-in logs. This is a way to view evidence, not permission or a procedure to remediate the incident. See Microsoft's sign-in log documentation.

Request a concise summary for each vendor-listed review area. For application registrations, credentials and permissions, ask what changes were examined and whether anything remains unexplained. For logs, request the reviewed period and any evidence gaps. Microsoft describes audit logs as information about tenant changes; ask the administrator to explain how that evidence informed the conclusion rather than supplying only a sign-in summary.

Keep sensitive evidence in the authorized investigation process. The business-facing report should summarize findings without copying credential values or raw identity details into a broadly shared document.

Make reconnection a documented decision

The vendor's reconnection instruction and the tenant investigation answer different questions. Keep both visible in the decision record. ConnectWise's advisory requires service-specific instructions while continuing to emphasize individual environment review.

Before approving the work, request:

1. Applicable vendor guidance: the current update and the instructions covering the affected service.
2. Investigation summary: the administrator's findings, remediation status and unresolved limitations.
3. Execution ownership: who will follow the official re-enrollment procedure and report its outcome.
4. Verification evidence: how the administrator will demonstrate successful operation using the vendor's instructions.

Do not turn this into a generic promise that the tenant is clean. Require a bounded conclusion explaining what the evidence supports. If instructions have not been issued for your service, leave reconnection pending. If the investigation has unresolved concerns, escalate them rather than using a restoration announcement to close the incident.

Close recovery only after operational verification

ConnectWise says its phased re-enrollment materials will help partners re-establish service and verify successful operation. Ask your provider to retain that verification result, not merely record that re-enrollment was attempted. Also request a clear statement of what is available and what still awaits restoration, consistent with the vendor's phased approach.

Apply the same separation of responsibilities when reviewing other connected workflows through business automation planning: identify the service owner, the administrator responsible for permissions and the person accepting operational results. This is a process recommendation, not a claim that other integrations are affected by this incident.