As reported by The Hacker News, ConnectWise has disabled seven of its application identities and suspended Cloud Backup services after unknown threat actors obtained unauthorized access to those identities and compromised downstream Microsoft 365 tenants. The company identified the issue on October 14, 2026, and began revoking certificates and disabling connections on October 17.

Cloud Security Alert: As reported by The Hacker News, ConnectWise has disabled seven of its application identities and suspended Cloud Backup services after unknown threat actors obtained unauthorized access to those identities and compromised downstream Microsoft 365 tenants.

This incident is a textbook example of supply chain risk in the MSP ecosystem — but with a particularly dangerous twist. When an ISV's service principal is granted tenant-wide delegated permissions across hundreds or thousands of customer environments, a single compromise at the vendor level can cascade into mass tenant access. This is not a vulnerability in a single product; it is an architectural risk inherent to the multi-tenant SaaS model that pervades Microsoft 365 ecosystems.

Why This Incident Is Structurally Significant

The seven disabled ConnectWise application identities — spanning Cloud Backup, Cloud Management for MS Teams, Exchange Online, MS Graph, Partner Center, and SharePoint Online — collectively held extensive delegated permissions across customer tenants. The breadth of these service principals suggests the attackers potentially had access to mailboxes, Teams data, SharePoint sites, and directory information across every affected tenant.

The critical detail ConnectWise disclosed: disabling connections prevents new authentication but does not reverse changes already made inside a tenant, and previously issued access tokens may remain valid until they expire. This means the blast radius is not contained by revocation alone.

This is the core problem with OAuth-based delegated access. Unlike password-based authentication where changing a credential immediately invalidates all sessions, OAuth tokens have lifecycles that can persist beyond the revocation of the underlying grant. Attackers who established additional identities, permissions, or persistence mechanisms inside compromised tenants are not affected by ConnectWise's remediation actions.

Who Is at Risk

Why This Incident Is Structurally Significant
MSPs and their customers using ConnectWise Cloud Backup or Cloud Management for M365 administration — potentially thousands of downstream tenants
Small and midsize businesses who rely on MSPs for M365 management and may lack internal security teams to detect rogue application registrations or suspicious token activity
Any organization that has granted third-party SaaS applications tenant-wide delegated permissions without reviewing the scope of those grants

The Broader Problem: Unchecked Delegated Permissions

This incident should prompt every organization to audit the third-party application identities operating in their Microsoft 365 tenant. The Microsoft Graph API's permission model allows service principals to hold powerful scopes like Mail.ReadWrite, Sites.FullControl.All, and Directory.ReadWrite.All. When these are granted to a multi-tenant ISV application, you are trusting not just the vendor's security but the security of every component in their authentication chain.

ConnectWise has stated there is no evidence backup archives were accessed or that existing archives were breached. That is reassuring but does not address the primary risk: attackers operating inside customer tenants with potentially weeks of undetected access before the October 14 discovery.

Shield53 Recommendations

Immediate Actions for Affected Organizations

  • Audit all application registrations and service principals in your M365 tenant via Entra ID. Look for any ConnectWise-related app IDs (listed in the advisory) and review their current permission grants and sign-in activity.
  • Hunt for persistence mechanisms the attackers may have established: new app registrations, additional delegated permissions, new federated trust relationships, mailbox forwarding rules, and OAuth consent grants. Use the AuditLogs and SignInLogs in Azure Monitor or Microsoft Sentinel.
  • Force re-consent for any ConnectWise applications once service is restored — do not assume old grants are safe simply because connections were revoked.
  • Review conditional access policies to ensure they cover service principal sign-ins, not just user sign-ins. Many organizations leave app-based authentication outside CA policy scope.
  • Check for mailbox forwarding rules and inbox rules created by service principals — a common post-compromise persistence and data exfiltration technique in M365.

Strategic Actions for All Organizations

  • Implement least-privilege for third-party app grants. Avoid granting tenant-wide admin consent to multi-tenant ISV applications. Use application-specific consent where possible and review scopes quarterly.
  • Deploy Microsoft Defender for Cloud Apps or equivalent CASB to monitor OAuth app activity and alert on anomalous behavior from service principals.
  • Create an inventory of all third-party SaaS integrations with your M365 tenant, including the specific permission scopes granted to each. This is your baseline for detecting unauthorized additions.
  • Establish an incident response playbook specifically for OAuth/consent grant compromise scenarios. Standard IR procedures for credential theft do not adequately address token-based persistence and delegated permission abuse.

This incident will not be the last of its kind. The MSP-to-customer trust chain is a high-value target for threat actors precisely because compromising one vendor can yield access to thousands of tenants. Organizations must treat every third-party application identity in their environment as a potential attack surface and govern it accordingly.