An MSP Platform's Own Credentials Became the Attack Path
ConnectWise disclosed that unknown threat actors gained unauthorized access to its application identities, the credentials its own products use to connect into customer Microsoft 365 environments, and used that access to compromise those customers' tenants directly. This is a materially different kind of incident than a typical software vulnerability: the attacker did not need to exploit a bug in a customer's own systems, they rode in on the legitimate, trusted connection ConnectWise's platform already had. On October 17, 2026 at 07:00 UTC, ConnectWise disabled seven affected application identities and suspended its Cloud Backup service, and as a precaution also pulled SaaS Security and Cloud Management offline.
ConnectWise says it first identified the issue on October 14, 2026, three days before it took the disabling actions on October 17. That gap between detection and containment is itself a data point for any customer assessing how this incident was handled, since identity-based access of this kind can be used to make changes inside a tenant for every hour it remains live. The company also revoked certificates tied to the affected Cloud Backup connections as part of its response, and pulled SaaS Security and Cloud Management offline even though those two services were not themselves confirmed as the entry point, a precaution that suggests ConnectWise was not yet fully confident it had scoped the attacker's full reach across its product line.
The Scale Huntress Found Is Larger Than ConnectWise's Own Disclosure Suggests
Security firm Huntress independently investigated the attacker's infrastructure and found sign-in activity from three specific IP addresses, 144.172.64[.]128, 144.172.64[.]99 and 144.172.64[.]60, across nearly 1,000 Entra tenants. Of those sign-in attempts, roughly 300 succeeded. That is a wide blast radius for an incident rooted in a single vendor's compromised application identities, and it illustrates why MSP and SaaS-connector platforms deserve the same scrutiny as any other high-privilege access point in an environment, rather than being treated as background plumbing that only IT operations teams need to think about.
The gap between ConnectWise's own numbers and what Huntress found independently is itself instructive. A vendor's own disclosure, however prompt, reflects what that vendor can see inside its own logs, while an independent researcher tracking the attacker's known infrastructure can surface activity the vendor's initial scope assessment missed. Any customer relying solely on ConnectWise's own notifications should treat Huntress's published figures, the nearly 1,000 tenants with sign-in activity and roughly 300 successful logins, as the more conservative floor on how many tenants may have seen attacker activity, and plan their own audit accordingly.
A Second, More Targeted Wave Went After Specific Sectors
Beyond the broad sweep reflected in the roughly 1,000-tenant figure, Huntress identified a separate and more deliberate wave of activity that attempted to reach 16 tenants specifically in policy, national security, trade and critical-mineral sectors. Those targeted attempts did not succeed, according to the available reporting, but the fact that they were attempted at all signals the attacker treated the initial, broad access as a reconnaissance step toward a more selective, higher-value follow-on operation rather than as the end goal in itself.
That two-stage pattern, mass opportunistic access followed by a curated, sector-specific targeting pass, is a profile more consistent with a sophisticated, possibly state-aligned actor than with a smash-and-grab credential thief working purely for financial gain. Organizations in those named sectors that use ConnectWise products should not take the failure of this particular attempt as reassurance that the same actor will not try again through a different access path now that it has shown clear sector-level intent against exactly their kind of organization.
ConnectWise's Own Language Draws a Careful, Important Boundary
ConnectWise has been explicit that disabling the compromised application identities does not reverse any changes the attacker already made inside a customer's tenant while that access was live. That is a meaningful caveat: containment at the vendor level stops new unauthorized access through that specific connection, but it does nothing to undo mailbox rule changes, new forwarding addresses, newly created accounts, or any other persistence an attacker planted during the window of successful sign-ins, which Huntress's data shows happened roughly 300 times.
The company also stated that its own finding does not establish the status of downstream customer environments, effectively telling customers that ConnectWise's remediation cannot tell them whether their own tenant is currently clean. Both statements place the burden of verification squarely on the customer rather than the vendor. Any organization using ConnectWise Cloud Backup, SaaS Security or Cloud Management should treat this as an instruction to actively audit its own Microsoft 365 tenant for unauthorized changes, not as a problem ConnectWise's containment actions have already resolved on its behalf.
What a Thousand Affected Tenants Means for Vendor Concentration Risk
ConnectWise is widely used across the managed service provider ecosystem, which means a compromise of its application identities does not stay contained to ConnectWise's own direct customers, it potentially cascades through every MSP that resells or operates those connections on behalf of its own clients. That multiplier effect is exactly why identity-and-access platforms sitting between a vendor and thousands of downstream Microsoft 365 tenants deserve a materially higher level of security scrutiny than a typical point-product integration, and why an incident at a single vendor like this one can functionally become hundreds of separate customer incidents at once.
If your organization uses ConnectWise Cloud Backup, SaaS Security or Cloud Management, or receives any of them indirectly through an MSP, the immediate action is a tenant-level audit: check for new or modified mail-flow rules, unfamiliar service principals or app registrations, and any sign-in activity from the specific IP ranges Huntress has published. The broader lesson for the roadmap is to inventory every third-party application identity with standing access into your core SaaS tenants and ask, concretely, what happens to your environment if that vendor's own credentials are the thing that gets compromised next.
