ConnectWise M365 Breach 2026: What UK Buyers Must Do

What happened in the ConnectWise M365 breach 2026

ConnectWise shut down customer access to its Cloud Backup service at 05:01 UTC on 17 October 2026 after confirming unauthorised access to application identities — the "service principals" that let backup software read and write data inside a customer's Microsoft 365 tenant. Microsoft separately confirmed malicious activity, saying it had detected unauthorised authentication attempts from a single IP address on 15 October. Managed detection vendor Huntress identified at least 162 compromised tenants in its own monitored environment alone, and Todyl, a cybersecurity platform for MSPs, corroborated the same attacker infrastructure.

ConnectWise says it has found no evidence that stored backup archives themselves were accessed or altered, and that existing backups will remain available once the service is restored. But the breach is not about the backups sitting in cold storage — it is about the live, standing permissions the backup application holds inside every connected tenant.

Why MFA and user-based defences didn't stop this

According to Todyl's analysis, the attacker authenticated directly as the backup application itself, using its secret, rather than logging in as a human user. Because no user sign-in occurred, protections such as multi-factor authentication offered no resistance — the automated script simply inherited whatever broad permissions the customer had already granted the app over mail, OneDrive, SharePoint and Teams data.

This is the uncomfortable lesson for UK buyers: a service that was trusted enough to be granted wide tenant access becomes a single point of failure the moment its credentials are compromised. Huntress observed that on nearly 50 tenants, ConnectWise Cloud Management service principals went further and self-assigned directory roles — mostly Exchange Administrator — with one case escalating to Global Administrator and planting credentials inside both an MSP management tool and Huntress's own application within roughly five minutes. Microsoft's threat intelligence team assessed the attacker likely abused existing Directory.ReadWrite.All permissions, and classified the episode as an active supply-chain attack.

Immediate checks for UK MSPs and enterprise tenants

Every organisation using ConnectWise Cloud Backup, SkyKick Cloud Manager, or related Cloud Management apps for Exchange Online, Teams, SharePoint, Partner Center or Microsoft Graph should treat Entra ID auditing as urgent, not optional. The three vendors involved have each published slightly different guidance, which is worth comparing side by side before deciding what your team actions first.

• •Filter Entra sign-in logs by the Cloud Backup application ID 506e08f9-6e9a-4da4-942b-a099a03644ae and the related Cloud Management IDs, watching for unfamiliar source IPs
• •Check for scripted user agents linked to the attack — curl/7.88.1, python-urllib/3.12, python-requests/2.31 and python-requests/2.34.2
• •Review application credentials and certificates added since 13 October, when the earliest scripted sign-in attempts were logged
• •Disable implicated ConnectWise applications where they are not actively required, and revoke existing tokens rather than relying on session revocation alone

Why disabling the app alone isn't enough

Todyl's warning deserves particular attention: disabling an application stops new tokens being issued, but tokens already issued remain valid until they naturally expire, and revoking user sessions does nothing to end application-based access. ConnectWise's own service shutdown does not retroactively remove any credentials an attacker may already have planted inside a customer tenant. That means administrators need to actively hunt for and remove rogue credentials, not simply wait for the vendor's outage notice to clear.

This is precisely the scenario that supplier cyber risk assessment frameworks are built for — treating a vendor's standing access as part of your own attack surface, reviewed on a schedule rather than only after a breach headline. For MSPs managing dozens of client tenants through the same backup integration, a single compromised service principal multiplies risk across every downstream customer.

The bigger lesson on cloud backup and third-party risk

This incident lands squarely inside a wider pattern UK buyers have been warned about: cloud data breach and third-party risk increasingly originates not from a direct attack on Microsoft 365 itself, but from the privileged third-party applications granted standing access to it. Any backup, archiving or management tool with broad Graph API permissions is a potential pivot point, which is why architectural choices matter as much as vendor selection.

Buyers evaluating resilience should revisit the necessity of Microsoft 365 backup against how that backup is delivered — in particular whether backups sit behind immutable backup architectures that can't be altered even if the managing application is compromised. It is also worth running a fresh exercise to compare Microsoft 365 backup solutions on the basis of least-privilege access models, not just price and retention windows.

What good looks like going forward

Beyond this specific incident, the episode strengthens the case for zero trust principles applied to application identities, not just human users, and for managed detection & response capable of spotting anomalous service-principal behaviour such as self-assigned admin roles. Organisations without in-house capacity to audit Entra logs at this depth should talk to a specialist in cyber security solutions before assuming the vendor's shutdown has closed the door.