ConnectWise Cloud Backup OAuth Incident: Response Guide

ConnectWise's October 18 Trust Center update says unauthorized access affected application identities associated with Cloud Backup, formerly SkyKick. On October 17 at 07:00 UTC, ConnectWise disabled seven listed application identities and revoked certificates used for affected connections. Cloud Backup remains suspended; SaaS Security and Cloud Management were also temporarily taken offline while the investigation continued.

This is the latest point in a developing incident that The Hacker News covered in its initial October 17 report and October 18 follow-up; they describe one event, not two separate breaches. Treat the vendor's current advisory as the source of service status and recommended action. Independent responders, including Huntress and Todyl, reported unauthorized Microsoft 365 sign-ins using the Cloud Backup application's existing tenant consent. Their telemetry sets and confirmed activity differ, so their counts should not be combined into a single victim total.

What the evidence says, and what it does not

The Cloud Backup application is a multi-tenant Microsoft 365 enterprise application. Organizations previously granted it permissions to operate the backup service. Threat researchers reported use of a compromised shared application credential to obtain app-only access in customer tenants. Because app-only authorization does not require a human user to sign in, user MFA and user-focused Conditional Access controls do not by themselves prevent this application credential path.

ConnectWise says it has no evidence that stored backup archives were accessed and that the archives remain encrypted, isolated, and preserved. That statement is about backup archives. It does not establish that no activity occurred in live Microsoft 365 tenants. ConnectWise explicitly says it lacks the downstream visibility to determine independently whether each partner tenant experienced unauthorized activity. A successful service-principal sign-in establishes authentication, not that files or mail were read or exfiltrated. Conversely, incomplete activity logs cannot prove no access occurred.

Recommended tenant response

ConnectWise directs partners to examine their own Microsoft 365 tenant and every managed customer tenant, including dormant SkyKick connections. Use the official Trust Center workflow as it changes. At a minimum:

1. Keep the affected enterprise applications disabled. Match the seven application client IDs in the advisory, not only display names, which may still use the SkyKick brand. Do not re-enable them until ConnectWise provides restoration and reauthorization instructions.
2. Preserve evidence before deleting or changing configuration. Record tenant and local enterprise-application object IDs, state, owners, consent, credentials, and UTC collection time. Export available service-principal sign-in, Entra audit, Microsoft 365 audit, and SIEM records promptly. Retention and permissions vary by tenant.
3. Review activity beyond the original app. Examine application and user sign-ins, credentials, consent grants, directory roles, owners, federation trusts, policy changes, delegated mail access, mailbox forwarding, inbox/transport rules, and any identities modified during the activity.
4. Search every managed tenant. A dormant or legacy connection may still exist. Verify local status separately; the vendor's disabled connection does not prove every customer tenant's enterprise-app object is disabled or clean.
5. Treat established access paths independently. The advisory warns that disabling the original app does not reverse tenant changes or credentials established through another identity. Contain suspicious changes through your incident-response process and involve Microsoft or qualified responders when needed.
6. Do not equate a clean search with proof of no activity. Record the exact log sources, time coverage, licensing limits, gaps, and queries used. Where visibility is insufficient, document the uncertainty and escalate rather than claiming the tenant is unaffected.

The application most prominently discussed by researchers is ConnectWise Cloud Backup, client ID 506e08f9-6e9a-4da4-942b-a099a03644ae. The vendor advisory lists seven client IDs and detailed checks. Use the full authoritative list there; do not rely on a shortened or stale indicator list in this article.

Longer-term control lessons

Third-party application consent creates a trust relationship that can outlive the original deployment decision. Inventory multi-tenant enterprise applications, remove unused grants, minimize application permissions, assign accountable owners, and define an emergency disable-and-recovery process with the vendor. User MFA remains important, but app-only credentials need their own protection, monitoring, rotation, and revocation controls.

For service providers, incident scope includes each customer tenant, not just the provider's own directory. Confirm which customers approved the application, identify dormant grants, and maintain a repeatable way to export evidence before retention expires. Do not mass-delete application objects during triage when doing so would destroy useful configuration evidence or make vendor-guided recovery harder.

Separate application authentication from tenant activity

An app-only sign-in and a data operation answer different questions. A service-principal sign-in can show that an application identity authenticated to a tenant. It does not, by itself, show which mailboxes, files, or sites the identity accessed. Tenant audit records and workload-specific logs may show subsequent operations, but their coverage depends on the tenant's licensing, retention, and configuration.

Use client IDs and tenant-local enterprise-application object IDs to correlate records. Display names can be changed or duplicated, so they are weak identifiers during a multi-tenant investigation. Keep the UTC time range and the query used with every result. This helps an MSP compare tenants without treating one customer's telemetry as evidence about another.

Move from containment to safe recovery

Disabling the affected application identity blocks a path; it does not automatically reverse tenant changes, remove every local grant, or establish that existing sessions are harmless. After preserving evidence, verify the application state in each tenant, review credentials and consent, revoke suspicious grants or sessions through the tenant's response procedure, and assess any separate identity or persistence path discovered during investigation.

Keep backup continuity decisions separate from compromise findings. Confirm service availability and reauthorization steps through the current ConnectWise Trust Center before restoring the integration. When the service is available, validate access using a controlled account and a known test restore process. Do not restore data or re-enable an application solely because the vendor has resumed service; first verify the tenant-side identity and recovery conditions.

Questions about the ConnectWise Cloud Backup incident

Does ConnectWise disabling its application identities remove every tenant grant? Do not assume so. Check each tenant's local enterprise application, permissions, and sign-in records, then follow the current vendor instructions.

Does “no evidence of backup archives accessed” mean connected Microsoft 365 tenants were unaffected? No. The statement concerns stored backup archives. Review live-tenant activity separately and report only what your records establish.

Status snapshot

As of ConnectWise's October 18, 2026 advisory, the services above were still paused and no restoration time had been provided. ConnectWise said its investigation with a third-party forensics firm was ongoing. This is a dated status snapshot, not a claim about current availability. Check the Trust Center before taking service-restoration action.

Related reading: OAuth/OIDC security testing for SaaS applications and AI agent identity attack paths.