ConnectWise Supply Chain Attack: What Happened and UK Lessons

What happened in the ConnectWise supply chain attack?

The ConnectWise supply chain attack involved unauthorised access to application credentials associated with Cloud Backup, formerly SkyKick. ConnectWise published its initial advisory on 16 October 2026. It disabled affected application identities and suspended Cloud Backup, with connected SaaS Security and Cloud Management services also suspended.

The ConnectWise Trust Center advisory is the primary source for containment and restoration instructions. Its 25 October update targeted phased partner onboarding for 26 October, subject to validation, with backup restoration access intended first. That was a target, not confirmation that every service had resumed.

This guide concerns the October 2026 Cloud Backup incident. The earlier ScreenConnect security event is a separate incident and should not be used as evidence about this attack's entry point or impact.

Why is this a software supply chain security incident?

A supply chain incident can reach a business through software or a provider it already trusts. Here, the relevant relationship was a cloud application's existing access to customer environments. This illustrates why supplier assessment must cover permissions and identities as well as procurement questionnaires.

Consider a hypothetical backup integration authorised to read business information. Its legitimate job requires access, but the same permission becomes a risk if someone else gains control of its authentication material. A familiar application name does not make every action performed under that identity legitimate.

For business owners, the useful question is: which external services can reach our information, and how would we revoke that access? Managed IT support should include ownership of those relationships, a record of approved integrations and a route for urgent supplier notices.

Who has Microsoft linked to the attack, and what remains unknown?

In its 21 October research, Microsoft Threat Intelligence attributed the compromise to Storm-0940, a China state-aligned actor. Microsoft described use of the ARTEX agentic AI framework and observed follow-on activity in multiple customer environments, including reconnaissance, application credential changes and privilege-related changes.

Microsoft cautioned that an affected application or successful authentication alone does not establish customer data access or exfiltration. That distinction matters: targeted tenants, successful sign-ins and confirmed data theft are different measures. The complete customer impact and the precise initial credential-theft mechanism should not be inferred from headline counts.

For your organisation, use an evidence ladder. First establish whether an affected integration existed. Then establish whether it was used suspiciously, what permissions it held, what changes followed and whether information was accessed. Record unknowns separately. A clean answer at one level does not automatically settle every other question.

How can you check whether your Microsoft 365 environment needs investigation?

Ask the administrator responsible for Microsoft Entra ID to identify current and historical ConnectWise or SkyKick integrations using the application identifiers in the official guidance. Display names can change, so a name-only search is a weak basis for an all-clear.

What should your administrator record?

• The application ID and tenant-specific service principal object ID.
• The permissions granted, the consent history and the business owner.
• Whether the integration remains enabled, when it last ran and whether it was used previously.
• The log sources available, their retention periods and any visibility gaps.

Give the investigation a named owner and a deadline for an initial assessment. If several suppliers manage different parts of your tenant, decide who will bring their findings together. Otherwise, everyone can assume that someone else checked the cloud identities.

Our Microsoft 365 support services provide a relevant starting point for reviewing tenant configuration and access responsibilities. The first deliverable should be a documented exposure assessment, rather than a general assurance that Microsoft 365 is working normally.

What should you do first if a trusted application may be compromised?

Contain the suspected access, preserve evidence and investigate related changes. These activities need coordination: waiting for a perfect evidence export can prolong exposure, while deleting everything immediately can remove useful context.

Microsoft's incident guidance recommends keeping affected connections disabled, preserving evidence before deletion, reviewing service principal sign-ins and investigating unexpected credential or privilege changes. Follow the live guidance for the affected tenant rather than applying a generic reset to every account.

Bring in managed security services where the investigation exceeds your team's capacity. Agree who can approve containment outside office hours and how urgent findings reach business leadership.

Why does multi-factor authentication not cover every application identity?

Multi-factor authentication protects supported user sign-in flows. A background integration may authenticate using a certificate or application secret without an employee entering a password or approving a prompt. Protecting people with MFA remains essential, but it does not replace controls for these non-human identities.

Review which applications can read data, write configuration or grant access. Apply the smallest permission set that supports the actual business function, and assign an accountable owner to each integration. Remove unused connections after checking dependencies and preserving records.

A regular cyber security audit should examine these identities alongside administrator accounts and devices. Ask for findings that identify the permission, its business justification, the risk and the person responsible for fixing it. A list of settings without ownership rarely produces lasting improvement.

How can you improve detection across cloud services and devices?

Monitoring needs to distinguish an application's expected behaviour from unusual activity under the same identity. Start by documenting normal source infrastructure, operating times and administrative changes. Use that baseline to prioritise anomalies for investigation, while allowing for legitimate vendor changes.

Review sign-ins together with directory changes and resource activity. A single successful authentication is less informative than a sequence that includes a new credential, expanded permissions and unexpected information access. Retain enough context to explain that sequence after an alert.

Managed EDR supports endpoint detection and response, but endpoint monitoring alone does not provide complete Microsoft 365 application visibility. Clarify which service covers cloud identities, who investigates alerts and whether responders have the permissions they need.

Test the escalation process with a harmless exercise. Present a simulated unexpected application credential addition and ask the team to explain how it would be triaged, who would own it and when the business would hear about it.

How should you protect business continuity when a backup supplier is disrupted?

Backup security and backup availability are separate questions. A provider can preserve stored archives while customers temporarily lose access to restoration capabilities. Your continuity plan needs to address both the integrity of information and the practical ability to recover it when needed.

For each critical system, record the last verified successful backup, the maximum acceptable data loss and the time the business can tolerate without the service. Check these against a demonstrated restore, not just a green dashboard. Note any reliance on the same identity provider or management portal.

Work with your managed cloud services team to assess recovery dependencies. Where proportionate, evaluate an additional recovery route with separate access controls. Any temporary workaround needs security review, a named owner and an expiry date so that emergency permissions do not become permanent.

During restoration, validate a small sample before broad reconnection. Confirm that backups resume, restored information is usable and security monitoring still receives the expected events.

What should UK businesses ask their IT provider after this incident?

Ask for specific evidence about your environment and the tools used to support it. A reassuring statement about the provider's overall security cannot substitute for a tenant-level assessment.

• Do you use, or have you previously used, the affected integrations for us?
• Which checks have you completed, and what period do the available logs cover?
• What remains uncertain, and who is responsible for resolving it?
• Who can disable supplier access and approve safe reconnection?
• How will you maintain protection and recovery capability during disruption?

The NCSC supply chain security guidance groups its principles around understanding risk, establishing control, checking arrangements and continuous improvement. Use that structure to turn the conversation into an ongoing review rather than a one-off questionnaire.

If you use outsourced IT support, agree the boundary between your responsibilities, your provider's responsibilities and the software vendor's responsibilities. Include incident communication and access removal in that agreement.

What are the main security lessons for UK organisations?

The first lesson is to treat third-party application access as part of your own security perimeter. Buying a reputable service does not remove the need to understand its permissions, monitor its use and plan for its failure.

The second is to connect technical ownership with business decisions. Someone must be able to explain what a connection does, what stopping it would interrupt and when reconnection is justified. Include these dependencies in IT infrastructure management records, even when the underlying service sits in the cloud.

The third is to maintain basic controls while improving cloud identity governance. Cyber Essentials provides a useful baseline for core protections; it should sit alongside supplier oversight, recovery exercises and application permission reviews. Certification alone cannot establish that a specific incident has been investigated.

For a practical next step, review your five most privileged integrations this week. Give each an owner, confirm its access, check the available logs and document how to stop it safely. Then exercise one recovery scenario. These are concrete improvements you can measure without waiting for the final incident report.

What else do businesses need to know?