A supplier says its cloud backup service is coming back. Your first question is whether protection has resumed. Your second should be whether the access used during the incident has been fully investigated. A successful reconnection answers neither question on its own.
That distinction matters for Malaysian SMEs reviewing the October ConnectWise Cloud Backup incident, including businesses whose Microsoft 365 backup is arranged through a reseller or MSP. This article does not establish that AXO, its customers or your tenant use the affected service.
What the official updates actually confirm
ConnectWise’s 28 October 2026 update at 16:00 UTC confirms unauthorised access to application credentials associated with Cloud Backup, formerly SkyKick. It announces phased restoration, starting with Microsoft 365 backups and restores through a new application. The vendor instructs partners to re-authorise each tenant using “ConnectWise Cloud Backup for M365” and not re-enable previously disabled applications unless specifically directed.
Microsoft’s 21 October research assesses that Storm-0940 was responsible for the supply-chain compromise and describes use of the ARTEX AI framework to accelerate application abuse. Attribution is Microsoft’s assessment. Its report also makes an essential qualification: an affected application, or even a successful attacker authentication, does not by itself prove that customer data was accessed or exfiltrated.
These statements support urgent review. They do not justify telling every customer that their data was stolen, or declaring every tenant safe because the supplier has begun restoration.
Establish your actual exposure before changing access
Ask your provider to identify whether your tenant had the affected integration, which application identifiers were involved and what actions were taken. Match identifiers to the vendor’s guidance rather than relying only on a familiar display name. Record the tenant, responsible administrator, investigation owner and business contact in one incident record.
Hypothetical example: a distributor buys a Microsoft 365 backup package from a local reseller but does not know the underlying platform. The reseller confirms that the affected integration was present, provides its application identifiers and names the administrator reviewing tenant evidence. This is an exposure finding, not yet a finding of data theft.
If the service was never used, record how that was established. If the position remains uncertain, keep the question open with an owner and a deadline. A supplier’s unanswered email should not become an assumed “not affected” status.
Review application activity as well as staff logins
Staff MFA is not a substitute for checking application identities. Microsoft’s service principal sign-in documentation explains that these authentications do not involve a user: an application can present its own certificate or secret. Looking only at a director’s or administrator’s interactive sign-in history can therefore leave an important gap.
Have an authorised responder review the relevant service principal sign-ins, audit activity and available resource-access evidence. Microsoft’s incident research describes follow-on application credential and privilege changes that may establish persistence beyond the original application. Investigators should correlate suspicious changes with approved administrative work, rather than treating every automation event as malicious.
Preserve the evidence your tenant actually retains. Ask which log sources and dates were available, what was exported and what could not be reviewed because of retention or licensing limits. “Nothing suspicious found” has a different meaning when backed by complete evidence than when the required history is missing.
Keep containment and reconnection under change control
Use the vendor’s current instructions for the specific service and tenant. Do not follow an unsolicited email asking for broad administrator consent. Start from the official advisory and its linked restoration guidance, then have the designated administrator check the requested application and permissions.
Microsoft documents tenant-local application sign-in controls, including required administrative roles. These controls belong in an authorised containment plan. They are not a reason for an owner to disable unrelated enterprise applications without understanding the operational impact. Record each approved change and its verification result.
Separate the decision to reconnect from the decision to close the investigation. Give both a named approver. If additional unauthorised credentials or privileges are discovered, the responder needs to address those findings; replacing the original connection is not sufficient evidence of eradication.
Prove backup protection has resumed
ConnectWise explicitly states that re-authorisation alone does not confirm resumed backups. Its update requires verification of successful new snapshots once backup capabilities become available. It also describes a snapshot-history gap between the last completed backup before interruption and the first successful one afterwards.
Ask your MSP for the last successful backup before the interruption, the first successful backup after restoration and the workloads covered. Agree how any gap affects recovery expectations. Then perform an approved restore test using non-sensitive test content, with the result checked by the business owner. The restore evidence you request should establish usability, not just a green dashboard.
Close the incident only when exposure assessment, tenant investigation, approved reconnection and recovery validation each have an outcome or a documented unresolved limitation. To discuss your Microsoft 365 security and recovery priorities, contact AXO Technologies.
Sources and dates
Published 29 October 2026. Primary sources checked on 29 October 2026. Access dates are not publication dates. Restoration status and vendor guidance can change.
- ConnectWise Cloud Backup advisory — originally published 16 October 2026; latest update reviewed: 28 October 2026, 16:00 UTC.
- Microsoft: ARTEX-enabled supply-chain compromise research — published 21 October 2026.
- Microsoft: service principal sign-ins — documentation updated 17 March 2025; checked 29 October 2026.
- Microsoft: disable application sign-in — documentation updated 15 October 2026; checked 29 October 2026.