ConnectWise-Associated Credentials and Reported Microsoft 365 Access
Meta title: ConnectWise Credentials and Reported Microsoft 365 Access
Meta description: Dark Reading reported Microsoft 365 authentication using credentials associated with ConnectWise Cloud Backup. Its reporting does not establish access to customer content.
Incident overview
Dark Reading reported that credentials associated with ConnectWise Cloud Backup were used to authenticate to Microsoft 365 tenants. It reported that ConnectWise identified unauthorized access to Cloud Backup application identities on October 14, 2026, and disabled Cloud Backup for partners and clients on October 17. ConnectWise also disabled SaaS Security and Cloud Management while remediation continued, according to the report. sourceRef: Dark Reading, reporting on the incident
The reporting establishes that Microsoft 365 authentication occurred; it does not establish that an attacker read, copied, altered, or deleted customer content. Nor does it confirm that customer data was unaffected. Dark Reading reported that ConnectWise revoked certificates used by affected application connections, invalidated shared Cloud Backup credentials associated with the incident, and rotated credentials or disabled identified identities. The report does not establish the status of revocation in every tenant, provide a complete inventory of affected tenants, or resolve the initial access route and attribution. sourceRef: Dark Reading, reporting on the incident
Cloud Backup protects Microsoft 365 data. More generally, third-party applications can hold permissions that reach sensitive services across customer environments. For managed service providers (MSPs), that makes it important to review integrations in both the provider’s tenant and the customer tenants it manages. These are general identity and third-party-risk considerations, not findings about the extent of access in this incident.
What researchers and ConnectWise reported
Dark Reading reported that ConnectWise engaged an incident-response firm and that its investigation was ongoing. The report also says ConnectWise recommended customers review their Microsoft 365 tenants and the tenants of managed customers, including those with dormant SkyKick connections. sourceRef: Dark Reading, reporting on the incident
A dormant connection is not, by itself, proof that an integration is active or harmless. Check its configuration, permissions, and credentials before drawing conclusions.
Why application identities need scrutiny
Applications can authenticate without a person signing in interactively. Their permissions may persist and be less visible in reviews centered on user accounts. Inventory enterprise applications and service principals used for backup, security, and management; note each identity’s owner, purpose, consent history, permissions, credentials, and the customer environments where it appears. For background on identity compromise across SaaS environments, see Beyond the Perimeter: How Single Identity Compromises Enable Deep SaaS Penetration.
Pay particular attention to permissions involving mail, files, collaboration content, or tenant administration. Check whether certificates or secrets remain valid and whether credentials were issued unexpectedly. Where possible, compare settings with a known-good baseline. Verify identity state in each tenant rather than assuming a provider-side action removed every local consent, grant, or artifact.
There is also a continuity question: establish which services are unavailable, how backup and restore functions are affected, and what alternate recovery controls exist. Coordinate security, identity, Microsoft 365 administration, MSP operations, and legal or compliance teams. Avoid disabling legitimate integrations without a plan for data protection and restoration, while containing access that evidence indicates is suspicious.
Practical Microsoft 365 review steps
These are general review actions, not evidence about what happened in this incident. Start by identifying relevant ConnectWise Cloud Backup, SkyKick, and related management applications in your tenant; MSPs should repeat the review in every customer tenant they administer. Record object identifiers, owners, consent grants, permissions, credential dates, and whether each connection is active or dormant.
Then use available sign-in and audit records to establish what they can show: the timing and context of authentication, resources accessed, and whether activity continued after reported credential actions. Correlate that evidence with application changes, role assignments, and activity involving Exchange, SharePoint, OneDrive, and Teams. Preserve relevant logs. Coverage and retention vary, so document gaps and seek provider-side records when tenant telemetry is insufficient; an absent log entry does not prove an action did not occur.
Look for changes during the review period, including new application credentials, altered consent or permissions, unexpected administrative role assignments, and changes to mailbox access or forwarding. Review relevant mailbox rules and delegations, distinguishing pre-existing settings from new ones. If you find suspicious changes, preserve evidence and follow your incident-response process before removing artifacts investigators may need.
When assessing possible data access, keep authentication separate from content activity. Record which resources and actions the evidence supports, what remains undetermined, and whether additional records are needed. Do not characterize data as exposed—or definitively unaffected—without supporting evidence.
Finally, confirm whether backup jobs stopped, whether protected data remains recoverable through other means, and how restoration will be tested when service resumes. Track service impacts separately from breach conclusions. Keep a timeline of evidence sources, decisions, remediation, and open questions for later audit and compliance review.
Compliance and ongoing questions
Microsoft Learn materials on identity governance and Microsoft 365 controls can provide general background, but they are not evidence about this incident. Base compliance conclusions on verified facts: which data types and jurisdictions might be implicated, whether content access is evidenced, and which notification obligations or contractual commitments apply. Keep vendor statements, tenant telemetry, response actions, and unresolved questions distinct in the incident timeline.
The broader lesson is to treat service-provider access as part of the organization’s identity perimeter. Maintain an inventory of third-party applications, least-privilege permissions, accountable owners, credential-rotation plans, and a repeatable process for reviewing managed tenants. Revisit conclusions as further evidence becomes available.