As reported by Dark Reading, ConnectWise has disabled its cloud backup functionality amid concerns that attackers authenticated into Microsoft 365 tenants using credentials associated with the platform, potentially impacting downstream MSPs and their customers. While ConnectWise has stated that customer impact remains unconfirmed, the incident underscores a structural risk in the MSP ecosystem that deserves far more attention than any single vendor advisory typically receives.
Why This Matters Beyond ConnectWise
The core issue here is not whether ConnectWise itself was breached in a traditional sense. The more significant concern is the identity trust architecture that MSP platforms rely on. When a single set of credentials — or a single OAuth token — can authenticate into hundreds or thousands of downstream M365 tenants, that credential becomes a weapon of mass compromise. Attackers no longer need to compromise each target individually; they need only compromise the tool that manages them all.
The weakest link in the MSP supply chain is rarely the endpoint customer's security posture. It is the concentration of privileged access held by the platforms MSPs trust to manage their environments.
This is the same class of risk we saw in the SolarWinds and Kaseya incidents, and it persists because the industry has not fundamentally changed how MSP-to-vendor trust relationships are architected. Disabling backups is a reasonable containment move, but it treats the symptom, not the disease.
Who Is Most at Risk
The OAuth Token Problem Nobody Talks About
What is likely happening under the hood is not a simple username/password compromise but an OAuth token abuse scenario. When an MSP connects a platform to M365, Microsoft issues long-lived refresh tokens with delegated permissions. If an attacker obtains those tokens — through API key exposure, session hijacking, or platform compromise — they can authenticate as the MSP application across every connected tenant without ever needing the customer's credentials. MFA on the customer tenant is irrelevant because the token was already issued with consent.
This is a blind spot for most M365 defenders. Conditional Access policies often do not cover consented application activity. Audit logs may show successful sign-ins from the application ID, but they are frequently filtered out as noise.
Shield53 Recommendations
Immediate Actions
- Audit all third-party application OAuth grants in every M365 tenant you manage. Use the Microsoft Graph API or the Azure AD admin center to review consented permissions. Revoke any application you cannot immediately justify.
- Review ConnectWise-related sign-in activity in Azure AD audit logs for the past 90 days. Look for anomalous IP geolocation, unusual sign-in frequency, or access from non-standard user agents.
- Implement Conditional Access policies for third-party application access — require compliant device or trusted location for token use, not just initial sign-in.
- Verify backup integrity independently — do not assume backups completed before the service was disabled. Test restore operations from the last known-good backup set.
Strategic Hardening
- Segment MSP platform credentials — use separate service accounts per client tenant rather than a single delegated admin relationship where possible. This limits blast radius to one customer per credential set.
- Adopt least-privilege application permissions — demand that vendors scope OAuth grants to the minimum required. If a backup tool has Mail.ReadWrite across the tenant, that is a red flag.
- Establish an MSP vendor risk program — treat every platform with tenant-level access as a tier-0 trust boundary. Require incident notification SLAs, independent security assessments, and evidence of token rotation practices.
- Build an alternate backup path — any MSP relying on a single backup vendor for all client data should treat this as a single point of failure. Maintain a secondary backup capability, even if it is less feature-rich.
The ConnectWise situation will resolve, but the architectural problem will not. Every MSP platform that holds delegated access to customer tenants is a potential pivot point for attackers. The question defenders should be asking is not which vendor was compromised this time, but how many of their SaaS tooling relationships would be catastrophic if the vendor's credentials were exposed tomorrow. If the answer is more than a handful, the trust model needs to change before the next incident forces it to.
