ConnectWise outlines a return to service. Customer tenants still need their own review
Backup restoration access is expected before full re-enrollment, subject to testing. Preserved archives do not establish that every Microsoft 365 connection is safe.
ConnectWise has outlined the order in which its interrupted Cloud Backup service should return: access to restore existing backups first, followed by phased re-enrollment into the full service. Its October 23 update, posted at 01:00 UTC, says testing and security validation are expected to finish by the end of the weekend. The company anticipates restoration access early next week, subject to those checks succeeding.
That is a recovery plan, not permission to reconnect today. ConnectWise continues to tell customers to keep affected application connections disabled until instructions apply to their particular service. Administrators have another job alongside waiting for those instructions: establishing what happened inside each connected Microsoft 365 environment.
The backup archive and the access path are different assets
ConnectWise says existing backup archives remain encrypted, isolated and preserved, with no indication of compromise. That is useful information about the stored copies. It does not settle whether an attacker used a compromised application identity to reach the live systems from which those copies were taken.
An integration can have permission to act without a person signing in each time. This is what makes unattended backup practical: the service needs a durable way to reach the data. The same relationship becomes dangerous when someone else gains control of the application's credentials. The user's own password need not be the key that opened the door.
Treating those questions separately prevents a reassuring statement about one asset from becoming an unsupported conclusion about another. It also helps divide responsibility: the provider can restore its service while the customer investigates changes in the customer's environment.
A trusted application can leave a second route behind
Microsoft's investigation attributes the campaign to Storm-0940 and describes abuse of application identities followed, in some environments, by Microsoft Graph and directory operations. Its defensive guidance includes reviewing service-principal sign-ins and unexpected credential or privilege changes. Successful authentication alone is not proof that data was stolen.
The reason to examine later changes is straightforward. Disabling the originally compromised connection closes that connection. It does not automatically remove another credential or permission an attacker may already have created. Recovery therefore needs a history of what the identity did, not only a current list of disabled integrations.
Wiz Research's separate observations describe sustained automated probing across software vendors. That supports concern about operational tempo; it does not turn every attempted login into a breach. Defenders still need to distinguish failed attempts, established access and subsequent actions.
Reconnection should finish a review, not start one
The practical sequence is to preserve relevant records, follow the provider's containment instructions, review the affected tenant and use the service-specific restoration process when it becomes available. Microsoft explicitly cautions against deleting enterprise applications as the first response, because configuration and evidence matter to the investigation.
This applies to organizations and service providers in Italy as well as elsewhere; it is an integration issue, not a country-specific consumer rollout. Our coverage of Railway's credential response examined a different incident with the same need to distinguish restored functionality from retired access.
The moment a backup button works again will be welcome. The stronger recovery milestone is being able to explain why the identities behind that button are the ones the organization intends to trust.
